Tool Manifest
The declared set of tools, resources and prompts an MCP server exposes to a client — the machine-readable statement of what an agent is able to reach.
Why it matters
This is the first widely adopted artifact where an agent's reach is declared rather than assumed, and it should be treated as a controlled document: versioned, reviewed, and diffed on change. It is not, however, an authorization.
What it is not
These are routinely confused with Tool Manifest. The distinctions are not pedantic — each one has consequences for how a system is governed.
A manifest says what the agent CAN reach. A grant says what it MAY commit, under whose authority, and up to what limit. Reading a manifest as a permission boundary is the most likely agentic governance error of the next two years.
The manifest faces inward, toward the agent's own tools. The card faces outward, toward other agents.
Relationships
Typed edges into the rest of the ontology. These are what make the canon traversable rather than merely readable.
| Verb | Target | Meaning |
|---|---|---|
dependsOn | MCP | The subject cannot function correctly without the object. |
notEquivalentTo | Authority Grant | The two are routinely conflated and are distinct. |
addresses | Authority | The subject speaks to the object as a question or concern. |
Record
| Canonical identifier | QIS-TERM-00006 |
| Status | Canonical industry term |
| Adoption | Widely used |
| Domain · Layer | Capability · Intelligence |
| Origin | Model Context Protocol; equivalent constructs in most agent frameworks. |
| Semantic aliases | None recorded. |
| First published | 2026-08-02 |
| Last reviewed | 2026-08-02 · 180-day cycle |
Cite the identifier, not the URL. Identifiers are stable; URLs may change. This entry is free to read, quote and index under the dual license. Corrections to [email protected] are published.