Sources

What a source is

A source is something Inline can reach on your behalf: a connected MCP server, or a REST API you registered from an OpenAPI description. Both appear in one list on the Sources page, because both become tools and a server can mix them freely. The only remaining difference is who makes the call. Inline makes a REST call itself, with the key sealed in your workspace, and that is plumbing rather than something you compose around.

The credential stays with Inline

This is the part worth being precise about. When you connect a source, the token or key is stored by Inline and is never handed to the agent. The agent gets a tool it may call; the credential is applied at call time, on the other side of the gateway. An agent cannot tell whether a tool it is calling is backed by an MCP account or an API key, because Inline picks the right credential per call.

An API key registered on the REST API page is sealed with your workspace’s key, exactly like the credentials for services you connect, and stored in your workspace. It is not written to a log or to anything an agent can read, and it cannot be read back out of the form afterwards. It is removed when you delete the API or when the workspace is erased. Inline cannot revoke it at the service that issued it, so revoke it there if you no longer want it to work.

Disconnecting your own account from a source deletes the stored credential. Its tools stop working for you, and for any agent using a key of yours; other people are unaffected. Deleting the source itself is heavier: its tools disappear from every server that names them, and the downstream credentials it collected are deleted, and Inline tries to revoke each one at its provider. Many providers offer no way to revoke, and Inline says so when that is the case.

Administrators get a Stored credentials panel at the top of the page reporting how the tokens and secrets Inline holds are protected at rest. If no encryption key is set on the deployment, it says so plainly and offers to encrypt what is already stored once one exists.

Which key seals those credentials depends on the plan. By default every workspace’s stored credentials are sealed under a key shared with other workspaces, with the workspace bound into each value sealed in the current format; that keeps workspaces apart, but one workspace cannot make its credentials unreadable by destroying a key it does not own. On plans that include it, a workspace has a key of its own, made and held by us in Cloud KMS: you cannot hold, disable or destroy it yourself. When the workspace is erased its key is destroyed, and after a 30-day window in which the destruction can be undone, the stored credentials and secrets sealed under it cannot be opened by anyone, us included. Erasure is done by a person after a closed workspace’s 30-day grace period, with no fixed deadline yet, and a closed workspace keeps its key until then. There is no self-serve destroy button. The limits: it covers stored credentials and secrets only (REST API keys you register are among them), not tool-call arguments, script source and results, audit rows or workspace settings; it takes effect once the move to your own key has finished, and values stored earlier are under the shared key until then; and backups taken before then keep a copy under the shared key for 7 days (daily) or 98 days (weekly), with database point-in-time recovery keeping earlier versions for 7 days as well. The pricing page states the same limits next to the plans.

Who connects it, and who may use it

Connecting your own account to an MCP server needs nobody’s approval — you authorise only yourself, and the credential is stored against your email alone. Registering a source is an admin action, because it puts something in front of everyone.

When adding a server you choose between two models. Either each person connects their own account, authorising their own login; or one shared account serves the whole organisation, connected once by an admin and disconnectable only by one. To hold several accounts on the same software, register the server more than once and put the account in the name — “Asana (AU)”, “Asana (FMRS)” — since a server’s tools are named after it.

People on a source decides who may use it at all. Empty means everyone who can sign in. A server shared with a group still serves each person only the sources they may use.

Picking tools and rules per source

Each MCP source has an Edit tools view listing the tools it offers, with a switch per tool. Each tool also carries what it does to data, which is what lets a server limited to reading hide the tools that write, and can be restricted to named people.

Rules set on a source apply wherever that source’s tools are called, on every server, and before that server’s own rules.

Popular sources

The catalogue on the page is not a set of integrations. Each entry is the URL, the scope and the setup somebody would otherwise reconstruct from search results, researched from the provider’s own documentation and live sign-in metadata. It matters because a vendor may run several MCP servers and choosing the wrong one is not recoverable.

Some providers allow self-registration only for loopback redirect URIs, so a hosted deployment needs an OAuth app created by hand. When a connection attempt discovers that, Inline opens a form with the exact redirect URI to paste into the provider’s console and fields for the client ID and secret that come back.

Organization model keys

Scripts running on a server can ask a language model. One way to pay for that is an organisation key: an OpenRouter key the organisation owns, added here and assigned to particular servers. A script uses one only on the servers it is assigned to. Spend is shown for the month, by server and by person. Unassigning a key stops that server’s model calls until its owner chooses another source.

Call limits

A limit is a number of tool calls, over one of four windows: per minute, per day, per month, and per person per day. It can be set on a server, on a source, and once for the whole workspace, and the tightest of the three is what applies.

The workspace limit is an owner’s to set and an admin’s to read, and it is shown on this page because a cap set on a source looks as though it did nothing whenever a stricter number above it is what is actually biting. Every limit is displayed with its usage — what has been used, what is left, when the window resets — and each row says which level is in force.

Beside it sits one workspace-wide switch: whether a call held for approval may be decided by the person whose key the agent used, or must go to somebody else. Set there, no individual rule can take it back.