Tools

A tool is something an agent can call in another system — search a corpus, look up a ticket, post a message. Settings → Tools is where an administrator connects the servers that offer those tools and decides, one tool at a time, which of them an agent is allowed to call. Open it with the Settings control in the top navigation bar, then choose Tools under Capabilities.

A new tenant has no tool servers. Nothing is connected until an administrator connects it.

Two kinds of server

The tab is the filter the list route takes, so switching tabs is a fresh request rather than a client-side split.

The Builtin tab says so outright. It states it only when a read actually landed — a failure reports itself rather than showing an empty catalog.

Connect an MCP server

The notice above Authentication is the most important sentence on the form — see below.

Authentication

For OAuth, where the client ID and secret are sent is asked rather than negotiated. A server that accepts only the request body answers a correctly-formed Basic header with invalid_client — the same error it returns for a wrong secret — so no status code can tell the two apart. Set it to match what your server expects.

A credential is write-only: the stored value never comes back, and the form shows only whether one is set. Sending a new value rotates it, one field at a time.

A connected server's card is a summary of everything that decides whether its tools are reachable: its status, when it last synced, how many organizations hold it, and how it authenticates.

Every tool is held for review

This is the property the whole feature is built around. A tool's title, description and schemas are text a third party wrote, and an agent follows them. So nothing a server offers is callable until an administrator has read it and accepted it under their own name.

Three tools discovered, none of them approvable yet — the page approval counts only rows whose text has been on screen.

A row joins the page approval only after its schemas have been opened. That is not a formality: the input schemas are not on the row, so a bulk approval that promoted them unread would put an administrator's name on text nobody saw. There is deliberately no control that marks rows read without showing them.

Opening one row's schemas admits that row and no other. Show what approving all N accepts opens the rest — a shortcut through the gate, never around it.

Approval is per page of the listing, and the button's label carries the count — Approve 0 on this page and Approve 3 on this page are the same control. If tools on another page are still waiting, the tab says so.

Approving accepts a tool. It does not switch it on — those are two decisions.

Approve, enable, effect

Each row carries three things, and all three must line up before an agent can call the tool:

A tool binds to an agent only when it is approved, enabled, and still offered by the server.

When a server changes underneath you

Sync tools re-reads what the server offers. Anything that changed lands as pending, and the row is pulled back into review: the tool keeps running for agents at the text that was approved, while the new text waits for someone to read it.

A rewritten description is shown in plain sight, labelled as not yet accepted, and the approval gate is closed again.

The rewritten text is on the row rather than hidden behind the disclosure, because that is what an administrator has to read before deciding. Approving replaces the approved title and description with the pending ones; the disclosure holds the comparison, so you can see exactly what you are accepting and what you are discarding.

Until then, agents keep binding the approved snapshot. A description rewritten upstream does not reach an agent on its own.

Test connection runs the same handshake and writes nothing — use it to check a URL or a credential without touching the catalog.

Switching a server on and off

Switched on is the administrator's own decision about whether the server should run, separate from the status the last handshake reported. A server that is switched off binds to no agent, whatever organizations it is granted to.

A server can only be switched on once a sync has succeeded against it — until then it is offered to no agent, and the control says so rather than failing silently.

Organizations

An MCP server is connected once for the tenant and then granted to the organizations that may use it. Agents in those organizations' projects can be given the server; an organization removed here loses it immediately.

The checklist is the complete set. Saving with nothing ticked revokes the server everywhere, and the confirmation says so.

The Agents tab answers the other half of that question — which agents currently hold a grant to this server, and therefore what a revoke or a delete would take away. It is a read, so it has a tab of its own rather than only appearing when you start to destroy something.

Grant a server to an agent

Open the agent on the project's Team pane and use its Skills & Tools tab. The picker offers the servers granted to that project's organization; an agent may hold up to 100.

An agent granted a whole server may call every approved, enabled tool on it — or, if you choose Only selected tools when granting the server on the agent's Skills & Tools tab, just the ones you name. Narrowing there is the least-privilege control: the agent is offered nothing else. Each tool reaches the model under a namespaced name — the server's slug, then __, then the tool's own name — so two servers offering a search tool never collide.

Delete a server

Delete is in the sheet header. Before you can confirm, the dialog reads how many agents hold the server and states the count.

Deleting removes the server, its stored credentials, every tool it has discovered, and every agent's grant to it — across the whole tenant, not only the organizations it was granted to. If a delete fails, running it again is safe and finishes what it started.

Field reference

A server may offer at most 500 tools.

Troubleshooting

Related