Tools and MCP servers

The Tools & MCP servers page controls what your agents can call. An MCP server is the upstream service that really runs a tool, for example a payments service. An exposed tool is one of that server's tools made available to agents through the Gateway, with the K-Block action your policies decide on and, optionally, where the call's amount is.

Agents never reach the upstream server directly. They call the Gateway, the Gateway decides, and only allowed or approved calls are forwarded. See Tools and MCP servers for the concepts.

Who can do what

The Cloud API enforces these rules. A developer who tries an owner or admin change gets ADMIN_REQUIRED. Management API keys with the tools:write scope have the developer's rights: they can never enable or authorize a tool. See Roles and permissions.

Register an MCP server

1. Open the form

   On Tools & MCP servers, select Register MCP server.

2. Fill in the server

   Field	What to enter
   Name	A name unique in the organization.
   URL	The server's Streamable HTTP endpoint, for example https://tools.example.com/mcp.
   Authorization header (optional)	The complete Authorization header value the upstream expects, for example Bearer …. It is stored encrypted and never shown again.
   Server KID (optional)	Only for K-Block-aware upstreams that verify evidence and sign attestations. When you enter one, also paste the server's public identity documents (a JSON array) under Server identity documents, unless K-Block already knows that KID.

3. Register

   Select Register server. The dashboard opens the new server's page, where you discover its tools.

URL rules

• Use a public https:// URL. K-Block connects only to public https addresses: private, loopback and link-local addresses, and plain http://, are refused with URL_NOT_ALLOWED. If your MCP server is reachable only on a private network, make it reachable at a public https:// address first.
• No user name or password in the URL. Put credentials in the authorization header.
• No query (?…) and no fragment (#…). The URL is signed into every approval request and receipt of the server's calls, which cannot be redacted. A URL with a query is refused with URL_NOT_ALLOWED.

Discover tools

On the server's page, Discover tools asks the upstream for its tool list (tools/list). The Cloud API makes this request, under the same address rules as above, and sends the stored authorization header. The result lists each tool's name, description and input schema. A tool that is already exposed shows which exposed names it has.

Discovery exposes nothing. Select Discover again to refresh the list.

What can go wrong:

If the upstream reports no tools, the page says so. Check the server and discover again.

Expose a tool

Next to a discovered tool, select Expose… and fill in the form:

The action, amount pointer, currency and currency pointer are policy inputs: they decide what your policies and delegations allow. See Expose and map tools and Rules, amounts and currencies.

Drafts and enabled tools

• An owner or admin selects Expose tool. With Enabled checked (the default), the tool is enabled at once and its binding is authorized as it is now. Agents can call it while its server is active.
• A developer selects Save as disabled draft. The tool is saved disabled, and agents cannot call it until an owner or admin reviews it and enables it.

When tools are disabled, a note on the tools page counts them. It tells developers that only an owner or admin can enable a tool, and tells owners and admins to enable a reviewed tool with Edit, then Enabled.

Each exposed tool has a state badge:

Edit a tool

Edit on a tool row opens the same form, with Save tool. While a tool is enabled, a developer cannot change its action, exposed name, description or amount mapping: those fields are read-only for them. To change them, the developer saves the tool disabled, and an owner or admin enables it again.

An owner or admin cannot enable a tool in the same save that changes a policy input. Save the changes with the tool disabled, review the tool, then enable it.

K-Block cannot delete a single exposed tool in this version. Disable a tool to stop agents from calling it. Deleting a server that no call has used deletes its tools with it (see Delete a server).

Authorize and re-authorize a binding

A tool's binding is everything the owner's or admin's consent covers: its MCP server, the server's URL, server KID and credential, the upstream tool name, the action, the amount mapping and the input schema. Enabling a tool pins the binding as it is at that moment.

Any later change of a bound field, by anyone including an admin, makes the tool stale. For example, changing the server's URL or replacing its authorization header makes every enabled tool of that server stale. Then:

• the Gateway stops listing the tool to agents and refuses its calls with TOOL_REAUTHORIZATION_REQUIRED;
• the tools page and the Overview's Needs attention card list it;
• an owner or admin must authorize the binding again.

To authorize, select Review & authorize (or Review & re-authorize for a stale tool) on the row. The review shows the upstream (server, URL, server KID, whether an authorization header is stored, upstream tool), the policy inputs (action, amount, input schema) and the binding digests. Select Authorize this binding or Re-authorize this binding.

The digest you reviewed is the digest the dashboard sends. If the binding changes between loading the review and confirming, nothing is authorized and the API answers BINDING_CHANGED. The page reloads the tool so you can review it as it is now.

Server settings

On a server's page, owners, admins and developers see Server settings:

• Name and Status. A disabled server's tools are not callable.
• URL and Server KID.
• New authorization header (optional), and Remove the stored authorization header.

Select Save server to apply the changes.

While the server has enabled tools, only an owner or admin can change its URL, server KID or authorization header. For developers those fields are read-only. The page warns when a change will make the server's tools need re-authorization.

Moving a server that stores an authorization header to another origin (scheme, host or port) requires entering the header again in the same save, or removing it. The stored header is never sent to a new origin.

Delete a server

The Delete this server card says that deletion is only possible while none of the server's tools has a recorded protected action. Delete server asks for confirmation, which repeats this, then deletes the server and its exposed tools.

Common errors

More codes: Error codes and Gateway and tools.

Next steps