MCP & web lookup

Add a server, and choose where it lives

A server is a few lines of settings: a name, a transport, and either a command to launch or a URL to connect to. squeezy mcp add writes those lines for you, into either your own settings, so the server follows you across every repository, or the project's committed settings, so it travels with the team. Three transports are supported: stdio for a server Squeezy launches as a local subprocess, http for a network server, and sse for older network servers that speak the earlier event-stream protocol.

Cloning a repository does not start the MCP servers it declares. Project entries load switched off and stay off until you approve that server with /trust. What you approve is the part that decides what gets launched or connected to: the transport, the command and its arguments, the working directory, the URL, the environment entries, and the headers. Change any of them and the approval lapses, so an edited command is a new decision rather than an inherited one. Servers you added to your own settings need no such pin.

Tools arrive namespaced. A tool named query on a server named db reaches the model as mcp__db__query, so two servers can expose the same tool name without colliding, and a permission rule can name one server's tools without touching another's. Each server can also carry its own default of allow, ask, or deny, and can narrow which of its tools are offered at all.

• squeezy mcp add <name> --user --transport stdio --command <cmd> [--arg ...], a local server Squeezy launches as a subprocess.
• squeezy mcp add <name> --project --transport http --url <url>, a network server committed with the repo, inert until trusted with /trust.
• squeezy mcp enable / disable / remove <name> --user|--project, toggle or delete a configured server.
• --permission-default allow|ask|deny sets that server's own default; --enabled-tool and --disabled-tool allow-list or block individual tools by name.
• --required makes a headless run fail with a precise error instead of starting without that server's tools.

squeezy mcp add docs --user --transport stdio --command npx --arg -y --arg @scope/docs-mcp
squeezy mcp add api --project --transport http --url https://mcp.example.com
squeezy mcp enable docs --user
squeezy mcp remove api --project

Bring the servers you configured elsewhere

If another tool already has your MCP servers written down, you do not have to retype them. squeezy mcp import reads .mcp.json, .cursor/mcp.json, and ~/.claude.json from your workspace and home directory and turns what it finds into Squeezy settings.

It previews by default. Without --yes it writes nothing and shows you the parse: where each server came from, which of its keys have no equivalent here, and the exact difference against your current configuration. Writing needs --yes and an explicit --user or --project. A value written as ${VAR} stays a reference and is read from the environment when the server starts, so a token is never copied into a settings file, and anything landing in project settings is switched off until /trust, like any other checked-in server.

squeezy mcp import --dry-run
squeezy mcp import --path .mcp.json --dry-run
squeezy mcp import --user --yes

See what is configured, and whether it works

squeezy mcp list is the inventory: one row per server with its state, transport, endpoint, and a credentials column that names the environment variables in play and counts the headers, never printing a value. Add --probe and Squeezy brings each enabled server up for real, then reports ready, stale, failed, or cancelled beside the number of tools it advertised. squeezy doctor --probe runs that same check as part of the wider health report.

When one server is the problem, three commands narrow it down. squeezy mcp show <name> prints the merged configuration with the settings file each field came from, the credential summary, and, with --probe, live status and tool count. squeezy mcp test <name> runs the handshake on its own; because it is something you asked for explicitly, it runs even on a server that is disabled, says so in the output, and exits non-zero when the handshake fails, so it drops into a script or CI unchanged. squeezy mcp logs <name> replays what a local server wrote to its error stream, redacted, alongside the transport phases it went through. Every one of these takes --json.

squeezy mcp list --probe
squeezy mcp show docs --probe
squeezy mcp test docs
squeezy mcp logs docs --follow

Credentials, working directories, and time limits

A secret is never stored in a settings file. For a network server you name the environment variable that holds the bearer token (bearer_token_env_var) and Squeezy reads it when the session starts; if the variable is not set, nothing is sent rather than an empty header. Fixed headers go in http_headers, and headers whose values come from the environment go in env_http_headers, resolved the same way, with the environment-sourced value winning a name clash. For a local server, env passes entries to the child process and cwd sets the directory it starts in, so relative paths, Node scripts, and Python virtual environments resolve from a predictable root.

A network server can log in with browser OAuth instead. squeezy mcp auth <name> handles metadata discovery, PKCE, and dynamic client registration where the server supports it, then stores the tokens in an owner-only file outside your settings; squeezy mcp status shows what is stored, redacted, and squeezy mcp logout removes it. Logging in is not trust: a checked-in server still needs its /trust approval before it connects, tokens or not.

timeout_ms supplies the server’s common timeout. discovery_timeout_ms overrides bring-up and discovery. operation_timeout_ms covers tool calls and resource operations; tool_call_timeouts_ms can override individual tools. A tool uses its named override, then operation_timeout_ms, then timeout_ms, then the 30-second default. When a phase times out, the connection is dropped so a later call can start fresh.

• bearer_token_env_var, http_headers, env_http_headers, credentials for network servers, read from the environment at session start; only the names ever appear in settings or in mcp list.
• env and cwd, environment entries and working directory for local subprocess servers.
• timeout_ms, discovery_timeout_ms, operation_timeout_ms and tool_call_timeouts_ms separate shared, discovery, operation and per-tool limits; the fallback is 30 seconds.

What a server costs you in context

Every tool a server advertises has to be described to the model before it can be called, and a verbose server can spend thousands of tokens on those descriptions before doing any work. Squeezy trims them. Each tool's parameter schema is cleaned up and shrunk toward a fixed byte budget, and the default pass never changes what the tool accepts: it drops stray nulls, definitions nothing references, and display-only annotations. A schema still over budget after that is refused rather than advertised with an argument whose shape is unstated. Deleting optional parameters to make one fit is a separate opt-in, per server.

Discovery is rationed too. Squeezy sweeps for tool changes once per agent turn and, within that sweep, only re-asks the servers whose lists are actually due, so a stable server is not re-enumerated on every message; a server that announces a change is picked up between sweeps. Whatever else a server publishes stays out of the prompt until it is wanted: files and prompt templates it exposes are listed and read by name, on demand, rather than loaded up front.

When a server asks you a question

MCP servers can ask for input in the middle of a call, either a small form to fill in or a URL to confirm. Squeezy routes those through the same permission setting that governs MCP tools, so a server cannot drive your terminal unchecked. On the default, ask, every request is shown to you. On deny they are all declined without prompting, so a misbehaving server cannot stall the agent waiting for an answer. On allow, a form that declares no required fields is accepted for you, while anything with required fields, and every URL confirmation, is still shown.

Web lookup is gated, not open browsing

The agent can use websearch and webfetch when the task needs web information. Both pass through the permission policy. websearch_provider chooses Exa or Parallel; exa_api_key_env and parallel_api_key_env name the credential environment variables. webfetch retrieves one HTTP or HTTPS URL. Results carry bounded, redacted text, retrieval metadata and citations.

The boundaries are enforced. webfetch refuses loopback, link-local, private ranges, and cloud metadata addresses, judged on the address a hostname actually resolves to rather than on how the URL was spelled. A redirect that leaves the requested origin, meaning a different scheme, host, or port, is reported back instead of followed and needs a fresh approval. Neither tool is a way around your permission policy or the shell sandbox. Interactive page work is a different surface: the built-in browser tools drive a real, isolated browser, with their own page and their own approvals.

• websearch, discovery through the configured search service; the query appears in the approval prompt.
• webfetch, one HTTP(S) URL; the host appears in the approval prompt, internal addresses are refused, and an off-origin redirect needs a new approval.
• Ask requests consent for web and MCP calls. Auto allows ordinary web lookup and sends eligible MCP approval effects to the approval reviewer. Full can settle ordinary consent for both; explicit rules, trust gates and network restrictions still apply.

Related

• Permissions & safety
• Browser & computer use
• Configuration
• Providers & models