Signed agent-incident classification vs PP-26-4396, with third-party notification receipts.
Scored across 3 tools
classify_incident is a clear write action, while get_flags and get_registry are both reads but target different resources (private per-operator flags vs. public aggregates). The two 'get' tools could momentarily be confused since both return derived metadata, but the descriptions draw a workable line between them.
All three tools follow a clean verb_noun pattern (classify_incident, get_flags, get_registry) with consistent snake_case and verbs that match their action type.
Three tools is at the thin edge for a service whose name implies classification plus notification. Each tool is justified, but the surface feels under-built for the stated scope.
The server name promises notification, yet there is no notification or subscribe tool at all. There is also no way to read back an individual incident or verdict, list incidents, or correct a misclassification, leaving agents with dead ends after classifying.
Classify an incident record (first verdict per operator free, then $0.49 via x402 on the HTTP surface)
| Name | Required | Description | Default |
|---|---|---|---|
| record | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the pricing/x402 behavior, but not whether classification mutates state, what happens on a non-HTTP surface, what auth is needed, or what the verdict looks like – all critical for a tool whose name implies producing a judgment on a record.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single short sentence with no filler, which is good, but the emphasis is misplaced: pricing occupies the only explanatory slot while the functional contract is left implicit. Shortness here reflects under-specification rather than tightness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A nested-object input with no schema descriptions, no annotations, and no output schema demands a much fuller description. Missing are the verdict classes, the record's expected structure, and the response format – an agent could not reliably call or interpret this tool from the definition alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one required parameter, 'record', a nested object with 0% schema description coverage, and the description says nothing about its shape or required fields. Given the nested object, the description should compensate but does not; it only restates the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the verb 'classify' and the resource 'an incident record', which does separate it from the read-only siblings get_flags and get_registry. However, it never says what a verdict is, what classes exist, or what the tool returns, so the purpose is only half specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical gives billing conditions (first verdict free per operator, then $0.49) but no guidance on when to call this versus get_flags or get_registry, no prerequisites, and no exclusions. An agent learns nothing about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Definition-diff flags for your verdicts
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, yet it says nothing about whether the call is read-only, how many flags come back, whether results are scoped to a session or tenant, or what a 'flag' contains. The plural noun weakly implies a read-only list, which is the only behavioral signal present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and front-loaded, but its brevity comes from under-specification rather than economy. The single fragment omits the verb and object that would give it meaning, so there is no wasted wording but also no useful lead.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero annotations, no output schema, and no parameters, the description is the only source of context and it leaves the return shape, scope, and relationship to sibling tools entirely undefined. For a tool an agent would otherwise have to guess at, this is a substantial gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the empty schema is fully self-describing, so there is nothing for the description to clarify. Baseline 4 applies for a no-parameter tool, with the caveat that no implicit scoping (e.g., which verdict set is consulted) is explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun fragment ('Definition-diff flags for your verdicts') with no verb and no plain-language statement of what is retrieved. 'Definition-diff' and 'verdicts' are unexplained jargon, so an agent cannot tell whether this returns drift reports, rule changes, or something else, nor distinguish it from get_registry or classify_incident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no statement of prerequisites, and no reference to the sibling tools get_registry or classify_incident. The phrase 'for your verdicts' faintly suggests it relates to prior classification output, but this is inference, not instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public aggregate registry (counts and categories only)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. 'Public aggregate' suggests a safe, non-mutating read, but the description says nothing about authentication, rate limits, freshness of the counts, or whether the aggregate is scoped/cached — all meaningful for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact clause with no filler and the key qualifier ('counts and categories only') stated up front. It is efficient, though the terseness edges toward under-specification rather than pure conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is the only source of information, and it leaves substantial gaps: it does not say what entity the registry describes, what the 'categories' are, or the shape of the returned counts. For a zero-param introspection tool this is thinner than an agent needs to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description correctly signals that no filtering inputs are accepted by framing the result as an unparameterized aggregate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a resource ('public aggregate registry') and scopes it to 'counts and categories only', which tells the agent it returns summary data rather than records. However, it never says what the registry is a registry of, and it makes no attempt to distinguish itself from the siblings classify_incident and get_flags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no mention of alternatives, and no prerequisites. The adjective 'public aggregate' weakly implies a summary-introspection use case, but the agent must infer when to prefer this over the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
classify_incidentget_flagsget_registryAgent Incident Relay MCP — Article 73 5-clock broadcaster. One incident → simultaneous signed
Signed verdict receipts recovering a fleet's gatekeeper category, plus appeal packets.
Signed receipts + horizon statements proving whether an event-triggered agent actually woke.
Agent completion verification with defects, corrections, and evidence receipts.
Add one secure layer between your agents and this server.