Connect an agent

The gateway

Inline exposes an MCP endpoint at /mcp on the deployment’s own address. Adding it to a client as a custom connector is the whole installation: you are asked to sign in through the browser, and the tools you get back are the ones your sign-in authorises. Nothing is pasted and nothing is kept secret at the client’s end. The exact address for your deployment is printed on the Overview page, under Connect an agent.

The gateway serves tools from every MCP server you have connected. Endpoints from a registered REST API are deliberately left off it — one API’s ninety-odd operations would crowd out everything else — and are reached through a server or a key that names them.

The full endpoint reference, including the configuration REST API Inline exposes for managing API configurations programmatically, is documented in the app itself at app.useinline.dev/mcp-doc.html.

A server’s own address

Every server has an address of its own, on its Connect button. A session opened there is that server and cannot switch away; its sign-in and its keys work nowhere else. This is the durable option — one connector per server, nothing to remember afterwards — and it is what to use when mixing servers up would matter.

Because the tool list an agent sees at that address is exactly the server’s list, connecting is also how you check that a server is scoped the way you meant.

Two agents, one address, different tools

What an agent sees is a function of the token it holds, not of the URL. Inline decides per person and per tool, so the same gateway address serves a different list to each person who signs in through it, and a server shared with a group still serves each person only the sources they are allowed to use. A key issued for a server reaches that server and nothing else.

For code that cannot sign in — a cron job, a script — a server can issue a key instead, with a lifetime of 30 days, 90 days, a year, or never. The key has no tool list of its own: edit the server and its keys follow. The audit log records the key alongside the person it belongs to. The same tools are also callable over plain HTTP with that key as the bearer, for a language with no MCP client.

Choosing a server inside a session

Two other ways to point an agent at a server, both less durable than connecting to its address.

In any session, including desktop apps, you can say work on Acme to narrow to a server, and work on everything to go back. Called with no arguments, work_on reports the current choice and changes nothing. You can set whether that choice belongs to each conversation separately or to your whole account.

On the command line, a folder can be bound to a server, so a session started in that folder — or anywhere beneath it — is served that server’s tools. The most specific binding wins. Desktop app connectors cannot report a folder, so a binding does nothing there; use work on instead. A server’s own address is never re-routed by either mechanism.

How many tools an agent is shown

A server decides for itself whether it lists its tools or offers a search. Listing suits a handful. Search suits many: the agent asks for what it needs, gets the few tools that match, and runs one with run_tool. When no server is chosen, the same choice applies at the gateway, and the cost of listing everything is that every model pays for the whole list on each turn.

Screens inside the conversation

A tool can carry its own interface — an MCP App — which a host renders inside the conversation rather than sending someone to another tab. Support for that part of the protocol is still arriving and varies by client; tool support itself is broad. A tool built here works either way: where apps are supported you get the screen, and where they are not the agent calls the same tool and asks for the missing pieces in words.