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

With no annotations provided, the description carries the full burden. It discloses what the tool returns (triage recommendation, trust signal, decision-readiness score, missing trust evidence), its scope ('Evidence triage only'), and a key operational constraint (human review required). It does not mention authentication requirements or side effects, but 'triage' and 'evidence triage only' imply a read-only analysis.

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 dense but purposeful: purpose, input contract, return values, scope boundaries, and human-review requirement are all covered in three sentences. It is front-loaded with the core purpose. The only minor redundancy is repeating the 'evidence triage only' boundary after already saying 'not cybersecurity monitoring, identity verification, or authorization'.

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 the nested input object, no output schema, and no annotations, the description does a solid job: it specifies the required input shape, the return components, the non-goals, and the human-review requirement. The reference to an external schema file and get_schema adds a small dependency, but the description is still sufficient for an agent to decide whether to invoke this tool and what to pass.

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% because trust_request has a description, so the baseline is 3. The description adds the list of key fields (actor, target_surface, requested_action, dated_sources, risk_question, decision_stage) and references the schema file, but it does not explain the semantics of each field beyond their names. The schema's own description points to get_schema for the full nested contract, which is helpful but not fully self-contained.

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 opens with a specific verb and resource: 'Triage the trust evidence for an agent-mediated interaction' before a high-stakes action. It also names the exact input contract and output components, and explicitly distinguishes itself from cybersecurity monitoring, identity verification, and authorization, making it clearly separable from siblings like pre_action_check and validate_evidence.

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 clearly states when to use the tool ('before a high-stakes action executes') and what input to pass. It also provides exclusions ('not cybersecurity monitoring, identity verification, or authorization') and notes human review is required. However, it does not name specific sibling tools as alternatives, so the routing guidance is implicit rather than fully explicit.

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?

With no annotations provided, the description carries the full burden of the behavior, and it is unusually transparent: it says the tool reports per-claim findings, returns a relay verdict, and explicitly states it is evidence-readiness only and does not do factual validation, source fetching, or action authorization.

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 compact but information-dense: purpose, use-before conditions, input guidelines, output description, and limitations each earn their place. The most decision-relevant constraint is front-loaded in the first sentence.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one required nested object and no output schema, the description is complete enough. It covers what to pass, how it behaves, what will be returned, and what is explicitly not done, giving an agent a realistically safe basis to invoke and interpret 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 schema already documents the single audit_json parameter fully, so the baseline is 3. The description adds helpful operational meaning by requiring JSON matching evidence-audit.schema.json, listing claims, evidence records, and optional unsupported_claims, so the agent knows exactly what contract to satisfy and where to find more detail.

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: deciding whether another agent's claim-backed output is safe to relay. It goes further by naming the value it produces: which claims are grounded, which are unsafe to relay, and which evidence references are orphaned, positioning it clearly against related verification tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly lists when to use it: before forwarding, publishing, or acting on downstream claim-backed output. It gives clear exclusions by noting it does not verify factual truth, fetch sources, or authorize action; however, it does not name a specific sibling tool as the alternative for those cases, so the guidance is strong but not fully routed.

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?

With no annotations provided, the description carries the full burden. It discloses several key behaviors: it returns a validated memo, or when ANTHROPIC_API_KEY is unset returns the assembled system_prompt for the host model to complete. It also clearly states limitations: 'No live source retrieval and no legal, compliance, financial, or investment advice.' This is valuable behavioral context beyond what any structured field would provide. A minor gap: it doesn't explicitly state whether the tool is a write operation or how it interacts with other components, but the description is quite thorough for a tool with one parameter.

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 compact block of three sentences. The first sentence states purpose and scope. The second explains the request format and return behavior. The third lists limitations. Every sentence adds distinct value, no repetition, and key information is front-loaded. This is appropriately sized for the tool's complexity.

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 this tool has one nested parameter, no output schema, and no annotations, the description is quite complete. It covers what the tool does, when to use it, how the request is structured, the two possible return behaviors, and limitations. The only minor gap is that it doesn't detail the structure of the returned memo (output format) in depth, but since the request includes an output_format field and the sibling tools like validate_memo exist, an agent can infer the rest. This is solid coverage for a moderately complex 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?

Even though schema coverage is 100% and the request parameter is well-described in the schema (including an example and description), the description adds critical semantics: it explains that the request must match 'agenda-request.schema.json' and mentions the return behavior variation. It also references get_schema('agenda_request') for the full contract. This goes beyond the schema's basic property list, helping the agent understand how to construct the request properly. A 4 is appropriate since the schema already does heavy lifting, but the description adds meaningful guidance.

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 states the tool's purpose: it generates an auditable strategic-risk memo from a structured Agenda request. It specifies the resource (Agenda request), the output (validated agenda-memo or system_prompt), and the scope (sanctions, regulatory, geopolitical, trade, corridor, or policy-risk questions). This distinguishes it from siblings like validate_memo, audit_claims, or specific risk tools (cis_secondary_sanctions_exposure) which serve different functions.

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 explicitly states when to use: 'Use for sanctions, regulatory, geopolitical, trade, corridor, or policy-risk questions where the agent needs a memo with assumptions, scenarios, evidence discipline, and regional routing.' It doesn't explicitly name alternatives or when-not-to-use, but the context is clear enough that an agent could infer it's for memo generation rather than validation or specific deep dives. A slight deduction for not naming specific sibling tools as 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?

With no annotations, the description carries the full burden and does so thoroughly. It discloses deduplication behavior, consistency maintenance of unsupported_claims, conservative support_status defaults, return behavior, and explicit non-goals. This is exemplary transparency for a mutation 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?

The description is dense but every clause earns its place. It front-loads the core action and use case, then efficiently covers defaults, deduplication, return value, and boundaries without repetition or fluff.

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 6-parameter tool with nested objects and no output schema, the description is highly complete: it explains return value, defaults, deduplication, and non-goals. It does not detail the exact shape of the returned pack or error behavior, but that is a minor gap given the richness elsewhere.

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 baseline is 3. The description adds meaningful semantics beyond the schema: existing claims gain sources instead of duplicating, support_status default logic, and the pack_json/topic relationship. This elevates it above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Append a claim and its sources to an evidence pack and re-validate the result.' It clearly distinguishes this from validation/audit siblings by emphasizing incremental construction and explicitly listing non-goals such as verifying quotes or factual truth.

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 gives explicit context: 'Use when building an evidence pack incrementally as sources are read, instead of assembling the whole document by hand.' It also provides exclusions ('does not write files, fetch URLs...'), though it does not name alternative sibling tools directly.

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?

With no annotations provided, the description carries full burden. It clearly states the tool returns validity, support-level distribution, orphan evidence references, and unsupported-claim counts. It also explicitly declares what it does not do (verifying truth or source reputation). It does not mention destructive actions or authentication needs, but the non-destructive nature is implied by 'returns' statements.

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 with four sentences, each serving a distinct purpose: stating the core action, usage context, input requirement, and output summary with a limitation. No redundant 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?

Given the single parameter, lack of output schema, and annotations, the description covers all necessary aspects: what the tool does, when to use it, what input to provide, what it returns, and its limitations. It is fully adequate for the agent to use 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 coverage is 100%, and the description adds significant meaning beyond the schema: it specifies that audit_json should match evidence-audit.schema.json, which guides the agent on expected structure. This is a crucial detail not present in the schema's description.

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 states the tool validates a claim-level evidence audit and summarizes support quality. It specifies the resource (claim-level evidence audit) and the action (validate and summarize), distinguishing it from sibling tools like validate_brief and validate_evidence which likely operate on different scopes.

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 explicitly says when to use the tool ('after drafting or receiving a memo to check whether important claims point to evidence IDs...') and what it does not do ('does not verify factual truth or source reputation'), providing good guidance on appropriate contexts. However, it does not explicitly name alternative tools for different scenarios, which would strengthen the guidance.

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?

With no annotations provided, the description carries the full burden. It clearly states the tool is deterministic and local-text only, and explicitly lists what it returns (broken references, quote mismatches, etc.). It also clearly states what it does not do. This is strong behavioral disclosure, though it could add details on side effects (but it's read-only, which is implicit from local-text only). Score 4, not 5, because it doesn't explicitly state idempotency or error handling, but it's very transparent.

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 two sentences, with the first sentence front-loading the purpose and usage condition. The second sentence lists return types and exclusions concisely. Every clause earns its place, and it's neither verbose nor missing 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?

Given the tool has only one parameter with a nested structure, the description references get_schema for the full contract, which covers the parameter semantics. The output is described in terms of return values (packet_complete, etc.) and the exclusions are clear. There's no output schema, but the description lists the key output types. The tool is complex but the description covers everything an agent needs to decide whether to call it and what to expect.

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 baseline is 3. The description adds value by explaining the purpose of the packet_json parameter (claims plus complete source texts) and points to get_schema for the full contract. This goes beyond just naming the parameter, so it earns a 4.

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 states the tool checks a caller-provided evidence packet before human review, with specific verbs and resource. It distinguishes itself from siblings by listing its deterministic scope and what it does NOT do, which helps an agent differentiate it from tools like verify_claims or validate_evidence.

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?

Explicitly says 'Use when an AI output declares claims, source IDs, optional verbatim quotes, and the full supplied source text.' This gives a concrete trigger condition. It also lists exclusions ('does not retrieve sources, score source authority, assess factual truth, or authorize an action'), which helps an agent decide against using it for those purposes. However, it doesn't name specific sibling tools as alternatives, but the exclusions are enough to route 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?

With no annotations, the description carries the full burden. It discloses that the tool returns schema_valid separately from ok, does not verify factual truth, and checks for specific quality issues. This is fairly transparent about behavior.

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 two sentences: first defines purpose, second gives usage and behavioral notes. Every sentence is necessary and adds value, with no extraneous 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?

Despite no output schema, the description explains the return structure (schema_valid separate from ok) and lists what the tool catches. It is sufficiently informative for a single-parameter tool with 100% schema coverage.

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% with a clear parameter description. The tool description adds little beyond restating that the memo is 'schema-shaped,' so the parameter meaning is already adequately conveyed by 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 clearly states the tool checks an Agenda memo against evidence-readiness quality guardrails, listing specific failure modes. It distinguishes itself from siblings like validate_memo by noting it catches schema-valid but unsafe output and does not verify factual truth.

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?

Explicitly says to use after validate_memo or on any external model memo, and states what it does not do (verify factual truth). Provides context for when to use but lacks explicit when-not-to-use 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?

With no annotations, the description carries the full behavioral burden, and it delivers: it discloses that local stdio runs on user-supplied evidence only, that no live retrieval happens, that a name match is not identity verification, and that human review is required. It also names the exact output components returned.

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 information-dense and well-ordered: purpose, input contract, output, then operational caveats. It is longer than average, but the legal-regime enumeration and field listing are necessary for correct invocation. Slightly compressed phrasing would make it 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?

Despite having no output schema and no annotations, the description explains the required input shape, the legal review scope, the output dimensions, the evidence limitations, and the need for human review. This is adequate for an agent to select and 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 schema already provides 100% coverage for the single parameter, including nested object examples and a pointer to get_schema for the full contract. The tool description restates the key fields but does not add materially new semantics beyond what the schema already captures.

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 precise verb ('triage'), a specific resource ('secondary-sanctions exposure for a CIS-domiciled counterparty'), and enumerates the legal frameworks and jurisdictions involved. This clearly communicates what the tool does and distinguishes it as a specialized risk-assessment tool among the sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives concrete usage context: EU/UK/UAE/Singapore enhanced due diligence against OFAC EO 14114, EU sanctions, UK OFSI, and FATF/EAG typologies. It does not explicitly say when to prefer this tool over a sibling or when not to use it, so it falls short of full alternative routing guidance.

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?

With no annotations, the description carries the full burden and does so thoroughly. It discloses the iterative 'missing_required' return, the evidence_mode default, the scaffold behavior, the returned schema errors, and explicit non-side-effects: no file writes, source retrieval, prose drafting, or factual verification. This is far richer than a bare mutation or read hint.

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 tight paragraph with no filler. Every sentence earns its place: purpose, usage loop, scaffold behavior, default, and exclusions. It is front-loaded with the core action and gives enough detail without becoming a manual.

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 12 parameters, no output schema, and no annotations, the description covers all decision-relevant context: how to invoke iteratively, how to bootstrap with no arguments, what the response includes, and what the tool will not do. An agent has enough to select and call the tool correctly without further inference.

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 baseline is 3. The description adds value beyond the schema by specifying the evidence_mode default and the tool's missing-required reporting, which tells the agent how to use the 12 parameters iteratively rather than merely what each field means.

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 opens with a specific verb and resource: 'Assemble an agenda brief from supplied fields and report which required fields are still missing.' This clearly distinguishes it from siblings like validate_brief, which validate existing briefs, and get_schema, which returns schemas. It also states what it returns, making the purpose unambiguous.

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 an explicit usage pattern: call with known fields, read missing_required, call again with remaining fields, or call with no arguments for a scaffold. It also gives a default behavior ('evidence_mode defaults to reasoning_only') and states clear when-not conditions (does not write files, retrieve sources, draft prose, or verify factual truth), so an agent knows when to avoid 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?

The description fully discloses behavior: it only returns a planned status message, performs no analysis, and the aspect parameter is ignored. Without annotations, the description carries the burden and does so completely.

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 sentences with no wasted words. Front-loaded with the critical 'do not use' message, then provides alternative.

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 being a placeholder, the description is complete: explains purpose, current non-functionality, and alternative. No output schema needed for a status message 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 coverage is 100% and the schema already describes the parameter as optional and ignored. The description adds no new meaning beyond confirming it's ignored, so a 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?

The description clearly states this is a reserved placeholder for a future deep-dive workflow, differentiating it from sibling tools by explicitly directing to use 'analyze' instead. It specifies the tool's action: returns a status message and performs no analysis.

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?

Provides explicit guidance: 'Do not use for current detailed analysis' and 'For production work today, call analyze with request.depth set to scenario or red_team'. This clearly tells when to not use and identifies the alternative.

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?

With no annotations, the description carries the full burden and does a good job: it names the internal analysis steps (missing sources, misquoted excerpts, polarity mismatches, etc.) and the output form (structured markdown prompt). It stops short of disclosing edge-case behavior such as invalid or incomplete packet handling, but the core behavior is clear.

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 tightly packed sentences front-load the purpose and then enumerate the issue types and output format. Every phrase contributes meaning, and there is no redundant restating of the tool 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?

Given a single nested-object parameter and no output schema, the description covers the input purpose, analysis scope, and output type, and directs the agent to the full contract. It would be more complete with explicit return-value details or error behavior, but what is present is largely sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameter already has a baseline explanation. The description adds a useful pointer to get_schema('evidence_packet_request') and reinforces the parameter's purpose, but it does not elaborate on how each nested field is used. A 3 is appropriate since the schema carries most of the load.

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 distinct action ('Generate actionable self-correction instructions') and a specific resource ('from an evidence packet request'), then details the issue categories it inspects and the markdown prompt it produces. This clearly separates it from sibling validation/audit tools like validate_evidence or audit_claims.

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 use when repair instructions are needed from an evidence packet, but it does not explicitly state when to choose this over alternative tools, nor does it mention exclusions or prerequisites. An agent must infer the selection logic from the tool name and general 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?

No annotations exist, so description carries full burden. It discloses static markdown, idempotent nature, and limitations (no live events, no decision).

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 concise sentences front-loading purpose, then guidance, then behavioral notes. No redundancy.

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 no output schema, description states return type (static markdown) and clarifies non-live nature. Complete for tool's simplicity.

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%, baseline 3. Description adds context: parameters must be passed exactly as listed, lens_type is a family from list_lenses.

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 states the tool returns the full markdown for a lens, specifying the resource type (regional or sector) and distinguishing from list_lenses.

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?

Explicitly says when to use (after list_lenses for actual context) and what not to do (no live events, no decision-making). Provides instruction to pass parameters exactly.

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?

With no annotations, description fully describes behavior: returns markdown from installed package, no side effects, specific parameter hint. No contradictions.

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 sentences, no fluff. First sentence states purpose, second gives usage, third adds exclusions and parameter hint. Very efficient.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all necessary aspects: return type, usage context, initial parameter value, limitations. Complete for a simple retrieval tool with no output schema.

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% with description for 'name' parameter. Description adds specific guidance: 'Pass name=\"entrypoint\" for the main protocol', slightly exceeding baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Return packaged Agenda Intelligence protocol markdown' with specific verb and resource. Differentiates from sibling tools like audit_claims and validate_brief by specifying it returns protocol text, not analysis.

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?

Explicitly says when to use: 'when an agent needs the reasoning contract...' and what not to use for: 'does not analyze a question or validate user data.' Provides clear context for selection.

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?

Despite no annotations, the description fully discloses the tool's behavior: it returns a schema document and version, is read-only, and explicitly states what it does not do (validate data, fill templates, verify truth).

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 clear, well-structured sentences. Every word adds value, and the purpose is front-loaded.

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 the tool's simplicity (one optional parameter, no output schema), the description is complete: it explains purpose, usage, parameters, and limitations without 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?

The schema description coverage is 100%, and the description adds valuable context by listing example schema keys (agenda_brief, evidence_pack, etc.) and explaining the effect of omitting the 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 clearly states the tool returns a packaged Agenda Intelligence JSON Schema for constructing valid payloads before calling specific tools. It distinguishes itself from sibling tools by specifying its role in schema discovery, not validation or analysis.

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?

Explicitly tells how to use the name parameter (provide a key, file name, or omit to list all), and clarifies the tool is for contract discovery only, not for validation or factual 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?

Discloses that it returns static markdown from package and does not fetch live updates. No annotations provided, so description carries burden. Additional detail on error or permissions would improve, but sufficient for a simple read 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?

Three concise sentences: purpose, usage context, behavioral note. No wasted words; front-loaded with key info.

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?

Simple tool with one parameter and no output schema. Description fully covers purpose, use case, parameter format, and behavior, making it complete for an 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%. Description adds context: signal_id comes from list_signals and should not include .md extension. This aids correct usage beyond 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?

Clearly states verb (return), resource (strategic-risk signal markdown file), and scope (by ID). Distinguishes from sibling list_signals which returns multiple signals.

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?

Explicitly specifies when to use ('after list_signals') and what for ('full text of a specific archived signal'). Also instructs to pass signal_id without .md extension, avoiding common error.

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?

No annotations provided, so description carries full burden. It discloses being local-text only, deterministic, and lists specific excluded behaviors (source discovery, reliability scoring, factual truth). This fully informs the agent of boundaries.

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 front-loaded sentences: purpose, usage, exclusions, output. Every sentence adds unique value with no redundancy or fluff.

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 complex parameter, no annotations, and no output schema, the description fully covers inputs, outputs, and behavioral constraints. It clearly differentiates from 18+ siblings, making it complete for agent decision-making.

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 already describes the single parameter with 100% coverage, but description adds meaningful context: references a specific schema file, mentions optional verbatim quotes, and describes the return fields (grounding status, coverage, best passage, etc.), compensating for missing output 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 uses a specific verb ('check') and resource ('corpus of source texts supporting claims'), clearly stating the tool's function. It distinguishes from siblings like 'verify_claims' and 'audit_claims' by specifying it checks lexical support, not factual truth.

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?

Explicitly states when to use: when you have claims and full source texts needing a deterministic verdict before human review. Also explicitly states when not: no outbound requests, source discovery, reliability scoring, or factual verification, implying alternative tools for those cases.

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 explicitly discloses that the tool is pre-compliance evidence triage only, with no live retrieval, does not resolve vessel ownership or verify identity, no legal or sanctions advice, and requires human review. With no annotations provided, the description carries the full burden, and it does so clearly. It adds context about decision-readiness scoring and evidence gaps that are not present in the schema. It could be more explicit about whether it mutates state, but the read-only nature is strongly implied by 'triage' and the return semantics.

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 dense but well-structured: one sentence for the scope and risk facets, one for the input format/returns, and one for limitations and human review. No filler words. The key limitation (no live retrieval, human review required) is front-loaded before the returns are fully described, which is a good ordering for risk-sensitive tools.

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 has a single parameter with extensive schema documentation and an explicit pointer to the full schema via get_schema('gulf_maritime_exposure_request'). The description covers all key behavioral context, inputs, returns, and caveats. The output schema is absent, but the description covers the key outputs (triage recommendation, exposure signal, decision-readiness score, source comparison). For a complex, sensitive tool, no critical information for correct invocation 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?

The schema description coverage is 100% for the single top-level parameter (exposure_request), with a detailed inline description and a reference to the full schema via get_schema. The tool description adds value by explaining the purpose of passer input (vessel/voyage, route, cargo, counterparties, dated_sources, risk_question, decision_stage) and confirming the matching schema. It doesn't repeat field-by-field semantics but points to the authoritative schema contract, which is appropriate at this parameter's level.

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 states the tool triages maritime sanctions and chokepoint-disruption exposure for vessels/voyages through specific regions (Hormuz, Persian/Arabian Gulf, Gulf of Oman, Bab-el-Mandeb, Red Sea). It names specific risk facets (Iran-oil, Russia price-cap, dark-fleet, STS transfer, flag-hopping, P&I gap, AIS manipulation) and explicitly notes the input schema reference. This distinguishes it from broader sibling tools like middle_corridor_deal_risk or cis_secondary_sanctions_exposure, which focus on other geographies/risks.

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 provides clear guidance on when the tool is appropriate — for pre-compliance evidence triage of vessel/voyage risk in specific Gulf/Red Sea regions. It explicitly states the tool does NOT do live retrieval, resolve ownership, verify identity, or provide legal advice, and calls for human review. However, it does not explicitly name alternative sibling tools to use when those excluded functions are needed, so it falls slightly short of an explicit 'instead use X' pattern.

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?

There are no annotations, so the description carries the full behavioral burden. It does mention 'Evidence triage only', but it omits important constraints like how it handles missing sources or whether it flags incomplete requests. It doesn't disclose if it outputs certain errors, how it handles edge cases, or notable limitations beyond not being legal advice. Also, it says 'no live retrieval', but that's a constraint; overall behavioral transparency is thin.

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 rich and informative, covering purpose, inputs, outputs, and limitations in a clear, front-loaded manner. It's a long sentence but not wasteful; each part adds value. However, it could be slightly tightened, like removing 'distribution, import...' list if it's already in the schema, but it's not redundant.

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 the schema fully describes the request structure, and a tool helps, the description is fairly complete for inputs and outputs. It clarifies the output items and limitations, but it doesn't explain how the gate decision is derived, or what 'watch-next' indicators mean, or what happens with incomplete sources. There's also no info on output format beyond a label. It's adequate but leaves some 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?

The description mentions the main parameter 'readiness_request' and says it must match a schema, but since schema coverage is 100% and there's one parameter, the description adds minimal semantic meaning. It repeats that it's a structured request without adding details like the significance of 'decision_stage' or how it influences the output. It's adequate but not enriching.

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 has a clear topic and specific action, saying it grades a Kazakhstan market-entry file against a staged source-requirement taxonomy and returns a gate decision. However, while it lists many entry modes, it doesn't directly mention that this tool is the one to use for 'readiness' versus other assess tools. It's still quite specific and useful, just not perfectly distinguishing it from siblings like validate_brief.

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 states the input requires a structured readiness_request and explains what it returns, but it doesn't explicitly say when to prefer this tool over alternatives, nor does it mention any exclusions like 'use validate_evidence for evidence packets'. The context of 'before a launch, budget, or partner commitment' implies usage windows, but that's not explicit guidance on tool selection.

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?

No annotations are provided, so the description carries full burden. It states the tool returns metadata only, not full lens markdown or analysis results, and implies it is a read-only operation. No contradictions.

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 sentences, no redundancy, and the key function is front-loaded. Every sentence adds value.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description clarifies the return type (metadata only, not full content). It adequately covers purpose, usage, and limitations for a simple listing tool. Slightly more detail on metadata fields could improve completeness.

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% for the single parameter. The description adds 'Optionally filter by lens_type="regional" or "sector"', which mirrors the schema description without adding new information. 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?

The description clearly states the tool lists packaged regional and sector lens IDs, with the verb 'list' and resource 'lens IDs'. It distinguishes itself from the sibling tool get_lens by saying 'Use before get_lens'.

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 explicitly says 'Use before get_lens when an agent needs to discover which geography or sector reference packs can be loaded' and mentions optional filtering by lens_type. This provides clear when-to-use and when-not-to-use guidance.

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?

With no annotations provided, the description fully discloses behavioral traits: returns a snapshot, read-only, offline, and does not fetch live news. This is comprehensive for a tool with no 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 concise (three sentences), front-loaded with the core purpose, and every sentence adds unique value. No wasted 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?

Given no parameters, no output schema, and low complexity, the description covers purpose, usage, and behavioral traits completely. No missing information for an agent to use 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 tool has zero parameters, so a baseline score of 4 is appropriate. The description does not need to add parameter meaning as none exist.

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 the tool lists packaged strategic-risk signal records from a specific source, clearly identifying the verb and resource. It distinguishes from sibling tools like get_signal by indicating its role as a discovery tool for signal IDs.

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 provides explicit use cases: discovering signal IDs before calling get_signal or showing a static archive index. It implies not to use for live updates by stating it is read-only and offline, though it doesn't name specific alternatives for live fetching.

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?

Discloses it returns category IDs and per-pack counts, is discovery-only, and does not discover sources or verify truth. Lacks explicit statement of idempotence or safety, but adequate given no 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?

Four crisp sentences, front-loaded with purpose, then usage, output, and limitations. No wasted 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?

Fully covers purpose, usage, output, and boundaries for a simple parameterless tool with no output schema.

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?

No parameters with 100% schema coverage, but description adds value by explaining output (category IDs and per-pack counts) and usage context beyond 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 clearly states it lists source requirement category slugs, specifies the action ('List'), and distinguishes from sibling tools like source_plan and source_coverage.

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?

Explicitly says 'Use this first when you do not know which category to pass to source_plan or source_coverage' and notes limitations, providing clear when-to-use and when-not-to-use guidance.

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?

With no annotations provided, the description carries the full burden and exceeds it. It discloses exactly what the tool returns (triage recommendation, risk signal, decision-readiness score, supplied vs. minimum-required source categories, evidence gaps, high-risk-jurisdiction flag), and — critically — what it does NOT do (no live retrieval, no factual-truth verification, no legal/sanctions advice). It even routes the agent to get_schema for the full contract rather than hiding the nesting.

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?

Five dense, purposeful sentences, each earning its place: trigger points, input contract reference, output enumeration, and firm scope limitations. The disclaimers about no legal advice and human review are operationally necessary for a sanctions-adjacent tool and not padding. Loses one point for density — the single-sentence cascade of disclaimers could be lightly structured — but there is no appreciable waste.

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 high-complexity tool (nested request object, sanctions-adjacent domain, 1 param with 100% schema coverage, no output schema, no annotations), the description compensates thoroughly: it enumerates all six output components since no output schema exists, explains the input shape, and points to the full contract location. Loses a point because, without an output schema, the return-value prose list is the only contract and its structure/format remains unspecified — a minor gap given how much the description gets right.

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 baseline is 3. The description adds value above baseline by enumerating the key fields inside deal_risk_request (route, cargo, counterparties, dated_sources, risk_question, decision_stage) and pointing to 'middle-corridor-deal-risk-request.schema.json' plus the get_schema call for the full nested contract. The schema's own description similarly guides the agent to get_schema('middle_corridor_deal_risk_request'). The only reason not to give a 5 is that the description's list is illustrative rather than exhaustive of the nested contract, so the agent must still fetch the schema for field-level semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb + resource + scope: 'Screen a Kazakhstan / Middle Corridor (Trans-Caspian) trade deal for sanctions-adjacent and corridor risk.' It names exact trigger points (before signature, shipment, insurer handoff, committee review) and the corridor focus clearly distinguishes it from siblings like gulf_maritime_exposure and cis_secondary_sanctions_exposure without needing to compare 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 'when' is explicit and well-covered: 'before signature, shipment, insurer handoff, or committee review,' and the 'when-not' is also clear with 'Pre-compliance evidence triage only: no live retrieval, no factual-truth verification, no legal or sanctions advice; human review is required.' It misses a point only by not naming alternative sibling tools explicitly (e.g., when to prefer cis_secondary_sanctions_exposure instead), though the corridor-specific scope makes this largely self-evident.

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?

With no annotations provided, the description carries the full burden and handles it well. It explicitly discloses non-behaviors: 'does not authenticate, authorize, enforce, persist state, or perform the action.' This is meaningful, non-obvious context that prevents an agent from assuming 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?

Three dense sentences with no filler: the main routing behavior is front-loaded, the resubmission workflow follows, and the readiness boundary closes. Every sentence earns 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?

The description names the four possible routes, covers input families, and clarifies non-effects, which is strong for a tool with no output schema and no annotations. It does not explain the exact decision criteria that map policy checks and evidence to a specific route, but it points to get_schema for the full nested contract.

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 baseline is 3. The description adds value beyond the schema by identifying the semantically important inputs—'caller-supplied claim evidence, risk tier, policy checks, and an optional external approval reference'—and by explaining the resubmission semantics around run_id.

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 opens with a specific verb ('Route') and names both the object ('a caller-controlled action') and the four possible outcomes: continue, request_evidence, require_approval, or stop. It also distinguishes itself as a readiness-only decision router, separating it from sibling validation/analysis tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear contextual guidance: it is a readiness check that does not enforce or persist, and it explicitly instructs callers to 'Resubmit the same run_id after adding evidence or approval.' It does not name alternative tools explicitly, so some inference about when to choose this over siblings remains.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool uses a 'heuristic rubric' and returns a 'heuristic score and breakdown', and clarifies it is not definitive. However, it lacks details on side effects, authorization needs, or rate limits. The behavioral insight is partial but adequate for a non-destructive evaluation 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?

The description is a single, well-structured paragraph. It front-loads the core purpose, follows with usage guidance, provides technical input instructions, clarifies limitations, and mentions output. Every sentence earns its place with no redundancy or fluff.

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 explain the output format. It mentions 'Returns a heuristic score and breakdown' but does not detail the breakdown structure or where the rubric originates. Given the tool's role in evals/demos and many siblings, the description is adequate but lacks output specifics that would help an agent use the result effectively.

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 schema already documents both parameters (before_text, after_text) as plain strings. The description restates this ('Pass before_text and after_text as plain strings') and adds minor context ('Revised analysis text...' and 'Original analysis text...'). This adds little beyond the schema, achieving the baseline of 3.

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 states it 'Score a before/after pair of agenda-analysis text' and specifies the evaluation criteria (structure, evidence labeling, uncertainty handling, decision-readiness). The name and description align well. However, it does not explicitly differentiate from sibling tools like 'analyze' or 'validate', though the pair-input nature is distinctive.

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 says 'Use in evals or demos to compare whether an Agenda Intelligence rewrite improved...', providing clear context. It also explicitly states what it is not: 'not a factuality, legal, compliance, or investment judgment.' This helps an agent know when not to use it. It does not name specific alternatives among siblings, but the guidance is sufficient.

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?

No annotations provided, so description carries full burden. It clearly states the tool returns matched and missing source types, and explicitly lists limitations (does not discover new sources, verify truth, or change validate_evidence results).

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 concise sentences with no wasted words. Front-loaded with purpose, then usage, then limitations. Perfect structure.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately covers return values (matched and missing source types). Inputs are well described. The tool is simple and the description is complete.

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 baseline is 3. However, description adds meaning by explaining the optional behavior of category (overrides evidence_json.source_category) and the purpose of evidence_json. This extra context justifies a 4.

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 uses the specific verb 'diagnose' and resource 'source coverage', clearly stating the tool's purpose. It distinguishes from siblings by explicitly listing what it does not do (discover new sources, verify truth, change validate_evidence results).

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?

Explicitly states when to use: 'Use after collecting evidence to find source gaps before relying on a memo.' Also clarifies what it does not do, guiding agent away from misuse.

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?

With no annotations, the description carries the burden. It clearly states the tool returns a checklist of source types and does not perform web searches, fetch documents, or validate packs. This adequately discloses behavioral traits for a read-only, deterministic tool. No side effects are implied, and the description does not contradict any annotations (since none are provided).

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 three sentences, no wasted words. The first sentence states the primary purpose, the second provides use context, and the third clarifies boundaries and what it returns. It is front-loaded with the most important 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?

Given the tool has only one parameter (with enum), no output schema, and no annotations, the description provides sufficient context. It explains the return value ('checklist of must_check and optional source types') and what the tool does not do. The reference to list_source_categories in the input schema adds helpful cross-tool context. Overall, an agent can correctly select and invoke this tool based on the description.

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 baseline is 3. The description adds minimal meaning beyond the schema: it says 'Pass the source category slug as category' and gives examples, but the schema already has an enum and description with examples. The description does not provide new information about the parameter's format or constraints.

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 states the tool returns required source categories for a strategic-risk evidence pack. It further explains the use case (before collection or review) and provides domain examples (sanctions, elections, energy). The statement of what it does not do (search, fetch, validate) distinguishes it from other tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use the tool ('before collection or review') and what it does not do, implicitly guiding when not to use it. However, it does not explicitly mention alternative tools by name (except list_source_categories in the schema). The context from the description is sufficient for an agent to decide 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?

With no annotations, description carries full burden. It clearly states returns only validation status and schema errors, and does not judge truth, retrieve sources, or improve the brief. This discloses boundaries and behavioral traits well.

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 sentences, front-loaded with purpose, then constraints. No wasted words. Highly efficient.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple validation tool with one parameter and no output schema, description covers use cases, limitations, and return type. Missing details on output structure or error handling, but adequate given simplicity.

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% (1 param fully described). Description adds minimal value: 'Pass the parsed brief object' and 'against the bundled schema'—essentially restating schema metadata. 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?

Description clearly states it validates an agenda brief against a schema, with specific use cases (before scoring, audit, publication). It explicitly distinguishes itself from other tools by stating what it does not do (judge truth, retrieve sources, improve the brief).

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?

Description provides explicit when-to-use guidance ('before scoring, evidence audit, or publication steps'). It implicitly indicates when not to use it by listing what it does not do, but does not name specific alternative sibling 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?

With no annotations, the description carries full burden. It discloses that validation is against a schema and does not verify truth, but does not explicitly state it is read-only or discuss permissions, rate limits, or side effects. Adequate but not comprehensive.

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 sentences with efficient content: first states core purpose, second adds usage guidance and limitations. Front-loaded, no redundancy.

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 single parameter and no output schema, description mentions 'Returns schema validity and errors' but lacks detail on return format. Does not differentiate from similar sibling 'validate_brief'. Adequate but leaves some 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 coverage is 100%, so baseline is 3. Description adds minimal extra meaning beyond 'Pass the parsed evidence pack as evidence_json', largely restating the schema description. No additional constraints or format details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool validates an evidence pack against a schema, with a specific verb and resource. It distinguishes from siblings like 'audit_claims' by clarifying it does not verify truth or sufficiency, only structural usability.

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?

Explicitly says 'Use when you need to confirm... structurally usable' and delineates what it does not do (truth, currency, sufficiency). Provides clear context but could name alternatives for truth verification.

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?

With no annotations provided, the description fully discloses behavior: it returns validity and schema errors, and explicitly states limitations (does not score truthfulness, retrieve sources, or rewrite). This gives the agent a clear understanding of the tool's boundaries.

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 three sentences, each serving a distinct purpose: purpose, usage, and limitations. It is front-loaded with the main action and contains no superfluous 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?

Despite lacking an output schema, the description explains the return value (validity and schema errors). It also clarifies exclusions. With one well-documented parameter and clear behavioral boundaries, the description is complete for this validation 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 coverage is 100%, so the schema already documents the parameter. The description adds 'Parsed Agenda memo JSON object' which is consistent but does not significantly enhance understanding beyond the schema's description.

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 explicitly states 'Validate an Agenda memo against agenda-memo.schema.json', using a specific verb and resource. It further distinguishes itself by stating what it does not do (score truthfulness, retrieve sources, rewrite). This clearly separates it from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage context: 'Use after a host model or external process drafts a memo and before treating it as an Agenda Intelligence artifact.' While it does not name specific alternatives, the constraints on what it does not do implicitly guide when not to use 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?

There are no annotations provided, so the description carries the full burden of behavioral disclosure. It explains what the tool does not do (no source discovery, no live retrieval, no absolute truth claim), defines 'verified' operationally, and mandates human review. These non-obvious caveats are exactly the kind of context agents need.

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, front-loaded with what the tool does, and every sentence adds value: verdict vocabulary, evaluation dimensions, limitations, and operational caveats. No repetition or 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?

Given a single nested request parameter and no output schema, the description covers the output vocabulary, the input concepts, the judgment criteria, and the key caveats. The one clear gap is that the exact nested contract is deferred to get_schema rather than described in the tool text, but that is a reasonable trade-off for such a nested structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema describes the top-level wrapper and points to get_schema for details, so the baseline is 3. The description adds meaningful conceptual semantics by mapping the evaluation dimensions (freshness, source class, source groups, conflicts, jurisdiction, subject identifiers, as-of date) to what the claims and evidence parameters 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 clearly identifies the operation ('Issue a bounded factual Claim Verdict'), the resource ('caller-supplied evidence records'), and the specific output verdicts. It distinguishes itself from sibling tools by explicitly fencing off source discovery and live retrieval, making the niche unmistakable.

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 strong contextual signals for usage: use it when evidence is already supplied and a bounded evidentiary verdict is needed. It also provides explicit when-not clauses ('No source discovery or live retrieval', 'not absolute truth', 'Human review remains required'). It does not name specific sibling alternatives, so it stops short of full routing guidance.

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?

With no annotations provided, the description fully discloses behavior: input structures (evidence pack or audit doc), output (present, absent, missing_source_text), and limitations (no outbound requests, no factual truth verification). No contradictions.

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, well-structured paragraph. Each sentence adds value: purpose, usage context, input format, output, and limitations. No wasted 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?

Given two parameters (one required), nested objects, and no output schema, the description is thorough. It explains input types, output types, and what the tool does not do, ensuring the AI agent can invoke it 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 100%, so baseline is 3. The description adds meaning beyond schema: explains that pack_json can be an evidence pack or audit doc, and that span checks carry claim_id. This adds useful 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 clearly states the tool's verb ('Check'), resource ('quoted fragments appear in caller-provided source text'), and scope. It distinguishes itself from siblings by explicitly listing what it does not do (e.g., no outbound requests, no source reputation).

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 explicitly states when to use the tool ('Use when you have local excerpts and need to catch citation drift or misquoted snippets') and lists exclusions ('Local-text only: it does not make outbound requests...'). It does not name specific alternative tools, but the context is clear.

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