Tools and MCP servers

K-Block sits between your agents and the tools they use. The tools themselves live on MCP servers you already run or use (the upstreams). You register each upstream once, choose which of its tools agents may call, and give each exposed tool a K-Block action that policies and delegations refer to.

Agents never talk to the upstream directly. They call the exposed tool on the Gateway, which decides the call, forwards it to the upstream only when it may run, and records the outcome.

MCP servers

An MCP server record tells the Gateway where to send calls and how to authenticate to the upstream.

The URL is signed into the evidence of every call to the server's tools, and receipts cannot be redacted. That is why tokens must never be put in the URL: use the authorization header instead. A URL with a query is refused with URL_NOT_ALLOWED (reason URL_QUERY_NOT_ALLOWED).

A URL that breaks the address rules is refused with URL_NOT_ALLOWED as well. K-Block only connects to upstreams at public https addresses, so an MCP server that is reachable only on a private network cannot be used as an upstream.

The stored credential

The authorization header is stored encrypted, bound to the server's ID, and is never returned by the API or shown again in the dashboard (you only see whether one is set). The Cloud API sends it unchanged during discovery, and the Gateway sends it unchanged with every executed call.

The credential is also bound to the upstream's origin: if you move a server that holds a credential to another scheme, host or port, you must send the header again in the same request (a new value, or an explicit removal), otherwise the change is refused with VALIDATION_FAILED (issue AUTH_HEADER_REQUIRED). Nobody who can edit a URL can redirect the stored credential to a host of their choice.

Discovery

Discovery connects to the upstream as a real MCP client (with the stored credential, through the same outbound address checks) and reads its tools/list: up to 20 pages and 2,000 tools. Discovery reads; it changes nothing. In the dashboard, open the server and select Discover tools; each discovered tool shows whether it is already exposed.

Delete or disable a server

Owners, admins, developers and management API keys with tools:write can delete a server. Deleting also deletes its exposed tools, but once any of its tools has a recorded protected action the delete is refused with IN_USE, because the records of those actions are kept. Disable the server instead. The dashboard's Delete this server card and its confirmation say so before you delete.

Exposed tools themselves cannot be deleted in this version; disable a tool you no longer want agents to call. Tools, disabled ones included, count toward the organization's plan limit.

Tools

A tool, in K-Block, is an upstream MCP tool exposed to agents under a name of your choice and mapped to an action.

Action mapping

The action is what policies and delegations speak about. A policy rule matches actions (and optionally exposed tool names); a delegation grants actions. Several tools can share one action, for example the refund tools of two payment providers can both be refund.create.

Amount and currency

An amount mapping prices each call so that policy rules with amount conditions (for example "require approval above 100 USD") and a delegation's spending limit can apply.

• The value at the pointer must be a non-negative decimal string (for example "125.50") or a non-negative whole JSON number. Anything else, such as a fractional JSON number, is denied with INVALID_AMOUNT.
• If the pointer finds nothing, the call has no amount. Policy rules with an amount condition then fail closed: deny and require_approval rules match, allow rules do not.
• Without a currency pointer, the amount is always read in the tool's currency, whatever the call says. With a currency pointer, the call must name exactly the tool's currency at that pointer, otherwise it is denied with INVALID_AMOUNT and never reaches the upstream.
• A call without an amount (the tool has no amount mapping, or the pointer finds nothing) is priced as zero in no currency (XXX). A delegation with a spending limit denies such calls; see Delegations.

Rules are covered in Rules, amounts and currencies.

Who can configure tools

The exposed name, action and amount mapping decide how a call is judged, so putting them into service needs an owner's or admin's consent:

While a server has enabled tools, only owners and admins can change its URL, server KID or credential.

The binding pin

A tool's binding is everything that decides where its calls go, as whom, and what the policy and the approver decide on:

• the MCP server, its URL, its server KID and the version of its stored credential (every set, replacement or removal of the credential counts, even with the same value; the credential itself is never part of it);
• the upstream tool name, the action, the amount mapping (with the currency pointer) and the input schema.

K-Block computes a binding digest (a SHA-256 hash) over these fields. When an owner or admin enables or authorizes a tool, the current binding is pinned. The tool's binding status is then:

The tool's exposed name, description, enabled flag and the server's status are not part of the binding.

To bring a stale tool back, an owner or admin opens Tools & MCP servers, selects Review & re-authorize on the tool's row, checks what changed and confirms Re-authorize this binding. The request carries the digest that was reviewed; if the binding changed again in the meantime, it is refused with BINDING_CHANGED and nothing is pinned.

When a tool or server changes after approval

Every decision records the binding it was made under, and the signed proposal names the upstream URL, server, upstream tool and action. So an approval covers the tool as it was when the call was decided, not whatever it later becomes:

• A new call to a stale or unauthorized tool is refused with TOOL_REAUTHORIZATION_REQUIRED before anything is recorded.
• An approved call whose tool binding changed after the decision never executes, even if the change is reverted. While the tool is stale, each retry is refused and the approval is not consumed: with UPSTREAM_CHANGED when the server, URL, upstream tool or action now differs from the signed proposal, otherwise with TOOL_REAUTHORIZATION_REQUIRED. Once an owner or admin re-authorizes the tool, the next identical call closes the old action as superseded and gets a new decision (and, if the policy requires it, a new approval request).
• A mismatch between the signed proposal and the current tool (server, URL, upstream tool or action) never executes either: an action a person approved is refused at execution with UPSTREAM_CHANGED (nothing is sent upstream), and a pending action or one the policy allowed is closed as superseded on the next identical call.
• A call allowed by policy but not yet executed is also re-decided when the agent's policy version, the tool's exposed name or its amount mapping changed.

The approval views tell approvers when the upstream changed since the decision. See Approvals.

How a tool reaches an agent

The Gateway lists a tool to an agent (tools/list) only when all of these hold:

1. The organization has a principal.
2. The tool is enabled and its MCP server is active.
3. Its binding is authorized and its server URL can be signed (no query, fragment or credentials).
4. A valid delegation of the agent grants the tool's action.
5. Its input schema is an object schema.

The policy is not consulted: a tool whose calls the agent's policy denies is still listed. The list is not a gate either: a call that names an enabled tool on an active server goes through the decision even when that tool is not in the agent's list (for example, one left out because of its input schema).

A call names the exposed tool. A name that matches no enabled tool on an active server is refused with UNKNOWN_TOOL and nothing is recorded. Otherwise the call is decided and, apart from a few refusals listed in Actions, recorded as an action.

Next steps