MCP client
Zed and stdio-only clients — connecting through the mcp-remote bridge
A client that only launches local processes cannot reach a Streamable HTTP server directly. The mcp-remote bridge runs locally and forwards, OAuth and all.
Karl-Gustav Kallasmaa, Founder & CEOLast updated What you configure
The exact settings, as our documentation publishes them.
// Zed settings.json
{
"context_servers": {
"attensira": {
"source": "custom",
"command": "npx",
"args": ["-y", "mcp-remote", "https://mcp.attensira.com/mcp"]
}
}
}
Connecting it
In order, with the reason each step exists rather than only the instruction.
- 1
Understand why a bridge is needed
The Attensira server speaks Streamable HTTP only. Clients that speak remote HTTP natively connect directly; clients that only launch local stdio processes cannot, and need mcp-remote, which runs locally over stdio and forwards to the HTTPS endpoint.
- 2
Point the client at the bridge
In Zed's settings, register a custom context server whose command runs mcp-remote with the Attensira URL. The client launches a local process as it expects to, and the process does the remote half.
- 3
Let the bridge run OAuth
Omit any header argument and the bridge runs the OAuth flow itself, caching the token under your home directory. It needs Node.js, and its first run downloads the package and opens a browser, so allow a few seconds and expect a sign-in prompt before tools appear.
- 4
Check reachability if it stays silent
Request the unauthenticated health path on the MCP host. It answers without a credential, which separates a network or bridge problem from an authentication one when the client says nothing useful.
What it lets you do
- Brings the full Attensira toolset to clients that have no remote-MCP support at all, without any change on the server side.
- Runs the OAuth flow on behalf of a client that cannot, so even a stdio-only editor ends up with a refreshable token rather than a pasted key.
- Works the same way for any stdio-only client, so the pattern transfers to older builds of other editors rather than being specific to one.
What it cannot do
An integration page that lists only capabilities is an advertisement. This is the half you are evaluating.
- The bridge is a local process, not part of the Attensira service. It needs Node.js on the machine, and anything wrong with it presents as a client that shows no tools rather than as a server error.
- The token the bridge obtains is cached under your home directory. That is a credential on disk, so the machine's own security is what protects it.
- A bridged connection still reaches exactly one workspace, chosen at the consent screen, and still cannot be retargeted afterwards.
Not every MCP client speaks remote HTTP. Some only know how to launch a local process and talk to it over standard input and output — which is the original MCP transport, and is still how a number of clients and older builds work. Zed is the documented example, and everything here applies equally to any client in that category.
The mismatch, stated plainly
The Attensira server speaks Streamable HTTP only. There is no stdio server to launch and no plain SSE transport to fall back to. A client that can only start local processes therefore has nothing it can connect to directly.
The bridge closes the gap in the obvious way: it is a local process, so the client is happy, and it forwards to the HTTPS endpoint, so the server is happy. Nothing changes on our side, and nothing about the toolset differs — the same eighteen tools arrive through the bridge as through a native connection.
Registering it
In Zed's settings you declare a custom context server whose command runs the bridge with the Attensira URL as its argument. That is the whole configuration: a command and its arguments, in a shape the client already understands.
Omit any header argument. With nothing supplied, the bridge runs the OAuth flow itself, which is the better outcome — a stdio-only client that would otherwise have forced you into a pasted key ends up with a refreshable token instead. The token is cached under your home directory.
What to expect on first run
Two things happen that do not happen afterwards. The package is downloaded, which takes a moment, and a browser opens for sign-in. So the first start is slower than subsequent ones and involves a prompt, and a client that appears to hang for a few seconds on the first attempt is usually just doing that.
The bridge needs Node.js on the machine. It is a local dependency and not something the Attensira service provides, which is worth knowing because a missing runtime presents as a client with no tools rather than as any kind of error you would connect to Node.
Debugging the extra hop
A bridge adds a place for things to go wrong, so it is worth having a way to divide the problem. The MCP host publishes an unauthenticated health path that answers without any credential. If that responds, the server is reachable and the fault is local: the bridge, the runtime, the command, or the client's own configuration.
That single check saves a lot of time, because a stdio client that fails to start a process typically reports nothing more useful than an empty tool list.
What is unchanged
Everything about the credential works as it does elsewhere. The connection reaches exactly one workspace, chosen at the consent screen, and cannot be retargeted afterwards. Scope is fixed at approval. And the cached token is a credential sitting on disk in your home directory, so the machine's own security is what protects it — which is the ordinary situation for a developer laptop and worth being conscious of on a shared one.
Why this pattern is worth knowing generally
Zed is the documented example, but nothing here is specific to it. Any client that launches MCP servers as local processes and has no remote-HTTP support connects the same way, including older builds of clients that support remote servers today. If you find yourself with a client that cannot see the Attensira server and offers only a command-and-arguments configuration, this is the shape of the answer: point it at the bridge, let the bridge run OAuth, and everything above the transport behaves exactly as it does for a native connection.
Questions people ask
- Why can Zed not connect directly?
- Because the server speaks Streamable HTTP only, and Zed launches MCP servers as local processes. The bridge gives it a local process to launch that speaks HTTP on the other side.
- Does the bridge mean I have to use a key?
- No. Omit any header argument and the bridge runs OAuth itself, caching the token under your home directory. Passing a header is the option, not the requirement.
- Why does the first run take a while?
- The first run downloads the package and opens a browser for sign-in. Allow a few seconds and expect the prompt before the tools appear.
- What does the bridge require?
- Node.js on the machine running the client. It is a local process and nothing about it is provided by the Attensira service.
- How do I tell a bridge problem from a server problem?
- Request the unauthenticated health path on the MCP host. If it answers, the server is reachable and the problem is local.
Sources
Every factual statement above, with the page it came from and the date that page was read.
Attensira's MCP overview states that the endpoint speaks Streamable HTTP only and that a client which speaks stdio alone cannot reach it directly and needs a bridge.
docs.attensira.com · retrieved
“A client that speaks stdio alone cannot reach it directly and needs a bridge”
Attensira's connect documentation states that the mcp-remote bridge runs the OAuth flow itself and caches the token under the user's home directory, and that it requires Node.js.
docs.attensira.com · retrieved
“The bridge runs the OAuth flow itself and caches the token under your home directory”
Attensira's MCP overview states that the server publishes an unauthenticated health path that answers without a key, useful as a reachability check when a client is silent about why it failed.
docs.attensira.com · retrieved
“is unauthenticated and answers without a key, which makes it a useful reachability check when a client is silent about why it failed”