HOW IT WORKS

From an account you already have to a tool you can hand over.

Eight steps, in the order you would actually do them. Nothing here is a roadmap item — every one of these is a screen in the product today.

THE EIGHT STEPS

Connect a source

Sign in to Gmail, Notion, Stripe — whatever the work actually happens in. The credential is stored once, by Inline, and is never handed to the assistant. Revoking it here revokes it everywhere it was used.

Or hand over an API description

Upload the OpenAPI file you already maintain. Inline reads it and shows you every operation in it — often a few hundred — so you can pick the handful an assistant is allowed to reach.

Package a process into one tool

Taking on a client is a folder, a CRM page, an email and a checklist. Describe that sequence once and it becomes a single named tool. The assistant stops choosing the order because there is nothing left to choose.

Give the tool a screen

Some steps need a human: a file to upload, a date to pick, a total to check before it goes. The tool can carry its own interface and open it inside the conversation, instead of sending somebody to another tab.

Compose a server

Group the tools an assistant should see into one MCP server and hand over its address. Different servers for different jobs, so the sales assistant and the finance assistant are not looking at the same shelf.

Hold back what needs a person

Mark the calls that should never go through unattended. Those stop and wait in Approvals with the arguments visible, and whoever is named on the rule lets them through or does not.

Watch it run

Every call an assistant makes is written down — who ran it, against which account, with what arguments, and how it ended. Sessions are visible while they are still going, not an hour later.

Hand it to the people who need it

Add colleagues, put them in groups, and give each group its own servers and its own rules. Two-step verification is available to every person; requiring it of a workspace, and sign-in with your company’s identity provider, are set up with us.

THE STEP THAT DOES THE WORK

An API description is a list of everything. A tool is a decision.

Most API files describe hundreds of operations, and an assistant handed all of them will eventually find the destructive one. Choosing is the product: you say which operations exist, under what name, and who may call them.

Pick operations one by one, or by tag
Give the API one name, used in every tool it publishes
Scope each tool to a group, a server, or one person
Anything you did not pick cannot be reached at all

clients-api.yaml           312 operations

  [x]  POST   /clients
  [x]  POST   /clients/{id}/plan
  [x]  GET    /clients/{id}
  [ ]  DELETE /clients/{id}
  [ ]  ...308 more, unticked

  published as   new_client_onboarding
  visible to     Sales

WHAT IT CONNECTS TO

The systems the work already lives in.

Sign-in based sources for the software your company runs on, and your own OpenAPI file for everything internal. Both end up as the same thing: tools with names, owners and limits.

Gmail
Notion
Stripe
Drive
Asana
GitHub
+ your own API

Where to go next

MCP APPS The screen that opens in the conversation What one is, and why a chat window on its own cannot collect a file or hold an approval. SECURITY Where the credentials actually live Scoping, held approvals, the audit log, and what happens when you install somebody else's process. WHY IT EXISTS More tools was the wrong direction The argument behind all of this: why a process, not an endpoint, is the useful unit to give an assistant. START Connect one source and try it The free plan is enough to run a real process against real accounts.