Getting started

Sign in

Inline signs you in by email. Enter a work email and a one-time link arrives in the inbox; it expires in an hour. There is also a Google button if the workspace uses it. No password is set at any point.

Only people an Inline admin has added can sign in. If you belong to more than one workspace you are asked to choose one after the link opens, and you can create your own instead.

Connect a source

Sources is the list of everything Inline can reach on your behalf. It holds both kinds of thing — MCP servers and registered REST APIs — in one list, because both become tools.

The quickest start is Popular sources, a catalogue where the address and the setup have already been worked out. Some connect straight away; others need an OAuth app created in the provider’s own developer console first, and the entry says which, showing the redirect URI to paste and asking for the client ID and secret it issues.

To add something not in the catalogue, use Add an MCP server. You give the server’s URL — Inline probes it, works out how it wants to be authenticated, and reads its tool list — and a name, which has to be distinct because the server’s tools are named after it. Then you choose whether each person connects their own account, or whether one shared account serves the whole organisation.

Or register an API you already have

If the system is yours, Add a REST API instead, and the REST API page walks three numbered steps.

Step one loads the specification: drop an OpenAPI 3.x file, or give a URL. A GitHub /blob/ link is rewritten to the raw file automatically. Inline reads the operations out of it and stores nothing yet.

Step two is the list of every operation in the specification, with tickboxes. Only what you tick here can ever be called, including operations added to the spec later.

Step three names it and says who may call it. The name has to be lowercase with no spaces, because it appears in every tool name for this API. You give the target base URL — pre-filled from the spec, and every call is prefixed with it — and the API key or token, which is sealed in your workspace and cannot be read back on that page afterwards. You list the people who may call it at all, pick a token lifetime, and optionally restrict calls to a CIDR range. Then Register API.

Compose a server

A server is a named handful of tools at its own address. From Servers, New server asks for a name, what agents may do on it — read only, read and create, read create and update, or everything — and which tools it carries. Only tools you can reach are listed, and they are checked again when you save. Tools that do more than the level you chose are greyed out, and refused if an agent calls one anyway.

This is the step that makes the difference between an agent seeing one API’s ninety-odd endpoints and seeing the four you meant.

Connect an agent

Overview has a Connect an agent section with the addresses. Add one as a custom connector in your MCP client; you are asked to sign in, and you get exactly what you are allowed. A server has its own address instead, on its Connect button. There is more in Connect an agent.

Watch it run

Overview shows recent activity and counts — sources connected, tools you can call, servers, calls logged — and each count links to the page behind it. Activity is the full log, filterable by person, server, tool, outcome and how the call was made. If a rule held a call, it is in Approvals with its arguments visible, waiting for whoever the rule names.

Checkup is worth opening once the first tool works. It reads what the workspace actually holds and lists what is wrong right now, marking which lines are worth fixing and which are only worth knowing.