What Inline is

The problem it addresses

An assistant connected to your company’s systems is handed an enormous number of possible actions. One OpenAPI description can carry a few hundred operations. Three or four connected accounts and the assistant is choosing, on every turn, from a list nobody has read. The question stops being “can it reach the data” and becomes “which of these thousands of actions is it allowed to take, on whose account, and how would anyone know afterwards”.

Inline is the layer that answers that. You connect the systems; Inline decides, per person and per tool, what may be called; agents get an address that serves only what they are allowed. Every call is written down.

What goes in

Two kinds of thing. A REST API — an OpenAPI description you already maintain, plus a key you hold. And an MCP server — Asana, Notion, or one you run yourself. Both end up as the same thing: tools with names, owners and limits. On the Sources page they sit in one list, because the only real difference is where the call is executed.

What comes out

Either a scoped MCP endpoint, with its own URL and its own tool list, or a scoped key for code that speaks HTTP. In both cases the agent gets never more than the person behind it can already reach, so handing one over gives away less than handing over an account.

The nouns you will meet

Sources are the connected accounts and registered APIs. A source holds the credential — Inline stores it, the agent does not see it, and disconnecting the source stops every tool built on it. See Sources.

Tools are the individual actions an agent can call. You get them by ticking operations out of an API description or tools out of a connected MCP server. What you do not tick is not hidden or discouraged; it was never registered, so there is nothing to call. See Tools.

Servers are named handfuls of tools, each at its own address. This is how you give the finance assistant and the sales assistant different shelves. A server also carries what agents may do on it — read only, read and create, read create and update, or everything — and tools that do more than that are refused even if an agent calls one anyway.

Apps are whole processes: one named tool that carries several steps, and sometimes its own screen. Apps in your workspace are tools your agents can call under a grant they cannot exceed. Under Browse you can add a process somebody else built; under Publish you list one of your own.

Rules are conditions applied to every call, whichever door it came through. A rule can force or require an argument, block a tool with a message, redact a field out of a response, ask a webhook, or hold the call until a person approves it. Rules live on a server or on a source; a source’s rules apply wherever its tools are called, before the server’s own.

What happens after a call

A held call waits in Approvals with its arguments visible, naming who has to decide and when it lapses. Undecided calls expire after 24 hours. Everything else lands in Activity: who ran it, against which account, with what arguments, how it ended, and whether it went through MCP, HTTP or a script. Live sessions are visible while they are still running. Checkup reads the workspace as it actually stands and says what is wrong right now.

People is where colleagues, groups and roles live, and where you decide which group gets which servers.

The claims on Security map onto these same screens, and How it works walks the same path in order.