Connecting an assistant

MCP (Model Context Protocol) is the standard assistants use to talk to outside systems. Eel exposes a server, so a compatible assistant can work with your data without you writing any integration at all.

POST https://api.eel.software/mcp

How it connects

The credential is the usual one, in the usual header:

• An API key for the assistant to act as the workspace.
• A connected app token for it to act as a person.

A client that speaks the protocol needs no configuration: it hits the endpoint with no credential, gets a 401 pointing at the authorization metadata, and runs the OAuth flow on its own.

Several workspaces, one connection

The full detail, including adding or removing workspaces after connecting, lives in Workspaces in MCP.

When you authorize a connected app, the consent screen offers a checkbox for each workspace you can grant, and you can tick more than one. Whichever checked workspace comes first in the list becomes that connection's default workspace; the rest are just as authorized.

That is why every tool accepts one optional argument, which changes nothing for anyone using a single workspace:

workspace?: string   // id or slug; omitted = the connection's default workspace

Leave it out and the call acts in the connection's default workspace. Pass it and the call acts in that other workspace, as long as the connection is authorized there; if it is not, the call fails with an error naming the authorized workspaces, so the model knows what to try next. nest_list_workspaces is how to check ahead of time: it marks authorized: true on the ones this connection may act in, which is not the same as merely belonging to them.

This argument only shows up for a connected app. An API key stays tied to one workspace, so its tools never carry it.

Widening or narrowing a connection's workspaces later happens in Nest, under Connected apps, with no fresh authorization needed from the assistant's side.

Transport details

Worth knowing before choosing a client:

• POST only. GET and DELETE answer 405. There is no SSE.
• No sessions. There is no Mcp-Session-Id, and nothing holds state from one call to the next.
• JSON responses, not an event stream.

The catalogue trims itself

A connected assistant does not see the whole catalogue: it sees only the tools your credential may call. A tool you lack the scope for never appears in the list at all.

That saves you trouble. A model that sees a tool and gets told "you cannot" tends to insist, invent workarounds, or tell the user something broke. A model that never saw it works with what is there.

A key holding no known scopes gets an empty server.

A connection authorized before a tool existed does not see it either. Approve its new permissions in Nest, under Connected apps. The tool appears in the catalogue the next time the assistant connects. If you want it now, disable and re-enable the connector: no new authorization needed.

Your credential sets the limits

Connecting an assistant widens nothing about what you can do. Every call is verified again by the app that serves it, with the same credential and the same rules as the HTTP API.

Which is why a reference to something you cannot read comes back marked restricted rather than showing its contents.

What differs from the HTTP API

Very little, but two real things:

• Booleans are booleans. On the HTTP routes some parameters arrive as the strings 'true' and 'false'; in the tools they are the type they look like.
• Each app applies the rate limit, not the MCP endpoint.

Keep in mind too that the endpoint's own errors do not quite follow the API's code table. A disallowed method, for instance, answers 405 with the code invalid_request.