PHION Evidence

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

With no annotations, the description carries the full burden, and it does disclose two useful behavioral traits: the assessment is bounded by supplied evidence, and the call costs 0.005 USDC (a paid operation). It does not disclose what happens when evidence is insufficient, what the signed receipt guarantees, or any permission/latency characteristics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence with no filler, and the core purpose plus the output contents and price are front-loaded. It is appropriately sized for the amount of information offered, though it packs the price tag on with a semicolon in a slightly awkward way.

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?

An output schema exists, so return values need not be described, but for a tool with three parameters, nested objects, and 0% schema coverage the definition is materially incomplete. It gives no indication of what must go into 'subject' or what qualifies as valid 'evidence', which an agent needs in order to call 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 0% for three parameters including two nested objects, so the description must compensate but does not. It never mentions 'subject', 'signals', or 'evidence' directly, leaving the agent to infer the shape of the required subject object and the maxItems=32 evidence array from the raw schema alone.

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

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

The description names a specific operation (evidence-bounded reputation assessment) on a specific resource (an agent subject), and lists what the result contains (confidence, coverage, provenance limitations, signed receipt). It is clearly distinguishable from generic siblings like verify or attest, though it never names a sibling to differentiate against.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no alternative tool is named. The phrase 'evidence-bounded' weakly implies evidence must be supplied, but nothing tells the agent which of the many sibling preflight/verify/screening tools to prefer in a given situation.

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 it does disclose two genuine behavioral facts: this is a paid operation and the price/chain are 0.001 USDC on Base. It omits whether it is a write/side-effecting operation, whether the attestation is stored or returned, and what signing or auth is needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single front-loaded fragment with no wasted words, which is efficient. However, the brevity crosses into under-specification rather than conciseness, so the structure succeeds only as a one-line label.

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

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

For a paid, signed operation with three undocumented parameters, no annotations, and no output schema, the description is materially incomplete. An agent knows the price but not what it must pass, what it gets back, or how the result is consumed.

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

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

Schema description coverage is 0% for all three parameters (content, sources, ttl_seconds), and the description explains none of them. The required 'content' parameter and the ttl_seconds semantics (expiry of the attestation?) are left entirely undocumented.

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

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

The description names the resource (signed JSON attestation) and the mechanism (x402 paid), which tells an agent what it produces, but it reads as a jargon fragment rather than a clear verb+resource statement. It does not distinguish this from siblings like verify or fetch_evidence, which plausibly operate on the same attestation concept.

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

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

There is no statement of when to use this tool versus verify, fetch_evidence, or preflight/payment_preflight. The cost mention implies a paid path exists, but the description never says to call payment_preflight first or what condition selects attestation over 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add meaningful context by disclosing a free input preflight, provider attribution, signed evidence, and a fixed price of 0.005 USDC, which helps an agent understand billing and validation behavior. However, it omits broader operational details such as authentication requirements, data source behavior, failure modes, and return structure, so it is only partially 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 a single dense sentence with no filler: it names the operation, key features, and cost. The information is packed tightly, though it slightly sacrifices clarity by relying on jargon like 'provider attribution' without elaboration.

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 28 parameters, nested objects, no output schema, and no annotations, the description is too thin to support correct invocation. It provides no invocation guidance, no examples, no explanation of what the signed evidence contains, and no comparison to similar enrichment tools. An agent needing to choose parameters or interpret the result would be under-informed.

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

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

Schema description coverage is only 7%, and the tool description itself adds no parameter-level meaning beyond 'company enrichment.' The schema's own description does clarify that identifier can be pdl_id, website/domain, profile, ticker, name, company, or identifier and that nested inputs are accepted, but the remaining ~26 parameters are opaque. The description does not compensate for the low coverage.

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

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

The description identifies a clear domain ('Company enrichment') and distinguishes it from sibling evidence tools such as contact_enrichment_evidence, person_enrichment_evidence, and entity_enrichment_evidence by naming the company scope. It does not state what the returned 'signed evidence' contains, which leaves some ambiguity about the tool's exact output, but the primary purpose is recognizable.

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

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

The description gives no explicit guidance on when to use this tool versus sibling alternatives like contact_enrichment_evidence or entity_enrichment_evidence. There are no exclusion criteria, no mention of alternatives, and no condition-based routing. The only implicit signal is that it is for company-related enrichment.

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 does disclose useful behavioral traits: free input preflight, identity limitations, signed receipt, and the 0.007 USDC cost. But it omits whether the operation is read-only, what the signed receipt contains, and possible failure modes.

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 tight sentence, front-loading the core purpose and packing cost, preflight, and identity constraints without filler. It could be slightly better structured, but it earns its brevity.

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 28 parameters, no output schema, and no annotations, one line is insufficient. An agent cannot determine which identifier to pass, what the signed receipt looks like, or how identity limitations affect the enrichment result.

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

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

Schema description coverage is only 7%, yet the description names no parameters and gives no guidance on the 28 inputs. It only implies the input is a business contact, which does little to clarify how to populate fields like lid, pdl_id, query, or subject.

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 'Business-contact enrichment' – a specific verb and resource – and the 'business-contact' qualifier helps distinguish it from company or person enrichment siblings. However, it does not name any sibling or explicitly state what the evidence output looks like.

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

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

No usage context or alternatives are provided. The description mentions preflight and identity limitations but never says when to use this tool over company_enrichment_evidence, person_enrichment_evidence, or entity_enrichment_evidence.

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. It usefully discloses a hard prerequisite (the binding requirement) and the cost (0.002 USDC), and the phrase 'only when' implies refusal otherwise. But it says nothing about failure behavior, what the certificate contains, or how the maximum_age_seconds policy is enforced.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence that front-loads the core verb and constraints, with cost at the end. No wasted words, though the compression leaves semantic gaps that a slightly longer definition could close.

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 nested required schemas, zero parameter descriptions, no annotations, and no output schema, the single sentence is not sufficient. It omits the policy semantics, the certificate's contents, and the failure/return behavior an agent needs to call this correctly.

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

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

Schema description coverage is 0% and both parameters are nested required objects. The description maps three data subfields (observed_at, source_uri, content_sha256) to their intent and adds the '64-hex' format detail, which is genuinely beyond the schema. But the entire policy object, including the central maximum_age_seconds threshold, is left unexplained.

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

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

The description names a specific verb (Certify) and resource (freshness) with the exact binding conditions required to issue the certification. It is clearly distinguishable from generic siblings like attest or verify by the freshness/URI/hash semantics, though it does not explicitly name a sibling it is not. Purpose is clear but sibling differentiation is left implicit.

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 a precondition (only when timestamp is bound to source URI and a 64-hex content hash), which is a form of when-to-use guidance. However, it does not explain when to prefer this over nearby tools like attest, verify, or service_sla_attestation, nor any exclusions. Usage is implied rather than 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?

Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely useful behavior: it does not echo content, and it requires matching 64-hex expected/observed hashes. But it omits what counts as 'successful', what a mismatch returns, and the pricing/billing mechanics beyond the flat fee.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence followed by the price. Front-loaded with the core action and no filler. The dense clause stacking slightly hurts readability but nothing is wasted.

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

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

A paid, mutation-adjacent evidence tool with a nested 6-field object, 0% schema coverage, and no output schema. The description should explain the input object shape, the matching rule, mismatch behavior, and the return value. It covers only the hash-matching idea and the price, leaving most of what an agent needs to call it correctly unspecified.

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

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

Schema description coverage is 0% and the single required 'delivery' parameter is a nested object with six required sub-fields, none documented. The description gestures at the fields (transaction, request, content hashes) but supplies no format, no max length enforcement, and no explanation of the hash-matching semantics the caller must satisfy.

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

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

States a verb ('Bind') and the resources involved (delivery, transaction, request, content hashes), which is more specific than a tautology. However 'Bind successful delivery' is jargon that doesn't clearly explain to an agent what the tool actually produces or how it differs from near siblings like transaction_assurance, agent_task_handoff_receipt, or attest. The purpose is inferred rather than stated plainly.

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

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

No when-to-use guidance and no mention of alternatives, despite dozens of closely-named evidence/attestation siblings. The '0.003 USDC' price hints at a paid operation but the description never says when this paid call is warranted versus free siblings like schema_normalize_free or try_service.

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 behavioral burden. It usefully discloses accepted input formats, the source-backed nature of the output, the lack of OCR support, and the price. However, it does not describe failure modes, rate limits, processing guarantees, or whether any action is taken beyond normalization.

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 very short and front-loaded, with the core transformation stated first, followed by the OCR limitation and cost. Every clause adds useful information. It is slightly too terse given the unexplained expected_fields parameter, but the structure itself is 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?

The tool has two parameters, no annotations, no output schema, and only a one-sentence description. The description fails to explain expected_fields, input URL semantics, output shape, or behavioral constraints beyond OCR. An agent cannot confidently invoke this tool correctly from the provided information.

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

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

Schema description coverage is 0%, so the description must clarify the parameters. It indirectly describes source_urls as public text/HTML/JSON/XML sources, but it does not explain expected_fields at all, and gives no hint about their format, purpose, or relationship to the output. This leaves a required part of the contract unexplained.

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

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

The description clearly states the resource (public text, HTML, JSON, XML) and the result (source-backed JSON). It positions the tool as a normalizer/converter and adds a differentiating constraint ('no OCR'). It does not explicitly distinguish it from siblings such as source_backed_search or verified_web_extract, but the core purpose is clear.

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 phrase 'Public text, HTML, JSON or XML' and 'no OCR' imply the tool is for public non-image document conversion, but there is no explicit statement of when to use this tool versus a sibling, and no mention of when not to use it. No alternatives or routing conditions are provided.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the price (0.003 USDC), the freshness requirement, the accepted proof methods, and the control-vs-legal-ownership distinction — useful behavioral context. It omits whether the call is read-only or mutating, what happens on failure, and what the caller receives.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence with no filler, and the cost and freshness constraint are placed up front. The phrasing 'Require a fresh ... challenge' is elliptical but compact.

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

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

With no annotations, no output schema, and an undocumented nested evidence object, the description leaves too much for the agent to infer about inputs and outcomes. Given the tool's structural complexity, substantially more detail was warranted.

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

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

Schema description coverage is 0% for two parameters, one of which is a nested object with five required subfields. The description maps loosely onto 'domain' and, via DNS-01/HTTP-01, onto the evidence method, but leaves challenge_sha256, verified_at, and independently_verified unexplained, so it does not compensate for the coverage gap.

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

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

The description identifies a domain-ownership verification via DNS-01/HTTP-01 challenges and distinguishes control from legal ownership, which is a meaningful resource-specific idea. However, the leading verb 'Require' is an odd framing for a tool call and never states plainly what the tool does (verify, attest, issue evidence, or gate an action). An agent knows roughly the subject matter but not the operation.

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

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

There is no when-to-use guidance, no mention of alternatives among the many evidence sibling tools (rwa_sanctions_screening_evidence, agent_reputation_evidence, mcp_server_identity_evidence, etc.), and no preconditions stated beyond a fresh challenge. The 'freshness' hint is the only contextual cue.

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 bears the full burden of behavioral transparency. It adds some useful traits—source-bounded results, explicit missing facts, and a 0.008 USDC cost—but it does not disclose read/write behavior, whether it fetches the source URLs, persistence, auth, response shape, or failure 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 definition is compact and front-loaded: scope appears first, missing-facts behavior second, and price last. There is no filler and each clause earns its place. It is under-specified overall, but the structural efficiency is strong.

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

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

Given three parameters, a nested subject object, no output schema, and a crowded sibling list, the one-sentence description is insufficient. The agent cannot learn how evidence is returned, how subject relates to expected_fields, or when to select this tool over similar ones.

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 has 0% description coverage for three parameters, so the description must compensate. It indirectly maps 'source-bounded' to source_urls, 'entity' to subject, and 'field coverage ... missing facts' to expected_fields, adding some meaning beyond the bare schema names. However, it does not explain formats, requiredness, constraints, or how subject and expected_fields interact.

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

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

The description conveys a specific output concept—'Source-bounded entity field coverage with explicit missing facts'—and mentions the price, but it uses a noun phrase rather than a clear verb+resource statement. It does not distinguish this from siblings like multi_source_fact_bundle or source_backed_search.

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

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

There is no when-to-use guidance, no exclusions, and no reference to alternatives. The description only characterizes the result and cost, leaving the agent to infer when this evidence tool should be chosen over the many related tools in the sibling list.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond these: 'Deterministic, evidence-bounded and signed,' plus a 0.004 USDC cost. This enriches the agent's model of the operation without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loads the action. The semicolon leading into '0.004 USDC' is slightly abrupt, and 'separating registration from ownership' is a bit cryptic, but no sentence is wasted and the core behavior is stated first.

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 output schema present and annotations covering safety and idempotency, the description does not need to explain return values. However, the input schema is open with minProperties=1, and the description does not clarify what properties an agent should supply (e.g., how to specify identity or evidence). For a specialized ERC-8004 tool, this leaves a meaningful gap.

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

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

The tool has 0 declared parameters, so the baseline is 4. The description does not document parameter details, but there are none in the schema to explain. The open additionalProperties=true schema means the description's references to 'identity' and 'evidence' are the only semantic clues, which is acceptable for a zero-param tool.

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: 'Bind an ERC-8004 registry identity to evidence.' This clearly identifies the tool's core function and adds a distinguishing constraint ('separating registration from ownership'). It does not explicitly contrast with sibling tools like erc8004_reputation_intelligence or onchain_evidence, so it falls short of a 5.

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

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

The description gives no guidance on when to use this tool versus alternatives. It mentions the cost and behavioral properties but provides no selection criteria, prerequisites, or exclusions, leaving an agent to infer suitability from the name alone.

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

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

The description adds meaningful behavioral context: it performs SSRF checks on redirects, DNS, and connected addresses, plus hashing and injection screening. Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The cost mention is helpful, but there's no detail on failure modes, rate limits, or output format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single efficient sentence that packs in key features and cost. Front-loaded with the core action. 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 output schema and a single parameter, the description covers the core action and security checks. However, it omits return value details, error handling, and cost implications beyond the flat fee. Adequate but with clear gaps.

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

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

Schema description coverage is 0% and there is one required parameter 'url'. The description doesn't explain the parameter's expected format beyond the schema's 'uri' type, but 'bounded' and 'public' imply restrictions on what URLs are allowed. Baseline 3 when schema has minimal elaboration.

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

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

States a specific verb+resource: 'fetch bounded public evidence' with the added detail of SSRF checks and hashing. It's clear what the tool does, though it doesn't explicitly contrast with siblings like 'try_service' or 'webhook_verifier'.

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

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

No indication of when to use this tool versus alternatives. The '0.004 USDC' cost hints at a paid service, but there's no guidance on when it's appropriate or what happens if the fetch fails.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context such as the fee (0.005 USDC), the digest-based delta mechanism, and the exact record/template/evidence contents, but it does not explain response shape or pagination 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 a single compact sentence that front-loads the core purpose and packs content, delta semantics, evidence, templates, and pricing without unnecessary filler. It is efficient, though the final clause is dense.

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 read-only, idempotent feed with two parameters, the description is adequate but not complete. It lacks explicit return-format details and does not fully connect the optional SHA-256 parameter to delta mode, which would matter given there is 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 0%, but the description partially compensates by naming 'snapshot' and 'digest-based delta,' which maps to the mode enum. It does not explicitly clarify when since_snapshot_sha256 should be supplied, though the pattern and parameter name make the intent inferable.

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 resource: a canonical catalog snapshot or digest-based delta, and enumerates its contents (HTTP/MCP records, PHION Execute templates, signed evidence). This goes beyond the name and distinguishes the tool from the many evidence/verification siblings, though it lacks an explicit verb.

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

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

The 'snapshot or digest-based delta' wording implies when the tool should be used, but it does not provide explicit when-to-use guidance, exclusions, or comparisons with sibling tools. Usage context is present mainly by inference from the content description.

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

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

With no annotations, the description carries the full burden. It only adds a cost figure (0.002 USDC) but does not disclose the return value, how the evaluation works, what happens when the maximum age is exceeded, or any 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?

The description is very brief and front-loads the action and cost, but it is a fragment rather than a structured explanation. The brevity leaves out necessary details, making it under-specified rather than efficiently concise.

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

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

Given no annotations and no output schema, the description is far from complete. An agent would not know what result to expect, how to handle stale sources, or what the 0.002 USDC signifies beyond a cost.

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

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

Schema description coverage is 0%, so the description must explain the parameters. It implicitly maps 'explicit maximum age' to max_age_seconds but does not clarify source_urls beyond a vague 'live source observation', leaving the URL format and interpretation undocumented.

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

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

The description states a clear verb ('Evaluate') and resource ('live source observation against explicit maximum age'), indicating a freshness check. It is not a tautology and is distinct enough from related tools, though it doesn't explicitly compare to siblings.

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

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

There is no guidance on when to use this tool versus alternatives. The description only includes the task statement and a cost, with no mention of context, exclusions, or 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the snapshot is timestamped, provenance-bearing, and costs 0.005 USDC, which is useful context. But it does not disclose side effects, data-source behavior, failure modes, or what the returned snapshot structure is, leaving major behavioral gaps.

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 concise sentence that front-loads the core concept and ends with the cost. It contains no filler words. It loses one point because it prioritizes compactness over including a verb and parameter linkage, but structurally it is efficient.

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

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

With 3 parameters, 0% schema coverage, no annotations, and no output schema, the description needs to carry substantial weight. It does not explain how to call the tool, what the output looks like, or what the required parameters mean. The brief noun phrase and price are insufficient for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate by explaining the three parameters. Instead, it only loosely maps to the idea of market data and provenance and never mentions source_urls, subject, or expected_fields. The required source_urls parameter is completely unexplained, leaving an agent without enough information to fill it correctly.

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

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

The description says "Timestamped public market-data snapshot with provenance; 0.005 USDC." This names a specific resource and adds distinguishing attributes (timestamped, provenance, cost), which separates it from many siblings. However, it lacks a verb — it never states explicitly what the tool does with the snapshot — so it stops just short of a full purpose statement.

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

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

The description gives no guidance on when to use this tool versus alternatives. It implies a paid public-data retrieval context with the cost note, but it does not state when to prefer this over sibling tools like live_data_freshness or source_backed_search, nor any conditions or exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals the monetary cost (0.003 USDC), which is useful, but says nothing about whether the operation is read-only or mutating, what permissions are required, or what side effects binding may have.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It efficiently states the action, the components involved, and the cost, though it may be too terse for a tool with financial and evidence implications.

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?

An output schema exists, so return values do not need explanation. However, with no annotations and a complex, payment-bearing identity-binding operation, the description omits critical context such as when to invoke it, what it produces, and how it relates to sibling evidence tools.

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

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

Schema description coverage is 100%, so the schema already documents the required 'identity' parameter. The description adds a list of components (domain, endpoint, manifest, key, version) that likely map to fields within that identity, but does not clarify the parameter's structure or format beyond the schema.

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

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

The description uses a specific verb, 'Bind', and enumerates the identity components it operates on: MCP domain, endpoint, manifest, key, and version. It also names the cost, which helps identify this as a paid evidence-binding operation. However, it does not distinguish itself from adjacent siblings such as domain_ownership_evidence or mcp_manifest_firewall.

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

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

The description gives no guidance on when to use this tool versus alternatives, nor does it state preconditions, exclusions, or typical workflows. The only contextual clue is the price, which does not explain usage in relation to 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 the burden of disclosing effects, authentication, or data handling, but it only adds the price and a rough characterization of the result. It does not state whether this creates records, performs verification, or requires certain input preparation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is brief, front-loaded, and free of filler; the cost is stated compactly. However, the economy is achieved by omitting substantive guidance, so it is concise but not sufficiently informative.

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

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

The tool has three parameters, including a required source_urls array, no output schema, and no annotations, yet the description explains none of the invocation semantics or expected return shape. Critical information about how the multi-source agreement is constructed and what the agent receives is entirely absent.

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

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

Schema description coverage is 0%, and the description does not mention query, source_urls, or expected_fields at all. An agent must infer parameter meaning solely from property names and types, so the description completely fails to compensate for the missing schema documentation.

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

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

The description is a noun phrase describing what the bundle contains, not an action an agent can invoke. 'Independent source observations with agreement made explicit' essentially restates the tool's name without a verb like 'retrieve' or 'aggregate,' and it doesn't distinguish this tool from siblings such as source_backed_search or fetch_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?

There is no guidance about when to use this tool over sibling evidence tools, nor any prerequisite contexts or exclusions. The only additional detail is the price, which is an economic constraint, not a usage criterion.

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

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

Annotations already disclose readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the behavioral traits 'deterministic' and 'signed', which are useful, though 'deterministic' largely overlaps with the idempotency annotation. It does not describe authentication needs, rate limits, or failure behavior, but it does not contradict the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single compact sentence with no filler or redundancy beyond echoing the title. The phrase 'deterministic signed assessment over supplied input' is front-loaded and easy to scan. It is concise, though its brevity limits substance.

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 involving OAuth issuer binding and signed evidence, the description leaves too much unexplained: what 'issuer binding' means, what the assessment output looks like, and how the required parameters interact. Output schema and annotations cover return shape and safety, but the description itself is not complete enough for an agent to confidently know when or why to invoke this tool.

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

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

Schema description coverage is reported as 100%, so the parameters claims, expected_issuer, and expected_audience are already documented in the schema. The description itself adds no parameter-level explanation, which is acceptable under the high-coverage baseline, but it also does not enrich the meaning of those parameters.

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

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

The description states that this tool produces a 'deterministic signed assessment over supplied input', which hints at an assessment/evidence-generation operation. However, it never says what the assessment verifies about OAuth issuer binding or how it relates to the required claims, expected_issuer, and expected_audience parameters. It is more specific than a pure tautology but remains vague and does not distinguish it from sibling evidence tools.

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

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

There is no guidance on when to use this tool versus alternatives such as oauth_token_audience_guard, mcp_server_identity_evidence, or other evidence-generation tools. The description provides no prerequisites, exclusions, or typical use cases, leaving selection entirely to inference.

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

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

No annotations are provided, so the description bears the full burden of behavioral disclosure. It mentions immutable hashes and a cost of 0.004 USDC, which is useful, but it does not state side effects such as whether the tool performs network fetches, writes evidence, verifies hashes, or what happens on failure. This is minimal transparency for an on-chain evidence 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?

The description is compact and front-loaded, with no filler words. However, it is terse to the point of ambiguity, and the cost annotation is placed awkwardly after a semicolon rather than integrated into a clear behavioral explanation.

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

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

With two parameters, no output schema, and no annotations, this single cryptic sentence is completely inadequate for an agent to select and invoke the tool correctly. It omits the action performed, the meaning of subject, how source_urls are used, what the evidence output looks like, and when this tool should be preferred over any sibling evidence tool.

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

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

Schema description coverage is 0%, so the description must compensate for both source_urls and subject. The phrase 'Public explorer or RPC response evidence' hints that source_urls should point to public explorer or RPC endpoints, but it never mentions the subject parameter or explains its role. The description adds only weak contextual meaning beyond the schema's bare parameter list.

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

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

The description identifies the resource as 'Public explorer or RPC response evidence with immutable hashes', which gives some clue that this tool deals with on-chain evidence and hashes. However, it lacks an explicit verb or clear action statement, so an agent cannot tell whether this tool creates, verifies, or fetches evidence. It also does not clearly distinguish itself from the many sibling evidence tools beyond the 'public explorer or RPC' phrase.

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

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

There is no explicit guidance about when to use this tool versus siblings such as fetch_evidence, delivery_evidence, or domain_ownership_evidence. The phrase 'Public explorer or RPC response evidence' implies a use case, but no conditions, exclusions, or alternative recommendations are provided.

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

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

With no annotations, the description carries the behavioral transparency burden. It does add useful details: free input preflight, provider attribution, likelihood, limitations, signed receipt, and a price of 0.006 USDC. However, it does not disclose authentication needs, side effects, rate limits, or what the returned evidence/receipt structurally contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler words, and it front-loads the core purpose before listing notable features and cost. It is appropriately brief, though the semicolon-joined feature list reads a bit densely.

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 28 parameters, no output schema, and no annotations, so the description is severely insufficient. It does not explain how to construct a valid request, what fields are meaningful together, what the signed receipt looks like, or how preflight and validation behave. An agent would be guessing on most operational details.

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

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

Schema description coverage is only 7% across 28 parameters, and the tool description does not compensate. It mentions 'person' and 'free input' but does not explain any of the parameters, their roles, required combinations, or how the service interprets them. The description adds almost no semantic value over the sparse 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 identifies a specific action and resource: 'Person enrichment'. It also distinguishes itself from sibling enrichment tools like company_enrichment_evidence and contact_enrichment_evidence by naming 'person' as the subject. However, the phrase is somewhat jargon-heavy and doesn't fully explain what 'enrichment evidence' means in practice.

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

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

There is no guidance about when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or conditions that would route an agent to a different sibling tool. The only implicit hint is the word 'person', which is not enough for a tool with so many siblings.

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

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

Annotations already cover idempotency, read-only, open-world, and destructiveness, and the description adds real context beyond them: budget enforcement, persistent idempotency, acceptance-criteria evaluation, a signed completion envelope as output, and the absence of a gateway surcharge. It stops short of describing failure behavior or what a rejected acceptance check yields.

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 densely packed sentences with no filler; the core pipeline (gate, execute, evaluate, return) is front-loaded and the pricing note is a useful trailing clarification.

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 mutating, open-world, 7-parameter tool with no output schema and 0% parameter documentation, the description covers the return concept ('signed completion envelope') but omits dry_run semantics, failure modes, and rejection behavior. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must carry meaning, and it hints at max_budget_atomic ('enforce a budget'), idempotency_key ('persistent idempotency'), acceptance_criteria, and target_service. However, objective, input, and dry_run go entirely unaddressed, so it only partially compensates for the coverage gap.

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

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

States a specific verb ('execute') plus resource ('one selected PHION service') and frames the tool as a gateway with budget/idempotency/acceptance gating. It is distinguishable from most siblings, though it never names the closest alternatives such as try_service or preflight.

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

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

There is no explicit when-to-use or when-not guidance. The word 'universal' and the gateway framing imply broad applicability, but an agent cannot tell from the text when to pick phion_execute over try_service, preflight, or transaction_assurance.

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 does disclose meaningful behavioral detail: the specific invariants checked (hash chain, lowercase nonzero W3C trace/span IDs) and the cost (0.004 USDC). However, it says nothing about what a failure yields, whether the operation is read-only, or what the verdict/report looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One compact sentence with semicolon-separated clauses, front-loaded on the action and the validations performed. The price is appended at the end where it doesn't interrupt the primary meaning; nothing is wasted.

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

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

For a validation tool with no annotations and no output schema, the description covers the input-side contract well but is silent on the return value (pass/fail, error list, per-event verdicts) and on any failure behavior. An agent can invoke it correctly but cannot anticipate what it gets back.

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

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

With a single parameter at 0% schema description coverage, the schema documents only structure (required event_id, observed_at, trace_id, span_id), not meaning. The description compensates by spelling out what those fields must satisfy — identity validity, timestamp validity, W3C lowercase nonzero trace/span format — which is exactly the semantics the schema omits.

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

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

States a specific verb ('Validate') and enumerates the exact things validated: event identity, timestamps, hash chain, and W3C-compatible trace/span identifiers. It is clearly distinguishable from siblings like verify or attest in substance, though it never names a sibling to route against. The trailing price is unusual but doesn't obscure the purpose.

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

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

There is no statement of when to call this tool versus alternatives such as verify, attest, or transaction_assurance, and no prerequisites or preconditions are given. The agent must infer usage entirely from the name and description.

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

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

No annotations are provided, so the description carries the full disclosure burden, and it discloses almost nothing beyond 'free' — no auth requirements, no explanation of what makes a URL unsafe, no behavior on failure, and no rate limits. Calling something a safety check without saying what it inspects or returns leaves real ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One front-loaded sentence with no filler; the core action leads. It is efficient, though the terseness edges toward under-specification rather than tightness.

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

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

For a simple one-parameter tool with no output schema, the description still omits what a 'safety' verdict consists of and what the caller gets back, which is the main thing an agent needs to decide whether to gate a downstream action on the result.

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

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

Schema description coverage is 0% for the single required url parameter, and the description only says a URL is checked. It does not clarify expected form (absolute? scheme? relative paths rejected?), which matters because the schema only declares format: uri with no prose.

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

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

The description gives a concrete verb-plus-resource framing: it checks a URL for safety and reachability. That is enough for an agent to know what it does, but it never distinguishes itself from the sibling payment_preflight, which sounds nearly identical in kind.

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

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

There is no statement of when to call this versus payment_preflight, verify, or the other siblings, and no prerequisites (e.g., authenticate first, call before payment). The agent is left to infer the workflow position of a 'preflight' entirely from the name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the word 'deterministic' and 'signed', which hints at output behavior but does not explain what 'signed' means or what the assessment entails. No contradictions with annotations, but minimal added value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is only one sentence, but it is unhelpfully vague and lacks front-loaded, actionable information. It does not earn its place because it merely restates the tool's name and adds an opaque phrase.

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 an output schema, the description fails to explain the input, the meaning of the assessment, or the expected result. For a tool with a single required parameter and a clear purpose implied by its name, this is severely under-specified.

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 has one required parameter 'quote' but no description for it. The tool description does not elaborate on what constitutes a 'quote' or how it should be formatted. With zero schema descriptions and no tool-level explanation, an agent cannot correctly construct the input.

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 'deterministic signed assessment over supplied input' is vague and doesn't clearly state what the tool does. It echoes the title without clarifying that it assesses the freshness of a quote. It doesn't distinguish it from sibling tools like data_freshness_certificate or live_data_freshness, leaving an agent unable to determine its unique function.

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

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

There is no guidance on when to use this tool versus any alternative. No context is provided about typical scenarios, prerequisites, or exclusions. The agent has no basis to decide between this and the many freshness-related 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, covering the safety profile. The description adds genuinely new context: the 0.002 USDC cost and the fact that all three caps are hard-enforced. However, it does not say what happens on violation (raise, block, return verdict) or what the response contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single compact sentence with the core detection/enforcement behavior front-loaded and the price disclosed last. No filler, though the semicolon-chained phrasing is dense.

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 nested object inputs, two required params and no output schema, the description omits the return contract and the consequence of tripping a cap, which an agent needs to sequence calls correctly. The cost disclosure partially compensates, but the completeness bar is not fully met.

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

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

Schema description coverage is 0%, so the description must carry the burden, and it does reasonably: 'per-step identity, token and cost counters' maps to the trace item fields (id, tokens, cost_atomic) and 'all three hard caps' maps to the policy's max_steps/max_tokens/max_cost_atomic. It stops short of naming field names or clarifying the 'atomic' unit 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 names concrete actions (require per-step identity/token/cost counters, detect repeated nodes/edges, enforce three hard caps), which tells an agent exactly what this guard does. The cycle-detection and budget-cap combination distinguishes it functionally from neighbors like concurrency_guard, though no sibling is named explicitly.

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

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

There is no statement of when to invoke this tool, in what pipeline stage, or which alternatives (concurrency_guard, agent_budget_guard, subscription_spend_guard) apply instead. The agent must infer usage entirely from the behavior sentence.

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. It discloses the cost (0.015 USDC), the evidence nature (observed official sources, literal screening), and a limitation (not legal clearance). However, it omits return format, permissions, whether it is read-only, and what evidence is produced, leaving moderate gaps.

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, compact sentence with semicolon-separated clauses that are front-loaded with the core purpose, cost, and limitation. Every clause earns its place and there is no 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 nested input schema, no output schema, and no annotations, the description is too thin. It lacks any explanation of return values, error behavior, or how the subject and source_urls parameters are structured, leaving an agent without enough context to invoke it confidently.

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

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

Schema description coverage is 0% with three parameters, including a nested subject object and a source_urls array. The description provides no additional meaning for any parameter—no guidance on subject fields, jurisdiction usage, or source_urls purpose—so it fails to compensate for the undocumented schema.

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

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

The description states a specific verb and resource: 'literal subject screening against observed official US/EU sanctions sources.' It is clear what the tool does and distinguishes itself from the broader compliance siblings by emphasizing evidence-based, literal screening. However, it does not explicitly name sibling alternatives to further sharpen differentiation.

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 phrase 'Not legal clearance or wallet attribution' sets a boundary by stating what the tool is not, which implies it should be used for evidence-based screening rather than legal opinions or wallet attribution. But it gives no explicit when-to-use guidance relative to siblings like rwa_compliance or verify, so usage is only implied.

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 does disclose genuine behavior beyond the schema: free tier, rate limiting, non-mutation of payment-critical values. But it omits error/invalid-payload behavior, what the rate limit actually is, and whether normalization mutates or returns a new payload.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the key guarantee front-loaded after the purpose clause; no filler. Slightly dense with unattributed modifiers ('Free, rate-limited') but appropriately sized.

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 and no annotations, with a nested free-form payload object and an undocumented required target_service string. An agent cannot reliably construct a valid invocation from this description alone; payload shape, service identifiers, and failure behavior are all 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?

Schema description coverage is 0%: the nested 'payload' object has no field documentation, and 'target_service' is never mentioned in the description at all, so its expected values are entirely unknown. The description adds some intent ('payment-critical values are never changed') but does not compensate for the uncovered, required parameters.

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

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

States a specific action pair (validation and safe key normalization) on a specific resource (payload) with scope (before payment). The adjectival 'Free, rate-limited' implicitly distinguishes it from the sibling schema_normalize, but the distinction is left for the agent to infer rather than stated.

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

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

Gives a clear timing context ('before payment'), which implies when to reach for it, but never names the alternative schema_normalize or states when to use the paid variant instead. No exclusions or prerequisites are given.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It does mention 'identity limitations' and a cost of 0.006 USDC, but it does not state whether the operation mutates state, requires authentication, has rate limits, or what outcomes an agent should expect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is short but reads as a noun-phrase fragment rather than a usable definition. It front-loads no actionable information, and the cost/limitation details are appended without explanation, so brevity comes at the expense of substance.

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

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

Given three parameters, a nested object, no output schema, and dozens of sibling tools, this description is far too sparse. An agent cannot determine how to construct a valid request, what response to expect, or how this tool fits among its alternatives.

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

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

Schema description coverage is 0% and the description does not mention query, subject, or source_urls. The required source_urls parameter is undocumented, and the nested subject object is entirely unexplained, so the agent cannot infer parameter semantics from either source.

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

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

The description identifies the tool's domain (public social-source observations) and mentions attribution and identity limitations, but it lacks a verb stating what the tool actually does – e.g., fetch, verify, or record evidence. Without that, an agent cannot determine how it differs from siblings like fetch_evidence, source_backed_search, or onchain_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?

No guidance is given on when to use this tool rather than the many evidence-related siblings. The only contextual clue is the 0.006 USDC price, which implies a paid operation, but no selection criteria, prerequisites, or exclusion conditions are stated.

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

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

No annotations are present, so the description carries the full burden. It discloses the output nature (citations and hashes) and a monetary cost of 0.004 USDC, which is useful behavioral context. However, it does not mention whether the operation is read-only, any rate limits, or error behavior. The cost disclosure is valuable, but the lack of side-effect or safety information leaves some gaps.

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, information-dense sentence that includes the core operation, key output features, and cost. No filler words; every element adds value. It is appropriately front-loaded and easy to parse.

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 low complexity (two simple parameters, no output schema), the description covers the essentials: what it does, what it returns, and its cost. However, it omits details like the expected output format (e.g., list of results, ordering), any limitations (beyond max 5 sources in schema), and how errors or invalid URLs are handled. For a simple tool this is acceptable, but not fully 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?

The schema has 0% description coverage, so the description should compensate by explaining what query and source_urls mean. It only implies that source_urls are supplied public sources and that query is a literal search string. It does not specify how to format the query (e.g., single string vs. multiple terms), what constitutes a valid source URL, or any constraints beyond those in the schema. This provides minimal additional meaning over the field names.

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

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

The description states a precise action ('search') with a specific resource ('supplied public sources'), and adds distinctive details: 'literal' search, citations, hashes, and a fixed cost. This clearly distinguishes it from sibling tools like verified_web_extract or journey_verify, which focus on extraction or verification rather than user-supplied source search.

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 no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or conditions that would lead an agent to choose this over other search-like tools. All contextual selection must be inferred from the tool name and description.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior, lowering the burden. The description adds that the result is deterministic and signed, which is useful context beyond the annotations, but it does not clarify side effects, requirements, or output behavior beyond that.

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 compact sentence with no filler and the key behavioral trait (deterministic signed assessment) is front-loaded. It is concise, though the brevity comes at the cost of operational detail.

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

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

Even with annotations and an output schema, the description leaves the core question unanswered: what exactly is being checkpointed and assessed? With an unconstrained input schema and a long list of sibling evidence tools, an agent has too little information to select and call this tool correctly.

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

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

The schema requires 'checkpoint' and allows additional properties, but neither the schema nor the description explains what a checkpoint is, what shape it should take, or what other inputs are accepted. The phrase 'supplied input' does not compensate for the absence of any parameter 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 phrase 'deterministic signed assessment over supplied input' indicates the tool evaluates input and produces a signed result, but it never states a specific action verb or what distinguishes this evidence tool from the many similar sibling evidence tools. It leans heavily on the name itself.

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

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

There is no guidance about when to use this tool versus an alternative such as task_cancel_assurance, agent_task_handoff_receipt, or other evidence/assessment tools. No context, exclusions, or selection criteria are provided.

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

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

With no annotations, the description carries the full burden. It discloses that the operation is free and requires no wallet, suggesting a non-mutating informational action. However, it does not explicitly state that it does not execute the service, only that it gives a 'preview', and it omits any potential side effects or error behavior. The transparency is decent but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that covers the essential points: free, representative preview, exact price, upgrade instructions, and no wallet requirement. Every phrase adds value, with zero wasted words. It is ideal for quick agent comprehension.

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 one parameter with a large enum, no output schema, and no annotations. The description explains what it returns (preview, price, upgrade instructions) and that it targets paid services. It does not mention error handling or output format, but given the informational nature, it is largely sufficient for an agent to 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?

The schema has 0% description coverage, so the description must add meaning. It clarifies that the 'service' parameter selects a paid service from the enum. However, it does not elaborate on what each enum value represents or how to choose between them. Given the long list of services, this is a minimal but helpful clarification.

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 clear purpose: providing a free preview, exact price, and upgrade instructions for any PHION paid service. It explicitly notes that no wallet is required, distinguishing it from tools that execute actual paid transactions. The verb 'provide' and resource 'preview, price, upgrade instructions' make the action specific.

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 does not provide explicit guidance on when to use this tool versus the many service-specific siblings (e.g., payment_preflight, attest). It implies generic applicability ('any PHION paid service') but lacks a clear 'use this when...' or 'use that instead...' instruction, leaving the agent to infer the appropriate choice.

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 must disclose behavior on its own. It does mention a cost of 0.006 USDC and the bounded news-source scope, which is useful, but it never explains what 'evidence' means, whether the tool is read-only, what happens when the query is not found, or if execution triggers a payment.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short, but it is a fragmented noun phrase rather than a structured tool definition. It omits essential information and reads more like a tagline than a functional specification, so the brevity is under-specification rather than conciseness.

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

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

With two undocumented parameters, no output schema, no annotations, and a large suite of sibling evidence/search tools, this description is far from adequate. An agent cannot know what to pass, what to expect back, or how this differs from the many comparable tools in the sibling list.

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

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

Schema description coverage is 0%, and the description does not mention query or source_urls at all. The agent receives no help understanding that source_urls is required, how many URLs to supply, what kind of URLs are accepted, or how query affects the behavior.

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

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

The phrase 'Literal query evidence across bounded public news sources' suggests the tool returns evidence of a query restricted to news sources, but it lacks a clear verb such as 'fetch', 'verify', or 'search'. The purpose is vague enough that an agent could mistake it for a search tool or an evidence-certification tool, especially given many similar siblings.

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

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

There is no guidance about when to use this tool versus siblings like source_backed_search, verified_web_extract, or multi_source_fact_bundle. The description gives no exclusions, prerequisites, or selection criteria, so an agent is left to guess based only on the name.

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

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

With no annotations, the description carries the burden. It discloses that extraction is bounded, includes source/timestamp/hashes, and costs 0.003 USDC. However, it doesn't explain what 'verified' means behaviorally, whether it fetches live or cached content, or what happens on failure. The cost disclosure is useful but the verification semantics are vague.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One compact sentence with useful specifics (bounded, source, timestamp, hashes, cost). It's front-loaded with the core action and scope. Could add a bit more context without becoming bloated, but it 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?

For a tool with no output schema and no annotations, the description is thin. It doesn't explain the return format, how verification works, what 'bounded' limits are (beyond maxItems 5 in schema), or how query and expected_fields shape the result. An agent would need to guess at critical invocation details.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'source' which maps to source_urls, but doesn't explain query or expected_fields at all. The description adds minimal meaning beyond the schema's parameter names, leaving the agent to guess how query and expected_fields interact with extraction.

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 ('extract') and resource ('public web') with bounded scope, and mentions source, timestamp, and hashes. It doesn't explicitly differentiate from siblings like source_backed_search or fetch_evidence, but the 'verified' and 'bounded' framing gives a clear sense of what it does.

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

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

No guidance on when to use this tool versus alternatives like source_backed_search, fetch_evidence, or verified_news_monitor. The description implies a use case (bounded public web extraction with verification) but doesn't state when to prefer it or what conditions make it appropriate.

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

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

With no annotations, the description carries the full behavioral burden. It only discloses that verification is 'Free' (a genuine cost signal), but says nothing about whether it is read-only, what permissions it needs, what a failed verification looks like, or what the tool returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no filler. It is efficient, though arguably under-specified rather than truly concise given the gaps elsewhere.

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

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

For a tool with three parameters, nested objects, 0% schema coverage, no output schema, and no annotations, one sentence is insufficient. An agent lacks guidance on what 'content' and 'sources' are for and how to interpret a verification result.

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

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

Schema description coverage is 0% for three parameters, and the description only implicitly touches the 'receipt' parameter. The 'content' and 'sources' parameters (the latter an array, the former unexplained) receive no meaning at all, leaving most inputs undocumented.

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

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

The description gives a specific verb and resource: 'verification of a PHION signed receipt.' An agent can tell this is a verification tool, not an attestation or payment tool. However, it offers no differentiation from the sibling 'journey_verify,' which also sounds like a verification operation, and the 'PHION' term is opaque without domain context.

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

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

There is no statement of when to use this tool versus alternatives like journey_verify, attest, or preflight, and no prerequisites or exclusions. The only usage-adjacent signal is 'Free,' which hints at cost but not routing.

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