Documentation
The tool manifest
Updated: 2026-08-05
Integration scope drifts because "connect our CRM to Claude" is not a specification, and by week two the definition of the job has quietly changed three times. The tool manifest fixes that in one page. It is the single artefact both sides sign before any code, and every change to it after signature is a change order with its own number.
The fields
Each tool in the manifest carries the same six fields. Nothing more, because more fields become boxes nobody fills honestly.
| Field | What it pins down |
|---|---|
| name | The verb a user would say, not your endpoint path |
| inputs | The arguments, and which are required |
| outputs | The shape the model gets back |
| access | read or write, and there is no third option |
| source | The system and role the data comes from |
| scope | The permission boundary, named explicitly |
A worked example
Here is a real manifest fragment for a commerce build, current as of the 2026-07-28 revision.
- name: orders.search
access: read
inputs: [query, limit]
outputs: [order_id, status, total, placed_at]
source: postgres:read_replica
scope: store:read
- name: order.flag
access: write
inputs: [order_id, reason]
outputs: [order_id, flagged]
source: orders-api
scope: store:write:flags
dry_run: required
destructive: falseHow it maps to the contract
The manifest is an appendix to the statement of work. The build is complete when every tool in it passes the acceptance script, and a tool that is not in it is not in the build. When you want a new tool later, we quote it against the same six fields, which is why the price of a change is never a surprise.
Common mistakes
- Too many tools. Eighty endpoints become eighty tools become a worse interface.
- Ambiguous verbs. "manage" is not a tool; "order.flag" is.
- Unbounded writes. A write with no dry-run and no scope is a liability, not a feature.