Atomadic Forge

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, closed-world and non-destructive, so the safety profile is covered. The description adds the useful domain framing of claim drift, but says nothing about what a detection result looks like or how it treats more than two statements, which matters for an analytical 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?

Two tight sentences, front-loaded with the capability and followed by the disambiguation. Nothing redundant and nothing padding the length.

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 single-parameter read-only tool with annotations covering safety, the description covers purpose and routing well. The remaining gap is the ambiguous cardinality of the statements array and the absence of any hint at the shape of the contradiction 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?

Schema description coverage is 0%, so the description must carry the burden; it does convey that inputs are free-text claims, and the schema's example clarifies the shape. However, it says 'two' outputs while the parameter is an unbounded array of strings, leaving an agent unsure whether exactly two items are required or whether items are compared pairwise.

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?

Names a specific verb and resource ('Detect contradictions between two free-text agent outputs') plus the domain gloss 'natural-language claim drift'. It explicitly distinguishes itself from the sibling detect_contradiction by input type, so an agent can pick correctly without opening either schema.

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?

States the selection rule outright: free-text drift here, structured key/value claims that must agree in detect_contradiction. The alternative and the condition that selects it are both named, leaving no inference needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds nothing beyond that: it does not say what a classification result looks like, what intent categories exist, or how the model handles ambiguous input. For a classification tool with no output schema, that is a real 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?

It is short, but brevity here comes from under-specification rather than economy. The bracketed '[agents]' prefix is noise, and nothing is front-loaded because there is no substance to front-load.

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 output schema and no description of return values, an agent cannot know what label taxonomy or confidence data comes back. Given the crowded sibling namespace and a single undocumented parameter, the definition leaves the caller guessing about both input expectations and output shape.

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% for the single 'text' parameter; only a generic example string is provided. The description does nothing to explain constraints such as expected length, language, or whether the text is a user utterance vs. a system prompt, so it fails to compensate for the low coverage.

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 '[agents] Agent intent classification' merely restates the tool name and title in slightly different words. It gives no verb describing the operation and no distinction from siblings like agents_plan or agents_contradiction, all of which are also 'agent' utilities.

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 rather than text_keywords, text_sentiment, agents_plan, or any other sibling. No preconditions, no exclusions, no alternatives are named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, but the description adds no behavioral context beyond the name. It says nothing about plan structure, whether the agent executes the plan, determinism, or what the response contains.

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 phrase is not concise so much as under-specified. It contains no front-loaded useful detail and omits nearly everything an agent needs to select and invoke the tool correctly.

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 planning tool with a required goal, a nested constraints object, and no output schema, the description should explain what kind of plan is produced and how constraints affect it. Instead it provides only a restatement of the name, which is inadequate for the tool's complexity.

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 only 50% and the description provides no meaning for either parameter. The required 'goal' parameter has only an example in the schema, and the nested 'constraints' object receives no explanation in the description, so the description fails to 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?

The description 'Autonomous agent goal planning' essentially restates the tool name and title without a concrete verb or stated outcome. It does not clarify whether the tool generates a plan, registers a goal, or executes steps, leaving it ambiguous among the many agents_* siblings.

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, when not to, or which sibling alternatives exist. The agent must infer usage 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag this as a non-read-only, non-idempotent, non-destructive mutation, but the description adds zero context on top of that. It does not say whether re-registering an existing agent_id fails, overwrites, or is rejected — critical given idempotentHint=false — nor whether registration is reversible.

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?

Short, but the brevity reflects under-specification rather than economy; the '[agents]' tag is a namespace marker, not information. No sentence in the description earns its place because none adds content.

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 mutation tool with two required, completely undocumented parameters, no output schema, and no annotations explaining idempotency or uniqueness consequences. The description leaves everything an agent needs to call it correctly unstated.

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 mentions neither parameter. An agent gets no explanation of what agent_id must be (unique? format? scoped to what?) or what capability strings mean or whether they are validated against an allowed set.

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 restates the tool name almost verbatim: 'Register an agent' adds nothing beyond 'agents_register'. It never says what registration accomplishes (identity enrollment? capability cataloguing?) or how it differs from siblings like ratchet_register, sla_register, or reputation_record.

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 call this versus ratchet_register, sla_register, identity_verify, or any other sibling. No prerequisites, no ordering, no exclusions are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context of its own — no indication of what the score represents (range, freshness, aggregation), whether an unregistered agent yields an error or a default, or what the response looks like.

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 fragment with no filler, so it is not bloated. However, it is under-specified rather than economical — the brevity leaves the core action unstated, so the compactness does not earn its place.

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 one required parameter, no output schema, and 0% parameter description coverage, the description is the only channel for meaning and it delivers essentially nothing. For a scoring tool in a trust/reputation ecosystem, an agent needs at least what the score means and when to call it instead of trust_score.

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 carry the burden for agent_id, but it says nothing about the identifier's expected format or origin (registration name vs. DID vs. address). Only the schema's bare 'my-agent-001' example hints at format.

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 'Agent reputation and trust score' restates the tool name and title without a verb or object of action; it never says whether it reads a score, computes one, or returns a history. Siblings like trust_score, reputation_record, and identity_verify make a bare noun phrase ambiguous — an agent cannot tell which of these fetches an agent's reputation score.

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, when-not-to-use, or alternative is named, despite the sibling set containing at least three plausibly overlapping reputation/trust tools. Nothing indicates prerequisites such as whether the agent must be registered first via agents_register.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context by clarifying the comparison is semantic rather than textual, which shapes how the agent should interpret results. It does not discuss determinism or what the diff output looks like, so it stops short of a 5.

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?

Two tight sentences with zero filler; the core purpose is front-loaded and the sibling routing follows immediately.

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?

No output schema exists, so the description should indicate what the diff yields (structured change list, summary, verdict) and clarify the context parameter's role. Annotations cover safety, but return shape and the undocumented third parameter leave real gaps for a comparison tool.

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 carries the full burden. It implies output_a/output_b are the two agent outputs being compared, but says nothing about the 'context' parameter or how it influences the diff, leaving one of three parameters entirely unexplained.

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+resource (semantic diff between two free-text agent outputs) and immediately disambiguates the type of diff with 'meaning-level change, not text-level'. It also names the siblings it is not, so an agent can distinguish it from forge_verify, drift_check, and detect_contradiction without opening schemas.

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 use case is explicit (comparing two free-text agent outputs) and the exclusions are named with their conditions: forge_verify for build artifacts, drift_check for certified operational drift. That is a direct when-this / when-other routing rule.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this as a safe, read-only, idempotent, closed-world operation, so the safety profile is covered. The description adds only the word 'Live', which hints at real-time freshness but does not explain what is returned, how current it is, or how the topology is scoped. With zero annotation burden remaining, this is a very thin contribution.

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 only four words and is front-loaded, so it is not bloated. However, its brevity comes from under-specification rather than discipline: it omits the verb and the return semantics that would let an agent act on 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?

There is no output schema, no parameters, and only four words of description, so the description must carry the full burden of explaining what the tool produces. It does not say whether the result is a node list, edge list, or rendered graph, nor what 'live' means in terms of freshness. For a zero-argument read tool in a crowded agents_* namespace, this leaves a material 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, so there is nothing for the description to disambiguate, and the baseline for a parameterless tool applies. Schema coverage is 100% by default because the input is an empty object.

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 'Live swarm topology' largely restates the tool name and title rather than stating a specific action or defining what 'topology' contains. It gives no verb and no indication of whether it returns a graph, a list, or a snapshot of agent relationships, so an agent cannot distinguish it confidently from siblings like agents_reputation or trust_score.

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 call this tool, what question it answers, or which sibling to use instead for related agent-state queries. The only implied usage comes from the words 'live' and 'topology', which is not enough to route between the many agents_* and trust_* alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover idempotency and destructiveness, and the description adds real value beyond them: the exact return taxonomy (GREEN/RED/UNVERIFIED), the free-tier limit (3 calls/day), and entitlement gating. The rate-limit disclosure is genuinely useful. It would reach a 5 if it clarified why readOnlyHint is false for what reads like a compute/verify operation.

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?

Front-loads the product tag then the operation, and every clause (return codes, rate limit) earns its place. The bracketed entitlement prefix is slightly noisy but functional.

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?

No output schema exists, so the description must explain returns, and it does so precisely with the three status codes. With 100% schema coverage and clear behavior, an agent has what it needs; only minor gaps (nested inputs format expectations) remain.

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 100%, and the schema itself documents omitting claimed_digest for UNVERIFIED plus the nested inputs payload. The description adds no syntax or format detail beyond that, so the baseline 3 is appropriate.

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 and resource ('Recompute-audit an agent work claim') and pinpoints the exact operation (re-derive SHA-256 digest from inputs and compare to claimed digest). Clearly distinguishable from siblings like verify_settlement or forge_verify, which audit other artifacts.

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?

Explains the operating condition clearly: supply a claim to get GREEN/RED, omit it for UNVERIFIED. Context for when to use it is implied well by 'Replay, not opinion.' Does not explicitly enumerate alternatives among the many sibling verify/audit tools, so short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds nothing on top: it doesn't say whether the gate blocks/allows an operation, what happens on failure, or whether results are cached locally (consistent with openWorldHint=false) — the word "gate" implies blocking but never confirms it.

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 five-word tag-and-noun fragment is not conciseness but under-specification — nothing is front-loaded because there is essentially no body text. There is no wasted sentence, but also no sentence doing work.

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 three mandatory string parameters, no enums, no output schema, and zero documented value domains, the description leaves the agent unable to construct a valid call confidently. Annotations cover the read-only/idempotent profile, but the regulatory gate's decision semantics and valid inputs are entirely 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?

Three required parameters (data_type, jurisdiction, operation) at 0% schema description coverage, and the description says nothing about any of them — no accepted values, no defaults, no semantics for how they combine. The only hints are schema `example` fields (user_pii, EU, store), which are schema content, not description content. The description must compensate here and does not.

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?

"[security] GDPR/CCPA compliance gate" names a specific regulatory scope (GDPR/CCPA) and the resource type (gate/check), which does distinguish it somewhat from siblings like compliance_eu_ai_act or compliance_fairness. However, there is no verb describing what the tool actually does (validate? evaluate? block?) and no sentence stating its output or action.

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 description gives no when-to-use condition, no prerequisites, and no mention of alternatives. With fifteen compliance_* siblings, the lack of routing guidance is a real cost — the agent must guess whether this is the general pre-flight gate or a niche check. The "[security]" prefix hints at category but not usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context such as what the certificate represents, whether data is validated, or how unacceptable risk is handled.

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 bracketed phrase and is too terse for a tool with three required parameters and compliance implications. Its brevity does not earn its place because critical action and usage context are missing.

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 three-parameter compliance tool with no output schema, the description is not complete enough: it does not explain what a certificate is, how intended_purpose is used, or what the agent should expect as a result. Annotations cover the safety profile but not the domain behavior.

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 does not explain system_id, risk_category, or intended_purpose. The risk_category enum values are left undocumented in prose, so 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 a resource, "EU AI Act compliance certificate," and adds a [security] tag, but it uses a noun phrase with no verb. It does not clarify whether the tool checks, retrieves, or issues a certificate, though the EU AI Act focus distinguishes it somewhat from generic compliance siblings.

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 compliance_check, compliance_explain, compliance_fairness, or other compliance siblings. No prerequisites, exclusions, or alternative-selection criteria are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. However, the description adds no behavioral context such as what the certificate contains, whether it requires a prior decision record, or what happens when decision_id is unknown. It merely repeats the tool's domain.

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 but under-specified rather than concise; it front-loads a jargon-heavy spec identifier (XPL-100-ExplainBound) that offers no actionable information. There is no wasted sentence, but there is also no useful 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?

With three required parameters including a nested object, no output schema, and no annotation explanation of the certificate lifecycle, the description is far too thin. It does not tell an agent what inputs are needed or what the tool returns, leaving the definition materially incomplete for a non-trivial compliance tool.

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 all three required parameters (model_id, decision_id, and the nested subject_context object) are undocumented. The description supplies no meaning, format, or constraints for any of them, so an agent must guess at what subject_context should contain.

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, 'Explainability certificate (XPL-100-ExplainBound)', with no action verb and no statement of what the tool actually does. It identifies a resource type but does not distinguish it from siblings such as compliance_check, compliance_transparency, or compliance_fairness, all of which could plausibly produce compliance-related artifacts.

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, when not to use it, or which of the many compliance_* siblings to choose instead. The description offers nothing beyond a label.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only a '[security]' tag and a standard identifier, with no additional behavioral context such as what the proof contains, whether authentication is required, or what the 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 short phrase, which is concise but under-specified rather than efficient. It is front-loaded with a security tag and standard ID but omits the information needed to invoke the tool correctly.

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 four required parameters, no output schema, and a specialized compliance purpose, the description is far too thin. It does not explain what a fairness proof is, how inputs are used, or what the agent should expect in return.

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?

All four parameters are required and schema description coverage is 0%, but the description does not explain model_id, dataset_id, protected_attrs, or metric. It provides no semantic guidance for any parameter, leaving the agent with only bare schema names.

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 'Fairness proof' and references FNS-100-FairnessBound, which signals a fairness-proofing tool. However, 'proof' is ambiguous about whether it computes, generates, verifies, or retrieves a proof, and it does not distinguish this tool from the many other compliance_* siblings.

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 such as compliance_check, compliance_eu_ai_act, or compliance_transparency. The description gives no prerequisites, exclusions, or context that would help an agent select it correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already state readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that — it does not say whether reporting creates a persistent record, whether duplicate submissions create duplicate incidents (non-idempotent), or who is notified. The bracketed "[security]" tag is a category label, not behavioral context.

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 line with no wasted wording, and the resource is front-loaded. But the brevity here is under-specification rather than economical precision — the tag consumes roughly a third of the text without adding meaning.

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 non-idempotent write tool with four required parameters, no output schema and no parameter documentation. An agent cannot tell what happens after submission, whether the incident gets an ID back, or how this differs from compliance_incidents, so the definition is not complete enough to invoke 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?

Schema description coverage is 0%, so the description carries the full burden for four required parameters, and it provides no information about any of them. The names and the severity enum are largely self-explanatory, which prevents a score of 1, but nothing clarifies what system_id refers to or how affected_users should be counted.

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?

"Report compliance incident" does give a verb and a resource, but "report" is ambiguous — it could mean file/create an incident or retrieve a report about one. There is also a near-identical sibling, compliance_incidents (plural), and the description does nothing to distinguish creating an incident from listing them.

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, no prerequisites, and no mention of the obvious alternative compliance_incidents. An agent seeing both names must guess which one files an incident and which one reads them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered by structured data. The description contributes nothing beyond that — no indication of scope, volume, pagination, or what an incident record contains — but it does not contradict the annotations either.

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 the brevity is under-specification rather than economy — only six words exist, and none of them are front-loaded actionable information. There is no wasted text, but there is also almost no text to evaluate.

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 output schema and a bare-bones input schema, the description is the only place return shape and usage context could be conveyed, and it conveys neither. An agent cannot determine what this call produces or when it applies.

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 parameter system_id, so the description must explain whether this is a system identifier, which namespace it belongs to, or what format it takes. It says nothing, leaving the parameter's semantics inferable only from its 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?

"[security] Incident registry" is a noun phrase that essentially restates the tool name and title, with only a category tag added. It never states a verb (list, fetch, query) or what the registry returns, and it does not distinguish itself from the very similar sibling compliance_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 guidance on when to use this tool versus alternatives. With siblings like compliance_incident, compliance_check and compliance_explain in the toolset, an agent has no basis for choosing among them from this description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety is covered by structured data. The description adds only an opaque rule code (LIN-100-ChainIntegrity) with no explanation of what it verifies, what it returns, or what happens if the chain is broken.

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 text is short and front-loaded, but the parenthetical code consumes most of the content without conveying usable meaning. Brevity here reflects under-specification rather than disciplined economy.

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 at 0% coverage, no output schema, and a complex nested array parameter, the description should carry far more explanation than it does. As written, an agent cannot determine how to invoke the tool correctly.

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?

Both required parameters (model_id, dataset_stages) have 0% schema description coverage, and the description says nothing about them. In particular, the structure of the dataset_stages array of objects is entirely undocumented, leaving the agent unable to construct a valid call.

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 restates the name ("Data lineage") with no verb or scope, so it is close to tautology. The bracketed "[security]" tag and "LIN-100-ChainIntegrity" hint at a compliance-integrity purpose but never state what the tool actually does or how it differs from siblings like compliance_check or compliance_explain.

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 or when-not-to-use guidance. With siblings such as compliance_check, compliance_eu_ai_act, and compliance_transparency in the same family, an agent has no signal for selecting this tool over those.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description says "Log oversight event", i.e. recording/writing an event with reviewer, decision, and notes, while annotations declare readOnlyHint=true and idempotentHint=true. Recording a reviewer decision is a mutation, so the description directly conflicts with the structured safety profile, and no permissions, side effects, or return behavior are disclosed.

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?

Four words is not conciseness but under-specification; there is no front-loaded purpose, scope, or routing information to compress. Nothing in the text is wasted, but almost nothing is present.

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 four-required-parameter tool with no annotations-aligned behavior, no output schema, and 0% schema documentation needs the description to carry the load, and it says nothing about what is recorded, who can record it, or what is returned.

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 all four parameters (system_id, reviewer_id, decision, notes) are required with no types beyond generic strings. The description supplies no meaning for any of them, so an agent cannot know the expected format of decision or the scope of notes.

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?

"[security] Log oversight event" pairs a verb with a vague resource, but "oversight event" is not defined and there is no differentiation from roughly ten compliance_* siblings such as compliance_incident, compliance_check, or compliance_transparency. The bracketed tag adds a category hint but no distinguishing 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 statement of when to use this tool versus compliance_check, compliance_incident, audit_work_claim, or any other sibling. An agent has no basis to choose this tool over the crowded compliance family.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds nothing beyond the '[security]' tag: it does not say what period of history is returned, whether results are paginated, or whether system_id must be registered first.

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?

Two words plus a bracketed tag is not conciseness but under-specification. There is nothing front-loaded because there is essentially no content to front-load.

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?

The tool takes a required identifier and returns unspecified historical records with no output schema, so the description must carry more weight than it does. Annotations cover safety, but the agent still cannot tell what calling this will yield or how to scope 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% and the single required parameter system_id has no type documentation beyond 'string'. The description does not compensate at all — it never mentions system_id, its expected format, or where an agent should obtain one.

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 ('[security] Oversight history') is a near-tautology that restates the tool name and title. The only added information is the '[security]' domain tag, which does not say what the tool actually returns or how it differs from compliance_oversight, compliance_incidents, or trust_history.

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 call this versus the many sibling compliance tools (compliance_oversight, compliance_incidents, compliance_check, compliance_lineage). No prerequisites, no exclusions, no alternatives are named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only a "[security]" category tag and says nothing about what the report contains, what data it reads, or any permission requirements. It does not contradict the annotations, but it adds minimal behavioral context.

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, but its brevity reflects under-specification rather than efficiency. It is not front-loaded with actionable information and contains no useful detail beyond the title and a category tag.

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 requiring three parameters with no output schema and no parameter descriptions, the description is completely inadequate. It does not explain what the transparency report returns or clarify the required inputs, leaving an agent unable to invoke the tool correctly.

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 has three required parameters (system_id, period, include) with 0% description coverage, and the tool description provides no parameter guidance. It does not explain what system_id identifies, the expected period format beyond the schema's example, or what values are valid for the include array.

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 "[security] Transparency report" essentially restates the title "Compliance Transparency" with a category tag. It gives no specific verb, resource, or scope, and offers no way to distinguish this tool from the many compliance_* siblings such as compliance_check or compliance_oversight.

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, when not to, or which alternative to choose. With numerous sibling tools like compliance_check, compliance_incidents, and compliance_oversight, the description leaves selection entirely to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that — no indication of whether it performs an on-chain lookup, requires a live node, or how long a proof check takes. The 'BRP-100' token implies a standard spec but it is never explained.

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 is under-specification rather than conciseness: a bracketed tag and a jargon code occupy the whole description and convey no actionable front-loaded information.

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 five-required-parameter tool with zero documented parameters and no output schema, so the description carries the entire explanatory burden — and it provides none. An agent cannot construct a valid, meaningful call from this 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?

All five required parameters (bridge_id, source_chain, dest_chain, amount, token) have 0% schema description coverage and the description supplies no meaning for any of them. Format expectations — chain identifiers vs names, token symbol vs address, amount units/decimals — are entirely undocumented.

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 essentially a restatement of the title plus an opaque standard code: '[defi] Bridge Proof (BRP-100-BridgeIntegrity)'. It hints at a proof/verification domain but never states a verb or what is being verified (a transfer, a message, a lock event), so an agent cannot tell it apart from defi_oracle_verify, verify_settlement, or forge_verify beyond the 'defi bridge' label.

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 alternative among the many verify-style siblings. The agent must guess whether this validates a pending bridge transaction, a proof payload, or post-hoc integrity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds nothing beyond that — no statement of what is inspected, whether the contract must be deployed/exists, what permissions or network access are needed, or what a successful vs failed audit implies.

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 the brevity is under-specification rather than efficiency; the parenthetical internal code (CVR-100-AuditBound) consumes the only content slot without informing the caller.

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 output schema, 0% parameter documentation, and annotations covering only the safety profile, the description must explain what the audit returns and what inputs are valid. It does neither, so an agent has no basis to invoke this tool correctly.

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 required parameters (contract_id, contract_type) are completely undocumented in the schema. The description therefore carries the full burden and supplies nothing — no format for contract_id (address? hash? internal id?), no enumeration or expected values for contract_type beyond a single 'erc20' example.

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 essentially the title restated plus an opaque internal code ('Contract Verify (CVR-100-AuditBound)'). It never says what 'verify' means here — static analysis, source match, bytecode hash, or address legitimacy — so an agent cannot distinguish it from defi_bridge_verify, defi_oracle_verify, or forge_verify.

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 zero usage guidance: no when-to-use, no prerequisites, no exclusions, and no mention of any of the ~60 sibling tools even though several (defi_bridge_verify, defi_oracle_verify, security_zero_day) plausibly overlap. The agent must guess 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already provide comprehensive behavioral context (readOnlyHint: true, destructiveHint: false, idempotentHint: true). The description adds zero unique behavioral information.

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?

While extremely short, the definition is structured like metadata rather than helpful documentation. It is not concisely functional.

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?

Despite having a complex input schema with four specific financial metrics, the definition provides no context whatsoever on what the tool calculates or returns. It is maximally incomplete.

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 provides no guidance or context for the four required parameters, failing to compensate for the lack of structured documentation.

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 only contains a source identifier ('Liquid Shield (LQS-100-LiquidationBound)') and does not state what the tool actually does beyond its title.

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 are no instructions provided on when or how to use this tool relative to other available functions or scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the description only needed to add context the structured fields lack. Instead it adds nothing: it never says whether this only computes a recommendation or persists something (the readOnlyHint=false hints at a write), nor what state changes as a result. The word 'optimization' sits awkwardly against a non-read-only annotation and leaves the agent unsure of side effects.

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 short here means under-specified rather than efficient. The only substantive token is an opaque internal codename that consumes space without informing the agent.

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?

Three required parameters including a nested object, no output schema, and no parameter descriptions mean the description had to carry nearly all explanatory weight — yet it is a single fragment. An agent cannot call this tool correctly without guessing at input formats, protocol vocabulary, and the meaning of the returned optimization.

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 supplies no meaning for protocol, position, or the nested token_a/token_b/amount_usd fields, none of which the schema documents. For an undocumented nested object the description had the full burden and discharged none of it — accepted protocol values, amount units, and the risk_tolerance scale (example 0.5, range unstated) are all left unexplained.

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 'LP parameter optimization' hints at liquidity-provision tuning but never says what is optimized or what the tool returns, and the internal codename '(DFP-100-OptimalTick)' carries no meaning for an agent. It does not distinguish this tool from sibling optimizers such as defi_yield_optimize or defi_risk_score, so selection between them rests on guesswork.

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 whatsoever on when to use this tool, when not to, or which sibling to prefer. The description gives no prerequisites, no preconditions on the position/protocol inputs, and no routing rationale despite four other defi/compliance-adjacent tools in the sibling list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only an internal guard label and does not disclose what is checked, what thresholds apply, or what happens on failure.

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, but it is under-specified rather than concise. A single bracketed fragment does not front-load the actionable information needed to select or invoke the tool.

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 verification tool requiring five inputs, with no output schema and no parameter descriptions, the definition is far too thin. It does not provide enough context for an agent to confidently select or invoke the tool.

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 five required parameters — oracle_address, price_feed, reference_price, asset, and tvl_at_risk — with 0% schema description coverage. The description mentions none of them, so an agent must infer every parameter's meaning from the bare schema names.

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 only a category fragment, '[defi] Oracle guard (OGD-100-ManipulationBound)', and does not state a clear verb or resource such as verifying an oracle price feed. It gives no differentiation from the many nearby defi and verification siblings.

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, when not to use it, or which sibling tools are alternatives. In a large toolset with defi_risk_score, defi_contract_audit, oracle_hallucination, and others, the agent receives no routing context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that — no indication of what a score represents, its range, determinism guarantees, or what the response contains.

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?

Very short with no wasted words, but the brevity is under-specification rather than efficiency; the parenthetical code is noise that consumes part of an already tiny budget.

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 three required, deeply nested, undocumented parameters and no output schema, the definition leaves an agent unable to construct a valid call. Annotations cover safety only; the rest of the calling contract is missing.

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?

Three required parameters including two nested objects (position, market_conditions) with 0% schema description coverage, and the description says nothing about required shape, fields, or expected values. This is the case where the description must compensate for the schema, and it does not at all.

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?

Description restates the tool name and title ('DeFi risk scoring') and appends an opaque internal code, 'DFI-101-RiskScoreBound', that conveys nothing to an agent. It never says what the score measures, its scale, or how it differs from siblings like threat_score, trust_score, or defi_optimize.

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 guidance whatsoever on when to use this tool versus the many related sibling tools (threat_score, trust_score, compliance_check, defi_optimize). No prerequisites, no exclusions, no contextual triggers.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and a closed-world scope. The description adds no behavioral context about whether this moves funds, requires approvals, or returns only an allocation recommendation. It does not contradict the annotations, but it contributes almost nothing beyond them.

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 very short, but the brevity is under-specification rather than efficient conciseness. The single fragment is not front-loaded with actionable meaning and spends its only content on an internal codename.

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 optimization tool with no output schema and no parameter descriptions, the definition is missing the information an agent needs to invoke it safely. The annotations provide safety hints, but they do not fill the purpose, usage, or parameter gaps.

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 says nothing about either parameter. It does not explain principal_usd denomination, risk_tolerance scale or acceptable range, or any constraints, so it fails to compensate for the missing schema descriptions.

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 tag plus codename, 'Yield Oracle (YLD-100-YieldConvergence)', rather than a verb-and-resource statement. It does not explain that the tool optimizes DeFi yield, what it returns, or how it differs from siblings like defi_optimize or defi_risk_score.

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 and no comparison to alternatives. It does not say whether to call this instead of defi_optimize or defi_risk_score, nor what context makes it appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real value beyond them: deterministic and recomputable behavior, the RED/GREEN verdict semantics, the free-call quota, and the entitlement requirement. It stops short of covering error behavior for malformed claim objects, so it is strong but not exhaustive.

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?

Three tight, front-loaded sentences with no filler. Minor redundancy between the bracketed "[Ledger product, entitlement: ledger]" tag and the closing "then entitlement 'ledger'", which restates the same gating information.

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?

No output schema exists, and the description compensates by stating the RED/GREEN verdict format and determinism of results. With only one well-documented parameter and full annotation coverage, an agent has enough to invoke it correctly; only the shape of the returned details behind the verdict is unspecified.

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 100% and the schema already documents the claims array with key/subject and value fields. The description clarifies the semantics that make the parameter meaningful — contradictions are judged by the same key carrying conflicting values — going slightly beyond the schema's field list.

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 and resource ("Detect contradictions across structured claims") plus the exact rule ("same key asserted with conflicting values flips RED, otherwise GREEN"). It also names the sibling it is not (agents_contradiction for free-text prose), so the agent can separate the two without reading schemas.

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?

Gives an explicit routing rule: use this for structured claims, use agents_contradiction instead when comparing free-text agent prose. It also states the quota (3 free calls/day) and the entitlement gate ('ledger'), which tells the agent when the call will fail or need upgrading.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds nothing beyond a '[trust]' category tag — no mention of what a certificate represents, whether it is cached, or how the returned certificate is scoped.

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?

Extremely short, but brevity here reflects under-specification rather than efficient communication; there is no informational payload to front-load.

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?

No output schema, no parameter documentation, and a one-phrase description leave an agent unable to determine what this tool returns or how to supply a valid id. Completely inadequate for 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 single required parameter 'id' has 0% schema description coverage and the description gives no hint about what kind of id it is (agent id, drift event id, certificate id, hash). With no annotation or schema help here, the description fully fails to compensate.

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 tag plus a restatement of the tool title ('[trust] Drift certificate'), with no verb indicating what operation occurs. An agent cannot tell whether it issues, fetches, or validates a certificate, nor how it differs from the sibling drift_check.

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 guidance on when to use this versus alternatives, despite a directly related sibling (drift_check) plus trust_score and agents_reputation. Nothing indicates preconditions, context, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and closed-world, so the safety profile is covered structurally. The description contributes nothing beyond that: it does not say what a drift verdict looks like, whether thresholds apply, what the model_id must reference, or what happens with empty windows. With annotations doing the work, this is a clear miss on added behavioral context.

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 is under-specification rather than conciseness — there is no front-loaded statement of purpose to build on. The internal codename consumes the limited space that could have carried meaning.

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 three-required-parameter statistical-drift tool with two nested objects, no output schema, and no parameter documentation needs a real explanation of inputs and verdict semantics. The description supplies none of it, leaving an agent unable to construct a valid call without guessing the window object shape.

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 all three required parameters, and two of them (reference_window, current_window) are nested objects whose shape is entirely undisclosed. The description offers no clue about the expected structure of those windows (time range? sample set? metric map?) or the format of model_id. This is the exact case where the description must compensate and it does not.

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 essentially the tool name plus an internal codename ("DriftGuard check (DRG-100-DriftBound)"), restating the title rather than explaining what a drift check does, what is checked against what, or what it returns. The "[trust]" tag hints at a domain but conveys no operation. An agent cannot distinguish this from siblings like drift_certificate or agents_semantic_diff on the basis of this text.

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, when not to, or how it relates to the many plausible alternatives (drift_certificate, agents_semantic_diff, forge_verify). Nothing signals prerequisites such as needing a prior reference snapshot. The codename adds no selection signal for an agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the safety annotations (e.g., `idempotentHint: true`), the description provides high-value behavioral context by explaining the core logic: the enforcement happens through recomputation and a green verification. It also introduces a rate limit (3 free calls).

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 extremely concise and dense, front-loading critical business logic and operational constraints (recomputation, green verification, rate limits) without any filler.

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?

Despite having no output schema, the definition is complete for a tool of this nature. It defines the conditions for success (green verification) and the operational boundaries (rate limits and entitlement).

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?

With 100% schema description coverage, the definition meets the baseline for parameter semantics. It adds high-level context to the input structure by classifying the inputs as the 'work payload to verify' and the 'claimed digest the obligation is conditioned on.'

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 tool clearly states its purpose is to 'Enforce an SLA/obligation by recomputation.' It identifies the action (recomputation) and the mechanism (verifying work against a claimed digest).

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 definition sets clear usage criteria: the obligation is met 'only if the work verifies GREEN.' Additionally, it provides crucial operational constraints regarding call limits (3 free calls/day).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly=false, destructive=false, idempotent=false, openWorld=false, so mutation and non-idempotency are known. The description adds nothing beyond that: no mention of funds being locked, what happens on duplicate calls (non-idempotent means real financial risk), or permission/balance requirements for a money-moving operation.

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 the brevity is under-specification rather than economy; a single six-word phrase cannot carry the semantics of a financial escrow creation tool.

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 non-idempotent, money-moving tool with a nested conditions object, 0% schema coverage and no output schema, the description leaves essentially everything unspecified: fund custody, condition schema, release path, and return value.

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% across five parameters, including a nested "conditions" object whose shape and semantics are entirely undocumented. The description says nothing about amount/currency format, payer/payee identifier expectations, or what conditions gate release, so it provides zero compensation 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 verb and resource ("Create ... escrow") with a modifier ("agent-to-agent"), so the core action is identifiable. But it never says what an escrow here entails (funds held pending release? condition-gated?) and gives no explicit differentiation from sibling escrow_release/escrow_dispute beyond the verb.

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, prerequisites, or alternatives are given. The agent must infer from the name alone that this is the first step before escrow_release or escrow_dispute, and nothing indicates what must exist (e.g., registered agents) before calling it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the safety profile is known without the description. The description adds nothing beyond that: it doesn't say what state the escrow enters, whether the action is reversible, what permissions are needed, or why the operation is flagged destructive. Given a destructive, idempotent mutation, at least one of those facts should be spelled out.

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 short phrase is front-loaded and free of filler, so nothing is wasted. But the brevity is under-specification rather than elegance — there is no structure, no second sentence carrying usage or behavioral detail.

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 destructive, state-changing DeFi operation with a nested unknown-shape parameter, no output schema, and zero schema documentation, the description supplies no information an agent would need to call it correctly. Nearly everything must be inferred from the tool name 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% and the description explains none of the three parameters. In particular, 'evidence' is a nested object with no documented shape or content expectations, and 'reason' has no stated format or length constraints. The description does nothing to 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?

The phrase 'Open escrow dispute' names a verb and resource, so the agent can infer it initiates a dispute on an existing escrow. However, it does not distinguish this from siblings like escrow_create, escrow_release, or verify_settlement, and the bracket tag '[defi]' adds no disambiguation. Purpose is inferable but not sharply defined.

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 open a dispute versus releasing escrow or creating one, no prerequisites (e.g., must the escrow exist or be funded?), and no mention of alternatives among the escrow_* siblings. The agent must guess the trigger conditions entirely.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description is highly minimalistic and does not add any unique behavioral context beyond what is already signaled in the annotations (e.g., destructiveHint: true). It fails to describe specific operational constraints like rollback possibility or latency.

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 definition is extremely concise, fitting the format of a single, focused phrase. Every character serves the purpose of identifying the core action and domain.

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 that this is a destructive financial operation (confirmed by annotations), the description should provide basic context on the operational state or prerequisites for a release. The description is too brief to assist an agent in making a financially responsible decision.

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?

With 0% schema description coverage, the description was expected to define the `escrow_id` parameter. Since it is absent, and the parameter is a simple string ID, the description adds no semantic value or guidance beyond the tool's general function.

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 clearly identifies the action (Release funds) and the domain ([defi]). However, it is a general statement of purpose and does not distinguish this function from other similar tools like `escrow_create` or `escrow_dispute` within the sibling set.

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 description offers zero guidance on when or under what circumstances the funds should be released. It provides a simple declaration of the tool's function but gives no context regarding prerequisites, decision points, or workflow relative to other escrow tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description contributes nothing beyond that — no explanation of what a quality badge contains, where it comes from, or what happens when a model has no badge.

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 with no waste, but at five words including an opaque bracketed tag it is under-specified rather than concise. The '[fuse]' prefix consumes attention without conveying anything actionable.

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 simple single-param read tool this is nearly adequate, but with no output schema the description should at least say what a badge is and what the caller gets back. The agent is left guessing the return shape and the meaning of the 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?

With a single parameter and 100% schema description coverage, the schema fully documents 'model' including an example ('gpt-4o'). The description adds no meaning beyond it, so the baseline 3 applies.

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 fragment, 'Model quality badge', that essentially restates the title and adds no verb describing the action. Only by reading the schema ('fetch the quality badge for') does an agent learn this is a retrieval operation rather than a generation/forging one, and it is not distinguished from siblings like forge_verify or forge_leaderboard.

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 call this versus alternatives. The prefix '[fuse]' is unexplained jargon and does not signal a usage condition, and none of the related forge_* or quality/verify siblings are referenced.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate a non-idempotent mutation that is not read-only, not destructive, and closed-world. The description adds nothing about what happens to the model on submission, whether validation or rejection is possible, whether the change is reversible, or what authorization is required — the burden annotations leave open.

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 cryptic fragment prefixed by a bracketed tag. It is not verbose, but it is under-specified rather than concise; nothing is front-loaded beyond the bare verb and object.

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 a mutation tool with a nested object parameter, no output schema, and no annotations covering behavior beyond hints, the description is far too thin. An agent could not reliably construct a valid call or predict the effect without inspecting external knowledge.

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 three parameters, including a nested opaque 'delta' object, are entirely undocumented. The description's phrase 'model delta' weakly implies delta is the payload and model_id identifies the model, but it gives no structure, format, or constraint information for any parameter.

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 verb and a resource ('Submit a model delta'), so the general action is inferable, but 'delta' and the '[fuse]' prefix are unexplained jargon. It does not distinguish this tool from the many forge_* and ratchet_* siblings, leaving the agent unsure what a 'model delta' means in this ecosystem.

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 guidance on when to use this versus forge_verify, forge_badge, ratchet_advance, or other mutation siblings. There is no mention of prerequisites, model ownership, or what conditions make a submission valid.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: no hint about what is ranked, whether results are cached/live, how many entries are returned, or how scoring is computed.

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?

Two words with zero waste, which is maximally concise, but the size is driven by under-specification rather than discipline. There is no front-loaded statement of action or return content beyond the bare label.

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 carries the full burden of explaining what the leaderboard contains, its ordering, and roughly what an agent gets back. 'Model leaderboard' leaves all of that to guessing, so it is not complete enough to call the tool 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 there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The only shortfall is that the description does not say the call is argument-free or what the implicit selection criteria are.

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 'Model leaderboard' is a noun phrase that largely restates the title 'Forge Leaderboard', only clarifying that the subject is models. It names no verb (list? get? compute?) and does not distinguish this from siblings such as forge_badge, forge_verify, or forge_delta_submit, so an agent cannot tell what the tool actually does.

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 exclusions, and no mention of alternatives. At best the word 'leaderboard' faintly implies a read of rankings, but nothing tells an agent why to reach for this over forge_badge or trust_score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, and openWorldHint=false. The description adds no behavioral context about what is quarantined, whether the action is reversible, what permissions are needed, or what side effects to expect.

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 only three words, which is concise but not usefully front-loaded. The '[fuse]' tag is unexplained and the fragment is under-specified rather than efficiently 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?

For a destructive, zero-parameter tool with no output schema, the description does not say whether invocation performs a quarantine or lists quarantined models, nor what happens when called. This leaves the agent unable to predict effects and makes the definition inadequate.

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 the baseline is 4; there are no parameter semantics for the description to explain. Schema coverage is 100%, and no additional parameter guidance 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 ('Quarantined models') prefixed by an unexplained '[fuse]' tag; it does not state a verb or clarify whether the tool lists, creates, or releases quarantines. It effectively restates the title and gives no differentiation from sibling forge 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?

There is no indication of when to call this tool, what preconditions exist, or how it relates to alternatives such as forge_verify or forge_badge. The agent is left with no routing guidance beyond the name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds no further behavioral context about what verification entails, whether it has side effects, or what output to expect. It does not contradict the annotations.

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 sentence and is front-loaded with the main action. However, the unexplained "[fuse]" prefix adds noise, and the extreme brevity leaves the tool under-specified for an agent trying to invoke it correctly.

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-parameter verification tool with no output schema and zero schema descriptions, the definition is incomplete. The agent cannot determine what verification_type means or what constitutes a successful verification, even though the annotations cover the safety profile.

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 undocumented. The description does not clarify the format of model_id or what values verification_type accepts, so it fails to 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 states a specific verb and resource: "Verify a model submission." However, it does not explain what "verify" actually checks, and the "[fuse]" prefix is opaque. It also provides no differentiation from nearby siblings such as forge_delta_submit, forge_badge, or verify_settlement.

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, when not to use it, or which alternatives to prefer. Usage is only implied by the name and description, leaving the agent to infer the context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered structurally. The description adds nothing on top: it does not say what identity is checked (the caller? an ambient agent context?), given there are zero parameters, nor what a positive vs negative result implies.

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 short because it is under-specified rather than efficient; the single bracketed fragment carries no front-loaded actionable information. Nothing in the text earns its place beyond the name.

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 output schema, the description should explain what comes back from a sybil check (score, boolean, report) and what input it implicitly evaluates; it says neither. The tool is structurally simple and its annotations are rich, but the description still leaves the core question of 'what does this return' unanswered.

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 per the baseline this dimension is scored at 4. The description neither helps nor hurts here, though it could have explained what implicit context (caller identity) substitutes for parameters.

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 effectively the tool name restated with a bracket tag: "[identity] Sybil-resistance check" adds no verb, scope, or target beyond what identity_sybil_check already conveys. It does not distinguish this from close siblings like identity_verify, trust_score, or agents_reputation, which an agent would need to choose between.

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 run this check, what triggers it, or what alternative to use instead. With 45+ siblings and several adjacent identity/trust tools, the absence of any routing guidance leaves selection entirely to inference from the name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, covering the safety profile. The description adds nothing beyond that — no statement of what a verification result means, whether it fails closed, or what state it reads.

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 this is under-specification rather than conciseness — the single sentence carries a bracket tag and a jargon word and no actionable content. Brevity here costs the agent information rather than saving it noise.

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 output schema, the description must explain what a verification attempt returns and what 'topological' identity means in this system; it does neither. For a verification tool this is a substantive gap, only partly offset by the rich annotations.

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, agent_id, with 0% schema description coverage; only an example value ('my-agent-001') is given. The description does not say what an agent_id must be (registered? DID? name?) or whether it must exist, so the coverage gap is left unaddressed.

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 'Topological identity verification' largely restates the tool name and adds an unexplained qualifier ('topological') without saying what is actually verified or against what. It does not distinguish this from the sibling identity_sybil_check, so an agent cannot tell which identity tool applies.

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, despite identity_sybil_check and trust_score sitting right next to it in the sibling list. An agent has nothing to route on except the tool name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, covering the safety profile. The description adds only the vague phrase 'hallucination guard' without explaining what the guard does, how it behaves, or any limitations, so it contributes minimal behavioral context beyond the annotations.

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 phrase with no wasted words and is front-loaded. Its brevity is appropriate in form, though it is arguably too minimal to be useful, which is penalized in contextual completeness rather than here.

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 output schema and a single required parameter, the description should at least clarify what the tool returns, what the hallucination guard means in practice, and any usage constraints. It provides almost none of that context, leaving significant 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?

Schema description coverage is 0% at the top level, and the description does not mention the required 'messages' parameter or its expected structure. Although the schema includes nested role/content descriptions and an example, the description itself adds no meaning beyond what is already in 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 states 'chat inference' and mentions a 'hallucination guard,' which gives a basic idea of the resource. However, it is vague about what the inference actually does beyond that, and it does not differentiate this tool from siblings such as inference_stream or oracle_hallucination.

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 exclusions, and no prerequisites. The description implies it is for chat inference but leaves the agent to infer the appropriate context entirely.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the remaining burden is describing the streaming behavior itself — chunk format, termination, whether partial results are usable — and none of that is present. 'Streaming' and 'chain-of-thought' are keywords, not disclosure, and with no output schema the description is the only place this could have been explained.

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, with no filler sentences. But the brevity here is under-specification rather than economy, so it earns only a middle score.

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 streaming tool with no output schema and no parameter documentation needs the description to explain the return channel and result format; it does neither. An agent knows the name of the capability but not enough to call it correctly or interpret the response.

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 'messages' parameter; the schema only carries inline descriptions on the nested role/content fields. The description says nothing about message ordering, whether a system message is allowed, or how the array shapes the output — leaving the one parameter effectively undocumented in prose.

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 verb-ish phrase ('Streaming inference') plus a distinctive modifier ('chain-of-thought'), which hints at how it differs from the sibling 'inference' tool. However, '[inference]' merely repeats the resource and the phrase is terse; it never states what the tool actually produces or how streaming differs operationally.

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 statement of when to choose this over the sibling 'inference' tool, no prerequisites, and no exclusions. The word 'Streaming' implies a use case but the agent must infer it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare idempotentHint=true, destructiveHint=false and no open-world access; the description reinforces idempotency, adds that no key or payment is required, and tells the agent the response is a verbose setup payload rather than a terse result. One gap: readOnlyHint=false suggests the call may write state, and the description's 'one-command bootstrap' phrasing leaves it ambiguous whether the tool ever executes anything or only reports a command.

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 front-loaded sentence with the routing cue first and the payload contents enumerated after. Some promotional filler ('Atomadic control surface', 'proves the superpowers') consumes space without informing the agent.

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 output schema, the description must describe the return payload and it does, at a useful level of granularity. The only real omission is output format/verbosity expectations and whether the returned bootstrap command is meant to be run by the agent.

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 100% and the single optional agent_id is fully documented in the schema as an onboarding-state tracker, so the schema carries the parameter burden. The description never mentions agent_id and adds nothing beyond the schema, which is the expected baseline here.

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 does real work for an opaque name like 'murmuration': it states the tool initializes the caller into the platform and enumerates exactly what comes back (setup steps, runnable demo, recon links, bootstrap command). That is enough for an agent to recognise it as the onboarding entry point rather than one of the domain siblings, though it never states the action in a single plain verb+resource phrase.

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?

'START HERE (free, no key)' plus 'Idempotent - re-call anytime to re-check' gives clear first-call and re-call guidance, and 'free, no key' removes the main reason to hesitate. It stops short of naming when not to use it or pointing at a sibling for the actual work that follows onboarding.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds nothing beyond that — it does not say what an "epoch" is, whether freshness/rotation matters, or what constraints or costs apply.

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 is certainly compact, but this is under-specification rather than conciseness: it is too short to front-load any real information. Still, it wastes no words.

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 output schema and no parameters, the description is the only place an agent could learn what calling this returns and how to interpret an entropy epoch. That information is entirely absent, so an agent cannot confidently use the 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?

Zero parameters, so the baseline of 4 applies; there is nothing the description needed to disambiguate. No credit above baseline because it contributes no additional 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?

"Entropy epoch oracle" restates the tool name nearly verbatim and never states what the tool actually does — whether it reads the current entropy epoch, returns a value, or registers something. The "[trust]" prefix only hints at a category. It gives no way to distinguish it from rng_quantum, rng_verify, or defi_oracle_verify.

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, no prerequisites, and no mention of the adjacent tools (rng_quantum, rng_verify, defi_oracle_verify, oracle_hallucination) that could be confused with it. The agent must guess the selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds nothing on top of that – no indication of what a verdict looks like, whether confidence is returned, or what latency/cost to expect from an 'oracle' call.

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?

At four words there is no verbosity to trim, but the extreme terseness is under-specification rather than conciseness. The bracketed '[trust]' tag consumes part of the already minimal budget without conveying actionable meaning.

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?

There is no output schema, so the description should explain what the oracle returns (verdict, score, rationale), and it does not. For a verification-style tool with an unfamiliar 'oracle' framing, an agent has no basis for interpreting results or deciding between this and its many verification siblings.

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%, with two parameters ('claim' and 'context') documented only by terse examples. The description does not explain the expected claim granularity, whether context is free-form domain text or a controlled label, or how the two interact – the description carries full burden here and fails it.

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 'Hallucination oracle' is a noun phrase that restates the tool name and title without a verb or an object of action. An agent can guess it evaluates a claim for hallucination, but nothing states that this is a factuality/verification check rather than, say, a generator of hallucinated content.

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 call this versus neighbors such as detect_contradiction, agents_contradiction, forge_verify, or compliance_check. The '[trust]' prefix hints at a category but does not tell the agent what condition selects this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered by structured fields. The description adds only the word "Trusted", which is an unverifiable quality claim rather than disclosed behavior — no indication of what source corpus is consulted, whether results are deterministic, or what latency/rate characteristics apply.

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 with zero filler, but the brevity here is under-specification rather than discipline — a single vague phrase does not earn its place as the entire definition.

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?

Even for a zero-parameter tool with full annotation coverage and no output schema, the description never explains what "augmentation" produces or how a caller should interpret the result. The annotations supply safety facts, but the functional contract is entirely 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 gap for the description to fill.

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?

"RAG augmentation" restates the tool name with no specific verb, resource, or operation detail — an agent cannot tell what is being augmented (a query? a context window? a document set?) or what the tool produces. Nothing distinguishes it from generic inference siblings like `inference` or `text_summarize`.

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 description contains no when-to-use guidance, no prerequisites, and no mention of alternatives such as `inference`, `inference_stream`, or `text_summarize`. The `[inference]` tag is a category marker, not usage instruction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the agent knows this is a non-idempotent mutation. The description adds nothing beyond that: it does not disclose what state is changed, whether an advance is irreversible, what happens on an invalid or expired session, or what errors to expect. For a stateful non-idempotent mutation with no output schema, this is a serious disclosure 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?

It is short, but this is under-specification rather than conciseness: nine words, of which four are a bracketed identity tag and two restate the title. There is no front-loaded statement of effect or return, so the brevity costs the agent all actionable information.

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 non-idempotent, state-mutating session tool with zero schema description coverage and no output schema, the description supplies nothing an agent needs: no effect, no precondition, no result. Every behavioral question is left unanswered.

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 carry the load, and it says nothing about session_id. The only aid is the schema's "sess-001" example, which conveys format but not provenance, validity rules, or whether the session must already exist. The parameter name is self-explanatory enough to avoid a 1.

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?

"advance session" restates the tool name (Ratchet Advance) and adds no resource detail: it never says what a session is, what "advancing" does, or what state transition occurs. The "[identity] RatchetGate" tag hints at a domain but is not a purpose statement. An agent cannot distinguish this from ratchet_register or any other session-mutating sibling on the basis of this text.

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 mention of the obvious alternative ratchet_register despite it being in the sibling list. Nothing tells the agent whether a session must first be registered, whether advancing is repeatable, or what triggers a call.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already fully declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description's only added information is that this is a health probe, which implies a non-mutating status check but does not say what it inspects or what a failure indicates.

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 phrase with no padding. However, the '[identity]' bracket tag and the mojibake '—' character are noise that slightly degrades legibility.

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 zero-parameter, annotation-covered probe, an agent can call it correctly, but the description is silent on what the probe verifies and how to interpret the outcome, which is the main substantive gap left for a health-check tool.

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. There is no parameter meaning for the description to add or omit.

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 the tool as a 'health probe' for RatchetGate, which conveys a recognizable function, but it lacks a specific verb and gives no way to distinguish it from siblings like ratchet_advance or ratchet_register. The '[identity]' prefix reads as an internal tag rather than a description of 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 statement of when to call this probe, what a healthy vs unhealthy result means, or how it relates to the other ratchet_* tools. The agent must infer that 'health probe' means liveness/readiness checking.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds nothing beyond that — no statement of what a registration does, whether it requires prior identity verification, or what a re-register of an existing session_id returns. It does not contradict the annotations, but it contributes zero behavioral context.

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?

Extremely short, but short due to under-specification rather than efficiency. The line is also marred by a character-encoding artifact ("—"), and its leading bracketed tag conveys no actionable information.

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?

The tool is simple (one required string parameter, no output schema), so it does not need volume — but it still needs to say what registering a session produces and how it relates to ratchet_advance. With no output schema and no description of effects, an agent cannot predict the result of calling 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% for the single parameter; only a bare example ("sess-001") is present. The description does not explain the origin, format, or lifecycle of session_id (client-generated? returned by another call?), so it fails to 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?

The description is a bracketed tag plus a restatement of the title: "[identity] RatchetGate — register session". It names a resource (session) and a loose verb (register), but never says what registering a session accomplishes or what state it creates. It also gives no way to distinguish this from siblings like ratchet_advance, agents_register, or sla_register.

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 versus any of the ~48 sibling tools, no prerequisites, and no ordering hint (e.g., relative to ratchet_advance). The agent must guess entirely from the name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare idempotent, non-destructive, closed-world behavior. The description adds meaningful context beyond that: deterministic computation, the verified-minus-refuted formula, free-call limits, and entitlement requirements. It does not explain why readOnlyHint is false or what side effects, if any, occur.

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 compact and mostly front-loaded, with the core purpose stated immediately after product metadata. The entitlement and free-call note is useful but slightly interrupts the main explanation.

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 one-parameter tool with annotations and no output schema, the description covers the input source and computation method adequately. It still leaves the return value shape unspecified and lacks sibling routing guidance, which would help an agent choose this tool over related reputation and trust tools.

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 100%, so the single receipts parameter is already documented. The description adds the formula 'verified minus refuted,' but it does not explicitly map the 'ok' boolean or optional 'score' field to that computation, so it only marginally extends 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 states a specific action and resource: computing an agent's reputation from a ledger of verifiable receipts. It also clarifies the deterministic receipt-based mechanism and contrasts it with LLM judgment. However, it does not explicitly name or distinguish itself from sibling reputation tools such as agents_reputation, trust_score, or reputation_record.

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 description implies the use case: computing reputation when a ledger of verifiable receipts exists. It adds entitlement and rate-limit context, but gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance relative to the many reputation-related siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds value beyond that by disclosing the return keys {ok, ir, results, languages} and the entitlement/demo constraint (FREE_R2_DEMO), which is real behavioral context.

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?

Very short and front-loaded: the action comes first, then the return shape, then the demo/SDK note. Dense with bracket jargon but no sentence is wasted.

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?

Return keys and entitlement are covered and no output schema exists, so a good deal is present. But with 0% schema coverage and an opaque required 'atom_name', the definition leaves a critical input unexplained for an agent to call it reliably.

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 both parameters have empty schema descriptions, so the description must carry the burden. It never explains what 'atom_name' means or what form 'source_text' takes — the two most important facts for invoking the tool correctly.

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 concrete action and scope: emit to all 7 supported targets in one call, and names the return shape. The verbs/resource are specific enough to distinguish it from the listed siblings, none of which are polyglot/emit tools, though 'Polyglot' and 'atom' remain 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?

'Canonical demo examples baked to R2; novel inputs via SDK' hints at a demo-vs-SDK split but never says when an agent should call this instead of an alternative, nor states preconditions. No explicit when/when-not guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds entitlement and demo/live behavior context, but does not describe the output shape, failure behavior, or what atom_name controls.

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 with the core transformation, but the bracket prefix and dense jargon ('Syntax-as-Data polyglot render head', 'R2') consume space without adding clarity for an agent.

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 output schema and 0% schema description coverage, the description should explain the three parameters and the expected output. It leaves atom_name undefined, does not specify target language identifiers, and says nothing about the rendered result, making it incomplete for a callable rendering tool.

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 three undocumented parameters. It hints that source_text is the source and language is the target language, but atom_name is completely unexplained and no parameter formats or allowed language values are given.

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 specific transformation pipeline: source -> language-neutral logic IR -> source in target language, which is more than a tautology. It does not distinguish this tool from the sibling render_polyglot_all_pure, and jargon like 'Syntax-as-Data polyglot render head' slightly obscures 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?

Usage is implied by the pipeline description and the note that canonical demo examples are baked while novel inputs are emitted live. It does not explicitly say when to use this instead of render_polyglot_all_pure or other siblings, nor does it state prerequisites or exclusions beyond the entitlement tag.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare that this is a non-read-only, non-idempotent, non-destructive mutation, so the safety profile is covered structurally. The description adds nothing beyond that — no mention of whether records are permanent, whether duplicate records accumulate (consistent with idempotentHint=false), or whether the outcome value influences other scoring tools like trust_score.

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 is under-specification rather than efficiency — four words that omit the essential semantics of a write tool. There is no front-loaded scope statement or qualification clause.

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 four undocumented parameters, a mutation with no output schema, and no explanation of side effects, the description leaves nearly everything an agent needs in order to call this correctly unspecified. Only the annotations carry behavioral meaning.

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% across four parameters, yet the description names none of them. An agent gets no explanation of what interaction_type accepts (free string with no enum), whether counterparty_id is optional-contextual or required in practice, or how outcome should be chosen.

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 verb ("Record") with an object ("agent interaction"), so the basic action is inferable, but it never states what a reputation record contains or how it differs from siblings like agents_reputation or trust_score. The bracketed "[agents]" prefix reads as a namespace marker rather than meaningful scope information.

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 call this instead of agents_reputation, trust_score, or forge_verify, despite a crowded sibling set where routing ambiguity is high. The only implicit guidance is that it is a write (record), which annotations already convey.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds only the vague phrase 'with proof', without saying what the proof is, how it is formatted, or whether the randomness is verifiable against a public beacon. The '[inference]' prefix is unexplained and adds ambiguity rather than clarity.

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?

At eight words it is certainly short and front-loaded, but it is terse to the point of under-specification. The bracketed '[inference]' tag consumes space without conveying usable meaning.

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?

There is no output schema, so the description carries the full burden of explaining the return value — and 'with proof' is not explained at all (format, verifiability, size). For a tool whose entire value proposition is a verifiable random value, this leaves the agent guessing about what it will receive.

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 disambiguate; baseline 4 applies. No argument syntax is needed for a no-argument call.

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 noun phrase 'Quantum random number with proof' identifies the resource but supplies no verb, so it is unclear whether the tool generates a new number, fetches one, or returns a proof artifact. Nothing distinguishes it from the sibling rng_verify, which likely consumes the output of this tool.

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 versus rng_verify, nor any prerequisite, cost, or latency context. The agent must infer the relationship between the two rng tools entirely on its own.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered structurally. The description adds only an opaque "[inference]" tag and leaves the core behavior unexplained: whether verification is local or remote, what failure looks like, or what a positive result means.

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 clause that is front-loaded and wastes no words. The "[inference]" prefix is unexplained noise rather than useful signal, which keeps it from a 5.

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 output schema, the description carries the burden of explaining what verification returns (a boolean? a proof? the value itself?), and it says nothing. For a cryptographic-intent tool, the description is too thin for an agent to predict results or interpret them.

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 per the rubric the baseline is 4. Nothing in the description contradicts the empty schema; if anything it correctly implies no inputs are required beyond the current epoch context.

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 verb ("Verify") with a resource ("current epoch random value"), which is more than a restatement of the name. However, it never specifies what is being verified against (a commitment, a proof, a beacon) or how it differs from the sibling rng_quantum, so an agent must guess at the actual operation.

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 guidance on when to call this versus alternatives such as rng_quantum, and no preconditions stated. The sibling list contains an obvious sibling but the description never routes to or away from it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds meaningful context beyond those: it identifies the product area, the entitlement, and a rate limit (3 free calls/day), which helps an agent anticipate access constraints.

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 compact and front-loads the action. The bracketed entitlement metadata is useful but slightly redundant with the later entitlement mention, preventing a perfect score.

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 one parameter, no output schema, and clear annotations, the description covers the core action plus entitlement and rate limits. However, it does not clarify what a 'capability/pipeline coordinate' looks like, how routing differs from similar tools, or what the agent should expect back.

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 100%, so the single parameter is already fully documented. The description only restates that the intent is natural-language and routes to a coordinate, adding no syntax or format details 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 states a specific verb (Route) and resource (natural-language intent to a deterministic capability/pipeline coordinate), making the core action clear. It does not explicitly distinguish itself from similar siblings like agents_intent_classify or inference, which prevents a 5.

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 such as agents_intent_classify or inference. The rate-limit and entitlement note is a constraint, not a usage guideline, and no exclusions or prerequisites are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, non-destructive, and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing beyond that — no indication of whether assessment is heuristic, model-based, or deterministic, and no note that it operates on closed-world data only.

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 that brevity comes from under-specification rather than efficiency; the single bracketed fragment carries no actionable content.

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 a free-form nested object parameter, no output schema, and no parameter documentation, the description leaves the agent unable to construct a valid call or anticipate results. Annotations cover safety only, not the information gaps here.

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% across two parameters, including a nested 'context' object whose expected keys are entirely undefined. The description does not compensate at all, leaving 'context' effectively unusable.

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 'Zero-day threat assessment' essentially restates the tool name and title without specifying what operation is performed on the target or what kind of assessment result is produced. It gives no signal distinguishing it from sibling tools like threat_score or defi_risk_score.

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, when to prefer threat_score or identity_verify instead, or what preconditions apply. The agent must guess entirely from the name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing beyond that - no prerequisites, no statement about whether re-registration overwrites or returns the existing record (which idempotency implies), no note on provider/consumer consent or authorization needs.

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 the brevity is under-specification rather than efficiency. The single fragment omits information that would earn its place, so length is not a virtue here.

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 mutating tool with an undocumented nested object parameter, no output schema, and zero parameter descriptions. The description supplies none of the missing context - not the shape of the SLA terms, not the identity semantics of provider versus consumer, not the return value.

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% across three required parameters, and the key one ("terms") is a free-form nested object whose shape is completely undefined. The description provides no compensating information about what provider_id, consumer_id, or the terms object should contain, so an agent cannot construct a valid call from the text.

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 "[agents] Register an SLA" essentially restates the tool name and title. It names a verb and resource, but there is no scope, no detail on what an SLA record contains, and no differentiation from siblings such as sla_report or escrow_create. The bracketed "[agents]" prefix is noise rather than clarification.

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, when-not-to-use, or alternative is stated. The presence of a sibling sla_report that clearly relates to the same resource makes the absence of routing guidance a real cost, though nothing is actively misleading.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the agent knows this is a non-read-only, non-destructive, non-idempotent operation. The description adds no context about what reporting actually does, side effects, permissions, notifications, or expected response.

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 extremely short and front-loaded, but this is under-specification rather than useful conciseness. It spends its few words on a namespace tag and a vague action without conveying actionable detail.

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 three parameters, no parameter descriptions, no output schema, and only basic annotations, the description is far too thin. It does not tell the agent what a valid violation report needs, what happens after reporting, or how to interpret the 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?

Schema description coverage is 0% for all three parameters, and the description does not explain sla_id, violation_type, or description. It provides no meaning beyond the bare parameter names, leaving required fields like violation_type completely unspecified.

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 an action and resource: 'Report SLA violation,' so an agent can infer this is about submitting an SLA violation. However, 'Report' is ambiguous (create a report vs. file a violation), and the definition does not distinguish it from sibling tools such as sla_register or compliance_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 guidance on when to use this tool, when not to use it, or which sibling tool to choose instead. The agent must infer its role from the name and the terse phrase 'Report SLA violation.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is fully covered and the description adds nothing new. Critically, it does not disclose the one behavior that matters here: whether polling consumes/drains messages or leaves them in place for repeat reads.

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?

Four words, front-loaded with the scope tag and the operation, with no filler. Given the empty schema, brevity is defensible, though it is arguably too little to be useful rather than tight.

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 output schema and no annotations describing payload, the description should explain what a poll returns (message list shape, ordering, empty-state) and whether messages are acknowledged. None of that is present, so an agent knows only the name of the operation, not what it will get back.

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, which is the baseline-4 case; there is nothing for the description to disambiguate. The schema fully covers the (empty) input surface.

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 verb+resource ('Poll swarm inbox') and the '[agents]' tag hints at agent-scoped messages, so the general domain is clear. But it never says what an 'inbox' holds (messages, tasks, relays?) or how it relates to siblings like swarm_relay, so an agent cannot sharply distinguish it from adjacent swarm 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?

There is no statement of when to call this versus alternatives such as swarm_relay, nor any note about polling cadence, frequency limits, or whether it should be called repeatedly. Usage is only weakly implied by the word 'Poll'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the key safety traits: not read-only, not idempotent, not destructive, and closed-world. The description adds no delivery semantics, routing behavior, failure modes, or permission requirements beyond those annotation hints.

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 concise and front-loaded, with no wasted words. But it is under-specified rather than appropriately informative, so brevity comes at the cost of usefulness.

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 relay tool with a nested message payload, no output schema, and only partial annotation coverage, the definition is missing too much. An agent would not know expected delivery behavior, return values, or how to structure the message object.

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 only 33%, and the description does not compensate. The required target_agent_id and nested message object are undocumented, and even the ttl hint exists only in 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 states a verb ('Relay') and resource ('message through swarm'), giving a minimal sense of what happens. However, it is vague about what relaying entails and does not clearly differentiate it from siblings such as swarm_inbox or agents_register.

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?

It provides no guidance on when to use this tool versus alternatives like swarm_inbox or other agent tools. There are no prerequisites, exclusions, or contextual cues.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond the bracketed "[inference]" tag — no mention of model-based extraction behavior, determinism of results, or typical keyword count, so the marginal value is minimal.

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 text is short but that reflects under-specification rather than conciseness — it is a two-word fragment with no front-loaded statement of action, inputs, or output. Brevity here costs information instead of saving it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.