L Loach Docs
Ctrl K

Tools, MCP & folders

Web fetch, MCP servers and working folders all have hard safety guards. Most surprises trace back to one of those guards firing - or to a prompt waiting for your answer.

Pasted URL is ignored

Your prompt has a link but the model only sees the bare URL, not the page content.

  1. Web fetch is off by default. Turn it on in Settings → Tools → Web fetch, or type /web-fetch on.
  2. Only http:// and https:// URLs are fetched, and only those in the text you type - not links inside attached files or ones the model mentions.
  3. Up to 5 URLs per message are followed. Extras are ignored.
  4. Private Chat never fetches URLs, whatever the setting says.

“Refusing to fetch …” for localhost, 192.168.x, or my office VPN

Loach refuses to fetch an internal URL.

This is intentional. The SSRF guard rejects localhost and any URL whose resolved IP lands on loopback, link-local, private RFC1918 ranges, carrier-grade NAT (100.64.0.0/10, which Tailscale uses) or IPv6 unique-local addresses (fc00::/7), even if the hostname looks public but resolves there via DNS. To share internal content with a model, copy the page text and paste it into the chat instead. (This guard covers web fetch and Library links - MCP servers on localhost or your LAN are allowed.)

A URL fetch failed or came back cut short

The model is told a URL was attempted but no content came back - the reply’s tool-call block shows a red warning - or only part of the page arrived.

Expand the tool-call block on the reply and open its web_fetch entry to read the reason. A fetch fails on:

A body over the 5 MB cap isn’t a failure: the page is cut off at the cap and the entry says “truncated by Loach” - as it does for a page whose extracted text runs past ~12,000 characters. If your message also carries large attachments, a fetched page may not fit the 500,000-character message budget and is listed by URL only. And because no JavaScript runs, a page that builds its content in the browser can come back nearly empty.

Type /fetch <url> to see what Loach extracts from a page without sending anything to the model. If the URL works in a browser but not in Loach, the page is likely slow, large, built by JavaScript, or blocks non-browser user agents - or your network only lets traffic out through a proxy. Web fetch, Library links and HTTP MCP servers connect directly and never use a proxy (the HTTP(S)_PROXY variables or the system setting): a proxy looks the host up again itself, which would get around the private-address check.

MCP “Test connection” fails (HTTP)

An HTTP MCP server is configured but the test button reports an error.

  1. Confirm the URL is the Streamable HTTP endpoint. Loach does not support the legacy two-endpoint SSE transport. If the server is distributed as a command to run (npx …, uvx …), add it as a Local process (stdio) server instead.
  2. If the server requires auth, open it in Settings → MCP and add an Authorization: Bearer … line under Headers. The field hides what’s in it once filled; its eye button shows the values.
  3. “DNS lookup failed” means the host can’t be resolved from this machine - check the address, or connect to the VPN it lives behind. localhost and private LAN addresses are fine for MCP (unlike web fetch); only link-local addresses are refused. A server saved switched off isn’t looked up, so you can rename or disable one while its host is out of reach; switching it on checks the host again.
  4. Check that the response body fits under 4 MiB - misconfigured servers that dump full schemas can exceed this.
  5. Per-request timeout is 30 s.
  6. Loach doesn’t follow redirects. When the error says the server redirects to the same URL with (or without) a trailing /, change the server URL to match; for any other target, use the address the server points to.
  7. Loach connects directly, never through a proxy - a server you can reach only through one won’t answer.

A local (stdio) MCP server won’t start

Test connection on a stdio server fails, or a chat shows an error for it, with “couldn’t start”, “exited before replying”, or “did not reply … within 60s”. (Saving doesn’t start the server - it first runs when you test it, list tools with /tools, or send a message with it enabled.)

  1. Use Test connection in Settings → MCP: when the server process exits, it quotes the last lines the server wrote to its error output (npm ERR! 404, a Python traceback, “command not found”). That is usually the whole answer. An error in a chat stops short of that output, which can print anything - keys included - and would otherwise be sent to the model and saved with the chat. A timeout doesn’t include it either; run the command in a terminal to see what it’s waiting on.
  2. Make sure the runtime the command needs is installed and on PATH for your user: Node.js for npx, uv for uvx. Loach hands the program the environment it read when it started - if you installed the runtime since, restart Loach. On macOS and Linux, Loach asks your login shell for its PATH once per launch, so tools installed through Homebrew, nvm, pyenv and the like are found even when Loach was started from the Dock or an app menu. If one still isn’t - your shell took over 10 s to start, or sets PATH somewhere a login shell doesn’t read - run echo $PATH in a terminal and add the result to the server’s environment variables as PATH=….
  3. On Windows, npx is a .cmd shim (uvx an .exe). Loach finds either on PATH for you, but a full path also works.
  4. First runs of npx -y … download the package. Startup is allowed 60 s; a slow network can exceed that - run the command once in a terminal to warm the cache, then test again.
  5. Put one argument per line. Don’t quote arguments the way you would in a shell - Loach passes each line as one argument, spaces included (only leading and trailing whitespace is trimmed).
  6. If you clicked Cancel on the “Run MCP server …?” system dialog - or pressed Enter, which picks Cancel - nothing was saved or started. Save again and click Start server.
  7. “This command line is too long to show for review” means the program, arguments and shown environment exceed the dialog’s 1,500 characters. Point the server at a config file instead of passing everything as arguments.
  8. A tool call that times out doesn’t stop the server; it may still be working. A tool that reports its progress gets up to 10 minutes. When two requests in a row go unanswered, Loach treats the server as hung and starts it afresh on the next call; to restart it sooner, disable and re-enable it.

A server imported from a backup is disabled and won’t turn on

After Settings → Data → Import data, a stdio MCP server shows up switched off, and flipping the switch opens a system dialog.

That is deliberate: a backup can’t prove you configured that command on this machine, so imported stdio servers arrive disabled and the first enable asks you to confirm the command line. Review it and choose Start server to enable the row; Cancel leaves it off. HTTP servers keep the on/off state they had in the backup - unless their host couldn’t be looked up during the import (offline, off the VPN), in which case they arrive switched off too; turn them on once the host is reachable again.

Backups never contain MCP headers or environment variables, and a URL’s credentials, the value after a --token-style argument and a credential passed as NAME=value come back as REDACTED - as does every query value in an HTTP server’s URL. After an import, re-enter any Authorization header, API-key variable, URL or redacted argument a server needs.

A server whose name breaks the naming rules (from a backup made before they existed) is imported under a fixed-up name rather than failing the import.

The reply is stuck on “Waiting for your approval…”

The assistant bubble shows an approval card and nothing else happens.

The model asked to run an MCP tool, or to change a file in the chat’s working folder, and Loach is waiting for you - answer Allow once, Always allow (Allow … for this chat for a file change), or Deny on the card. A card left unanswered for 10 minutes isn’t run - the call is marked No answer - and the Stop button cancels the reply. A file change inside a .git, .husky or .githooks folder, to a .pre-commit-config.yaml, or in a folder laid out as a bare Git repository asks every time, even after Allow … for this chat: a hook or setting there runs commands the next time you use Git.

Until you answer, replies in other chats queue behind this one. If the card is in a chat you aren’t looking at, Loach shows a notice with an Open button, and the queued chat offers Go to it. To stop being asked for a server you trust, open it in Settings → MCP and turn off Ask before each tool call; to bring back prompts for tools you answered “Always allow” for, use Ask again for all in the same editor and save.

“Stopped after 10 tool-use turns”

A reply ends with this error while the model is still calling tools.

Each reply gets at most 10 rounds with the model, so a model stuck in a loop can’t run forever: tools can run in the first nine, and the tenth is sent without tools so the model can wrap up. This error means it asked for them anyway, and those calls weren’t run. Either it was stuck, or the task needs more steps than that. Send a follow-up (“continue”) to give it another 10 rounds, or break the task into smaller requests. With the file tools, pointing it at the right files up front - or putting that in LOACHFILE.md - saves rounds spent searching.

“… does not support tools” after turning a tool on

Every message to a local model now fails with an Ollama error ending in “does not support tools”.

Loach sends the tools you switched on - built-in tools, enabled MCP servers, a chat’s working folder - with every request outside Private Chat, whatever the model. A model without tool calling can’t take them, and Ollama refuses the request. Switch the chat to a model that supports tools (its page in the Ollama library lists them, and ollama show <model> prints tools under Capabilities), or turn the tools off in Settings → Tools and Settings → MCP. Web fetch doesn’t count: it isn’t a tool the model calls, so it works with any model.

The model can’t use tools in Private Chat

A model that calls tools in regular chats says it has none in Private Chat.

By design: Private Chat offers no tools at all - no MCP servers, which could carry the conversation off your machine, and no built-in tools, since the overlay has nowhere to show a call or a PDF one makes. Use a regular chat for tool work.

Can’t add a folder, or the model doesn’t use it

Add directory is greyed out or refuses the folder, or the model says it has no file tools.

The model can’t use a file or folder name on Windows

A file tool refuses a path with “contains :”, “ends with a dot or a space”, “is a device name Windows reserves” or “reaches … by its Windows short (8.3) name”.

Those names are refused on purpose: a : names a hidden data stream, and CON, nul.txt or a trailing dot would be created as files that Explorer and most tools can’t open or delete. Ask the model to pick another name. A short name such as PROGRA~1 or IMPORT~1.MD is refused when it stands for a longer one, because the approval card would name a different file from the one that changes - ask the model to use the full name, which list_directory shows. (On every platform, a name with a control or text-direction character is refused too, because it can make the approval card show a different name than the one written.)

A file write or edit is refused

The model’s file change fails, and the tool-call entry shows why.