DOCS · Concepts
Tools
How a specification with hundreds of operations becomes the few named tools an agent is allowed to call, and why the rest are unreachable rather than hidden.
Subtraction, not exposure
An OpenAPI description is written to document everything a service can do. That makes it a bad tool list. Handing an agent three hundred operations costs tokens on every turn, and it puts the choice of which one to call somewhere nobody can review.
Inline inverts the default. You load the description, tick the operations that belong in the job, and the rest are not registered as tools. They are not hidden or discouraged; there is nothing to call. Operations added to the specification later are not reachable either, until somebody ticks them.
Registering an API
Loading the specification is the first step: drop an OpenAPI 3.x file,
or give a URL — a GitHub /blob/ link is rewritten to the raw file.
Inline reads the operations and stores nothing yet.
Then the list, with a tickbox per operation and a running count of how many are selected. This is the decision the rest of the page depends on.
Last, the details that make it callable. A name, lowercase with no spaces, which appears in every tool name for this API. A target base URL, pre-filled from the spec, prefixed onto every call. The API key or token, which is sealed in your workspace and cannot be read back. The list of people who may call it at all — each of whom still gets only the operations they are given, so this list decides who may be given any. A token lifetime, from an hour to never. Optionally a CIDR range, so calls only work from one network.
Changing the lifetime later applies to tokens issued from then on; tokens already out keep the lifetime they were given.
What agents see as arguments
How much of the specification Inline keeps decides how legible the tools
are. Stored whole, agents see each operation’s real argument names and
types. Stored trimmed to the selected operations, the names and types
are still exact. Not stored at all, agents see loose path_params,
query_params and body arguments and have to be told what to pass.
Revoking
Removing an operation from a registered API revokes it everywhere at once, including from any server already holding it, and it stops being callable immediately. Deleting the API stops every one of its endpoints for everyone, including through any server or key that names them, and cannot be undone.
This is the property that makes the tick list worth trusting. There is one place the answer lives, and no copy of it anywhere else to go and revoke.
Scoping who may call what
Picking operations decides what exists. A server decides who sees which of them. A server is a named handful of tools at its own address, holding only tools the person composing it can already reach, and those are checked again on save.
A server also carries a ceiling on what agents may do with them:
| Level | What it allows |
|---|---|
| Read only | Look things up, change nothing |
| Read and create | Add new things, never edit or remove |
| Read, create and update | Everything except deleting |
| Everything | Whatever its tools can do |
Tools that do more than the level are greyed out when composing, and refused if an agent calls one anyway — from a script too. A tool Inline cannot classify counts as deleting, so only Everything includes it.
Endpoints from a registered REST API are served on a server or a key that names them, and are left out of the plain gateway address. See Connect an agent for which address serves what.
Conditions on the call itself
Beyond who may call a tool, rules decide what happens when they do. A rule can force or require an argument, block a tool with a message an agent is shown, redact a field out of the response, ask a webhook, or hold the call until a person approves it. Rules sit on a server or on a source, and a source’s rules apply first.
A held call waits in Approvals with its arguments visible. Approving runs it at once, as the person who asked and within their key, so anything that would have refused it still does. A rule can require that the person deciding is not the person who asked, and the workspace can require that everywhere.
Every call, held or not, lands in Activity with who ran it, against which account, with what arguments and how it ended. Security states the same guarantees in the form a reviewer will ask for them.