Partition an agent fleet into reputation compartments with automatic firebreaks.
Scored across 9 tools
Most tools target distinct lifecycle stages: compartment creation, agent assignment, job registration, outcome recording, penalty intake, freeze, readmit, receipts, and status. Some boundary overlap exists between add_job and record_outcome (both job-related) and penalty_signal vs record_outcome (both negative signals), but descriptions provide enough context to distinguish them.
Five tools follow a verb_noun pattern (add_job, assign_agent, create_compartment, freeze_compartment, record_outcome), but penalty_signal and status_query are noun_noun, while readmit and receipts are bare verb/noun. The set is all snake_case and readable, but the mixed part-of-speech patterns reduce predictability.
Nine tools is well within the ideal 3–15 range and each maps to a distinct operation in the reputation-firebreak workflow. No obvious redundancy or padding is present.
The core lifecycle is covered (create, assign, job/outcome tracking, penalty, freeze, readmit, receipts, status), but there are notable gaps: no list/update/delete compartment operations, no explicit unfreeze (readmit may proxy), and no tool to manage baselines despite penalty attribution depending on them. These gaps could force workarounds.
Register an in-flight job {compartment, job_id, clean}
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| compartment | Yes |
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 almost nothing. "Register" implies a write, but there is no statement about idempotency (what happens if the same job_id is registered twice), required permissions, persistence, or side effects on the compartment.
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 short clause, which is front-loaded and free of padding. However, that brevity is under-specification rather than efficiency for a tool with two undocumented required parameters, and one listed token is spurious.
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 0% schema coverage, the description is the only documentation and leaves the agent without lifecycle context, error behavior, or return expectations. Given the sibling set implies a stateful job/agent workflow, this is a significant 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?
Schema description coverage is 0% for two required parameters, so the description must compensate and does not: it merely echoes the names "compartment" and "job_id" without explaining expected formats or meaning. It also introduces a third token, "clean", which is absent from the schema and adds confusion instead of semantics.
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 states a verb and resource ("Register an in-flight job") but never defines what a "job" is in this system, and it gives no differentiation from siblings like record_outcome, status_query, or readmit. The trailing brace list also names a field ("clean") that does not exist in the schema, muddying rather than clarifying the purpose.
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 alternatives such as record_outcome or status_query. An agent must guess whether registering a job is the right call versus the other lifecycle tools in the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assign an agent to a compartment {agent, compartment}
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes | ||
| compartment | Yes |
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 permission requirements, no reversibility or idempotency, no side effects on the agent or compartment, and no error behavior. For a mutation-style assignment operation this is a complete gap.
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 short and front-loaded, which is appropriate, but the trailing brace list is redundant with the schema and consumes the only remaining space that could have carried useful context. It is brief without being efficient.
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 two required parameters, 0% schema coverage, no annotations, and no output schema, the description is the only source of context and it supplies almost none. An agent cannot determine valid inputs, side effects, or what a successful assignment returns.
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?
Schema description coverage is 0% and both parameters are bare strings. The description only echoes the property names in braces ('{agent, compartment}'), adding no format, identifier convention, or expected value information beyond what the schema already shows.
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 states a recognizable verb+resource (assign an agent to a compartment), so an agent can grasp the basic action. However, it is essentially a restatement of the tool name with the parameter names appended, and it does nothing to distinguish itself from siblings like create_compartment or freeze_compartment.
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 use this tool versus alternatives, no prerequisites (e.g., must the agent or compartment already exist?), and no indication of what state the assignment implies. The agent is left to infer all routing decisions from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a reputation compartment {task_class} (plan slot required)
| Name | Required | Description | Default |
|---|---|---|---|
| task_class | Yes |
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 does not state permissions/auth needs, whether creation is idempotent, what happens on duplicate task_class, or what the result contains. The only behavioral fact offered is the 'plan slot required' prerequisite, which is genuinely useful but isolated.
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, front-loaded sentence with no wasted prose, which is good, but the raw template token '{task_class}' reads as a copy-paste artifact rather than deliberate documentation and slightly obscures the sentence.
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 zero annotations, no output schema, and an undocumented parameter, the description is far too thin — an agent cannot tell what a 'reputation compartment' affects, what the prerequisite means operationally, or what success looks like.
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?
Schema coverage is 0% and the sole parameter task_class is an undescribed string. The description repeats the placeholder '{task_class}' without explaining expected format, allowed values, or examples, so it adds essentially no meaning beyond the schema.
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 gives a clear verb+resource pair ('Create a reputation compartment'), which is better than a tautology, but 'reputation compartment' is domain jargon that is never unpacked and nothing distinguishes this from the sibling freeze_compartment or the reputation-adjacent record_outcome/penalty_signal tools.
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 '(plan slot required)' hints at a precondition but never says when this tool should be chosen over alternatives, nor what happens if no plan slot is available. No when-to-use or when-not-to-use guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Freeze a compartment {compartment}
| Name | Required | Description | Default |
|---|---|---|---|
| compartment | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and discloses almost nothing: it does not say whether freezing is reversible, what side effects or state changes occur, what permissions are required, or how success is reported. 'Freeze' at least signals a state mutation, 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?
A single short sentence with the action front-loaded and zero padding. Its brevity is efficient, though it borders on under-specified rather than genuinely concise.
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?
This is a mutation tool with no annotations, no output schema, and a parameter at 0% coverage, so the description is the sole source of behavioral and parameter context — and it supplies none of it. An agent cannot reliably predict consequences or argument format from this description 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?
Schema description coverage is 0%, so the description must compensate for the undocumented `compartment` parameter — yet it only echoes the parameter name in a placeholder. It gives no indication of identifier format, expected values, or how a compartment is resolved.
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 gives a specific verb (freeze) and resource (compartment), making the action unmistakable. It does not distinguish the tool from siblings such as create_compartment or add_job, but the verb is distinct enough that confusion is unlikely.
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 to use this tool, when not to, or what alternative exists (e.g., is there an unfreeze or a status_query-driven flow). The agent must infer the operating context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Intake an account-level penalty signal {kind}; attribution comes from baselines only
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a cryptic attribution constraint ('from baselines only') but says nothing about side effects, permissions, duplicate handling, or what happens after intake.
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 sentence with no obvious waste, but its terseness comes at the cost of clarity. The attribution clause is front-loaded but cryptic rather than informative.
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 an unannotated ingestion tool with an undocumented required parameter and no output schema, the description is incomplete. It does not explain what a 'kind' is, what the tool returns, or how to recover from an invalid signal.
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?
Schema description coverage is 0% for the single required 'kind' parameter, and the description merely repeats '{kind}' without explaining allowed values, format, or meaning. The description does not compensate for the schema gap.
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 an action ('Intake') and resource ('account-level penalty signal'), so an agent can infer this records or ingests a penalty event. However, 'penalty signal' is jargon and the description does not distinguish this from siblings like record_outcome or receipts.
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 guidance on when to use this tool versus alternatives. The phrase 'attribution comes from baselines only' reads as a constraint but is too cryptic to function as usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-admission probes {compartment, probes}
| Name | Required | Description | Default |
|---|---|---|---|
| probes | Yes | ||
| compartment | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure, and it discloses nothing: no mutation vs read semantics, no side effects, no permission or precondition requirements, no notion of what a 'probe' does to a compartment.
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, but brevity here reflects under-specification rather than economy; the single fragment is essentially the name plus a parameter list and earns no informational value.
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 two fully undocumented required parameters, an agent has nothing to act on: neither the effect of the call nor the shape of the inputs is recoverable from the definition.
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?
Schema description coverage is 0% and the description only echoes the parameter names in braces, adding no meaning: the format of 'probes' (array of what?), the identity/scope of 'compartment', and their relationship are all undefined.
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 phrase 'Re-admission probes' merely restates the tool name 'readmit' with the parameter names appended; it does not state what re-admission means, what is probed, or what happens as a result. An agent cannot distinguish this from siblings like record_outcome or status_query based on the description.
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 indication of when to call this tool, when not to, or which sibling (e.g., record_outcome, status_query, add_job) it replaces. The description offers zero routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Incident receipt chain + validity
| 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 burden, and it discloses nothing: not whether this is a read or a write, not auth requirements, not what 'validity' means or how it is computed. The '+' notation hints at two outputs but explains neither.
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 brief, but this is under-specification rather than conciseness: two noun phrases with no front-loaded verb or scope. Brevity here costs the agent information rather than saving it.
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 carrier of meaning, yet it never states what the tool returns or when it should be called. For a zero-param tool the explanation of the returned receipt chain and validity result is exactly what was needed and is absent.
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 of 4 applies; there is no parameter semantics for the description to add or omit. The empty input schema is consistent with a no-argument 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?
The fragment 'Incident receipt chain + validity' names a resource but supplies no verb, so an agent cannot tell whether this reads, verifies, or generates receipts. It is not a pure tautology of the name, but it is cryptic enough that it does not distinguish itself from siblings like status_query or record_outcome.
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 preconditions, and no pointer to an alternative among the eight sibling tools. The agent is given nothing to decide whether this tool applies to its situation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record an outcome {compartment, outcome, job_id?, job_clean?}
| Name | Required | Description | Default |
|---|---|---|---|
| outcome | Yes | ||
| compartment | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full behavioral burden, and it discloses nothing beyond the bare operation: no idempotency, duplicate handling, required permissions, or side effects for what is clearly a mutation. It only lists the parameter names.
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 line that is front-loaded with the operation, but its brevity comes from under-specification rather than efficiency, and it spends its limited words on phantom parameters not present in the schema.
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 two-required-parameter write tool with no annotations, no output schema, and no schema descriptions, the description leaves the agent without the information needed to invoke it correctly. It should at minimum explain what an outcome is and how compartment scopes it.
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?
Schema description coverage is 0%, so the description must compensate, but it only echoes the parameter names without explaining what compartment or outcome values mean. It also lists optional job_id and job_clean parameters that are absent from the schema, which is actively misleading.
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?
It states a verb+resource ('Record an outcome'), which is minimally specific, but 'outcome' is an undefined domain term and nothing distinguishes this from siblings like status_query, receipts, or penalty_signal. An agent cannot tell what recording an outcome actually accomplishes from this text alone.
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, when-not-to-use, or alternative guidance at all. With eight sibling tools in the same domain (add_job, penalty_signal, readmit, etc.), the absence of routing guidance is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compartment status for an agent {agent} — $0.01 x402 or included on an active plan (same billing as HTTP)
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes |
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. It usefully discloses the billing model ($0.01 x402 or included on an active plan), which is real context not found in the schema, but says nothing about read-only safety, side effects, or return shape.
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 sentence that front-loads the purpose and tacks billing onto the end. No wasted framing, though the pricing clause competes slightly with the core statement.
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 an undocumented parameter, the description leaves too much open: it never describes what status information is returned or any preconditions. The billing note is helpful but not sufficient.
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?
Schema description coverage is 0% for the single 'agent' parameter. The description only echoes it as {agent} without explaining accepted format, identifier type, or lookup behavior, so it does not compensate for the coverage gap.
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 resource and scope: compartment status for a named agent. An agent can infer the read-oriented purpose, though the verb is only implied and no sibling (e.g. freeze_compartment, readmit) is named to sharpen the boundary.
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 alternatives named. With siblings like freeze_compartment, readmit, and receipts, the description does nothing to tell the agent which situation selects 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.
add_jobassign_agentcreate_compartmentfreeze_compartmentpenalty_signalreadmitreceiptsrecord_outcomestatus_queryPropagation breaker: egress quarantine + fingerprint outbreak telemetry for fleets.
Agent reputation scoring: trust scores, Sybil detection, cross-chain identity for 133K+ agents
Decay-weighted reputation + tamper-evident trust attestations for the agent economy.
Trust infrastructure for AI agents. Portable reputation (JTS 0-5), agent discovery, vouching.
Add one secure layer between your agents and this server.
