Propagation breaker: egress quarantine + fingerprint outbreak telemetry for fleets.
Scored across 6 tools
Each tool targets a clearly distinct function: control verification, outbound message scoring, fingerprint lookup, store read, store write, and telemetry reporting. The read/write pair is explicitly differentiated by direction and the remaining tools do not overlap.
All six tools follow a uniform noun_verb convention (controls_verify, egress_check, fingerprint_query, store_read, store_write, telemetry_report). The pattern is applied consistently across the whole surface with no style mixing.
Six tools is a well-scoped set for a focused propagation-breaking server, covering detection, control integrity, storage, and telemetry without bloat. Each tool earns its place.
Core detection, verification, and telemetry operations are covered, but quarantine management (listing/releasing quarantined items) and explicit fingerprint ingestion are missing. These are minor gaps that the store and egress tools may partially work around.
Verify loop-breaking controls are on and untampered.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full behavioral burden, yet it only implies a read-style verification. It says nothing about permissions required, what a failed or tampered result looks like, side effects, or return format.
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 front-loaded sentence with no filler, so it is appropriately sized. It leans toward under-specification rather than verbosity, which is a completeness concern rather than a conciseness one.
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 verification tool with no annotations and no output schema needs the description to carry the meaning of 'loop-breaking controls' and the result of the check. The one-liner does not, so an agent lacks enough context to interpret or rely on the outcome.
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 there is nothing for the description to compensate for; the baseline for a no-parameter tool applies. No parameter syntax or meaning is missing.
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 pairs a specific verb (Verify) with a stated target (loop-breaking controls) and the condition (on and untampered), which is more than a tautology. However, 'loop-breaking controls' is undefined domain jargon, and it offers no contrast with siblings like egress_check or telemetry_report, so an agent cannot confidently place it in the toolset.
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 statement of when this check should be run versus alternatives such as egress_check or telemetry_report, nor any prerequisites or exclusions. Usage is entirely left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score an outbound message against inbound context; quarantine worm forwards.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It hints at a mutation ('quarantine worm forwards') but does not explain what gets quarantined, whether the action is reversible, what permissions are required, or what the scoring result represents.
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?
The description is a single front-loaded sentence with no wasted words. It is concise, though the second clause ('quarantine worm forwards') is cryptic and slightly reduces clarity without adding much structure.
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?
Given no annotations, no output schema, and no parameters, the description is too sparse to be complete. It does not explain what 'score' means, how quarantine works, or what the agent should expect as a result, leaving major gaps for correct invocation.
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 has zero parameters, so there is no parameter semantics to document. The schema description coverage is 100% (vacuously), and the description does not need to compensate for missing parameter details.
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 names a specific action ('Score an outbound message against inbound context') plus a secondary behavior ('quarantine worm forwards'), so the agent can identify the tool's domain. It does not explicitly differentiate from siblings, but the sibling names are in unrelated domains, so no confusion arises.
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?
No when-to-use guidance, prerequisites, or alternatives are stated. The agent must infer that this tool is for scoring outbound messages, but there is no indication of when it should be chosen over siblings or in what workflow context it belongs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Has this payload fingerprint been seen propagating in the fleet?
| 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, and it discloses almost nothing: no indication of what a positive/negative answer looks like, whether historical or live data is checked, scope of 'the fleet', or any permissions/rate limits. 'Propagating' hints at a time dimension but is never defined. This is a read-style query where the safety profile and return semantics are entirely unstated.
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 short sentence with no filler, and the subject (payload fingerprint propagation in the fleet) is front-loaded. The interrogative framing is efficient if slightly indirect for a tool description.
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, no output schema, and no parameters, the description is the only source of information, and it omits the return value, the input mechanism for the fingerprint, and any behavioral constraints. For a zero-arg, zero-annotation tool the definition needs to work considerably harder to be callable with confidence.
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 input schema is an empty object (0 parameters), which normally sets the baseline at 4, but the description explicitly references an input — 'this payload fingerprint' — for which no parameter exists, creating an unresolved question of how the fingerprint is supplied. The description does not clarify this gap, so it falls below the zero-param baseline.
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 conveys the subject matter precisely — a lookup of whether a payload fingerprint has been observed propagating across the fleet — but it is phrased as a question rather than a verb+resource statement, and the actual operation (query/check) is left implicit. Nothing distinguishes it from siblings like egress_check, which could plausibly answer a similar question about a payload.
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 guidance on when to reach for this tool versus egress_check, controls_verify, or telemetry_report. The phrasing implies a triage/verification context, but no condition, prerequisite, or alternative is named. The agent must guess from the sibling list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read from the shared store; data context unless a valid elevation token is given.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full behavioral burden. It hints at an authorization behavior (elevation token changes the context) but never explains what "data context" vs the elevated context actually return, how the token is supplied, or what happens if it is missing or invalid.
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 front-loaded sentence with no filler; the core operation comes first and the conditional context follows. It is efficient, though the brevity pushes into cryptic territory that the rest of the definition never resolves.
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?
For a tool with no annotations, no output schema, and no parameters, this one sentence is not enough. It omits what the store contains, the meaning of "data context," the return shape, and the origin of the elevation token.
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 schema is empty, which normally sets a baseline of 4, but the description references an input — a "valid elevation token" — that has no corresponding parameter in the schema. That mismatch leaves the agent unsure how, or whether, the token can be passed at invocation.
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 a specific verb ("Read") and resource ("the shared store"), which cleanly distinguishes it from the sibling store_write. It stops short of naming or contrasting any sibling explicitly, and "shared store" is left undefined, so it lands at clear-but-not-differentiated.
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 clause "data context unless a valid elevation token is given" implies a conditional usage mode, so the agent can infer there are two read scopes. However, it never says when to prefer store_read over siblings, nor what qualifies as an elevation token or how to obtain it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write to the shared store (data-only by default).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and mostly fails it: nothing about what a write overwrites or appends, whether the store is shared across sessions, auth requirements, or reversibility. "data-only by default" is a real hint that a different (presumably non-data/metadata) mode exists, but it is left unexplained.
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?
One short, front-loaded sentence with no waste. It is efficiently sized, though the ambiguous parenthetical raises more questions than it answers.
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?
For a mutation tool with no annotations and no output schema, the definition is too thin: an agent cannot tell what is being stored, what "default" mode means, what the alternative mode is, or what the call returns. The zero-param schema is simple, but the behavioral gap remains.
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 schema-baseline of 4 applies; there are no parameter semantics the description could usefully add beyond confirming the tool is bodyless.
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 a specific verb (Write) and resource (the shared store), and the sibling list makes the read/write split with store_read obvious. The parenthetical "data-only by default" hints at a non-data mode without naming it, so the scope is not fully pinned down.
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?
No when-to-use guidance and no explicit alternative routing, though the existence of store_read makes the read counterpart inferable. "data-only by default" implies another mode exists but never says when to use which.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-cluster spread telemetry and R estimates.
| 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 behavioral burden, and it discloses nothing: no read/write nature, no auth or permission requirements, no rate limits, no freshness or caching behavior for a telemetry endpoint.
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?
The single fragment wastes no words and is trivially front-loaded, but it is under-specified rather than genuinely concise — there is no verb and no complete sentence to structure. Adequate but minimal.
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 parameters and no output schema, the description is the only source of information about what an agent receives back, and it supplies only an ambiguous label for two outputs. It is not enough to invoke the tool confidently or interpret its result.
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 there is nothing for the description to clarify beyond the schema. Baseline 4 applies; the description adds no parameter detail because none is needed.
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 phrase ('Per-cluster spread telemetry and R estimates') with no verb, so it never says what the tool actually does — return, generate, or stream these estimates. It hints at the subject matter but an agent cannot tell whether this reads, computes, or publishes data, and 'R estimates' is unexplained jargon.
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 prerequisites, and no mention of any sibling such as fingerprint_query or controls_verify that an agent might reasonably confuse this with. Nothing in the text routes the agent toward or away from this tool.
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.
controls_verifyegress_checkfingerprint_querystore_readstore_writetelemetry_reportAgent-speed defense for your own public surfaces: daily diff probes, per-identity verdicts.
Autonomous agent guardrails, bash sandboxing, MCP rugpull diffing & prompt firewalls.
Security intelligence for AI agents. 27 x402 endpoints: honeypot, forensics, CAPTCHA, preflight.
Cache guard: forced-private partitioning, TTL clamp, fingerprint diffing, exposure verdicts.
Add one secure layer between your agents and this server.
