Technology · Discipline

MCP tool design

Tools shaped as jobs, cost stated on every call, every write read back, every create with a delete: the written standard every MCP tool in my estate must meet.

FAFOHive, Helix and the capabilities modelModel Context ProtocolA written standard for every tool
Generated from the vendor specification Shaped like the jobs agents do
83 → 15generated endpoint tools, then job tools
  • ~42,000tokens of tool schema an agent had carried every turn
  • 24meeting tools, each with a minimal exact schema
  • 520characters in the discovery tool's description, held there by a test

Tools shaped like jobs, not endpoints

FAFOHive: when I added in-house social integrations to the tool hub, the fast path was to generate one tool per vendor endpoint. I took it once. The X module's first build compiled its tools straight from the vendor's OpenAPI specification. They were cheap to make, expensive to call and easy for an agent to misuse. I withdrew that surface and replaced it with tools shaped like the jobs agents actually do, trading generated breadth for designed workflow tools with costs and guards.

What agents see · job tools with costs and guardsUnderneath · the generated endpoint catalog, private
Proportions illustrative. Raw endpoints exist only as internal helpers.

A written standard every tool must meet

I wrote the standard every tool in the estate has to meet, and its rulings. Its first rule is that a tool is a job. Errors come back verbatim, and an empty result never stands in for a failure.

A write
RequestServer flagDry runWriteRead back

A write that cannot be read back comes back marked as not confirmed. Every create ships with its delete.

Every description states

its purpose, when something cheaper fits, the exact cost formula, the batch alternative, cache behaviour, pagination cost, side effects, the return shape and its errors.

A failed call returns the status, the provider's code and message verbatim, any nested platform error, whether it was billed, the request with secrets redacted and a retryable flag. Every result carries its cost; secrets never appear.

Cost and repeats an agent can reason about

The X tools state their cost in units and refuse work once the monthly budget is spent.

An agent cannot budget what it cannot see, so every call states its cost.

Monthly budget, in units

Spent: the next call is refused before it reaches the platform.

When the outcome is unknown
An event
redeliveredA social action
never repeated

A lifecycle test through the agent tools alone

The Facebook module proved the standard against a real platform, with nothing allowed to reach it except through a tool.

Every kind of post and media
CreateCheckDelete
Calls through a tool body
allCalls outside a tool body
0
Platform-semantics defects found

The governed gateway these tools sit behind is in Agents with real tools and no keys.

Meeting tools a model cannot misuse

Helix: the meeting action server lets any model act in a Teams meeting as one employee. I wanted a model to be unable to send a malformed or ambiguous command.

A well-formed command
runsMalformed or ambiguous
rejectedUnsupported by Microsoft
typed refusal
minimal exact schema
additionalProperties: false, exact required fields, declared side effects and sensitivity, no model-facing action enums.

See A meeting attendee that will not fake it.

One discovery tool instead of a catalog

Capabilities model: here the design problem was the size of the tool surface itself. The whole schema on every turn became one discovery tool, whose description length is enforced by a test.

Every tool's schema, every turncatalogOne discovery tool1 tool
Its description tells the agent to look before it concludes no tool exists.

See A hundred tokens instead of forty-two thousand.