PHION RWA

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 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 idempotent, read-only, open-world, non-destructive behavior, so the bar is lower. The description still adds two valuable facts annotations cannot convey: it is fail-closed (rejects rather than degrades when evidence is missing) and it carries a cost of 0.019 USDC, which matters for a paid/x402 call.

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

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

A single sentence with zero filler, and the fail-closed posture is front-loaded. It is telegraphic to the point of being jargon-dense, 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?

No output schema exists and the input schema is essentially opaque (a bare nested object), so the description would need to carry more weight. It covers behavior and price but omits what evidence is returned, what a failed/closed result looks like, and what the undocumented parameters must supply.

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 'asset' is a nested object with no documented fields, yet the description says nothing about what asset, source_urls, or declared_facts should contain. 'Independently fetched evidence' hints at the tool's posture, not at parameter shape, so the three undocumented parameters are never compensated for.

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 resource (RWA asset due diligence) and enumerates the exact coverage dimensions: issuer, contract, jurisdiction, custody, documentation. That is far more concrete than a tautology, but it never distinguishes itself from close siblings such as rwa_compliance, rwa_sanctions_screening_evidence, or rwa_transaction_assurance, so an agent cannot route between them from the text alone.

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

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

There is no when-to-use or when-not-to-use guidance, and no alternative sibling is named. 'Fail-closed' implies it is meant for gating decisions, but the agent is left to infer the trigger condition and the relationship to the other rwa_* 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 cover read-only, idempotency, non-destructiveness and open-world access, so the safety profile is not the description's burden. The description does add two genuinely non-structured traits: fail-closed denial semantics and a 0.012 USDC charge, which matter for an agent deciding whether to invoke a paid gate. It still omits what a denial looks like and whether the call is blocking.

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 the most important trait ('fail-closed') front-loaded and no filler. It is efficient, though the semicolon-separated list of checks and trailing price make it read as a packed clause chain rather than clearly structured guidance.

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, open-world, two-nested-object tool with no output schema and zero schema descriptions is significantly under-documented: the description never explains the shape of 'asset' or 'policy', what source_urls is for, or what the decision result contains. For the complexity indicated, this is not enough to call correctly.

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

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

Schema description coverage is 0% and both required parameters ('asset', 'policy') are untyped nested objects, so the schema provides no semantics at all. The description lists the check categories (jurisdiction, KYC, allowlist, limit, transfer-window), which weakly hints at what 'policy' must contain, but never explains the asset object or the role of source_urls.

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 domain (RWA transfer compliance) and enumerates the check categories it covers, but the operative verb is only implied ('decision') and it gives no signal distinguishing it from siblings like rwa_transaction_assurance or transaction_assurance. An agent can guess its role but cannot confidently route between the overlapping RWA/assurance tools from this text alone.

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

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

There is no explicit when-to-use statement, no prerequisites, and no named alternatives. 'Fail-closed' hints that it is a gate, but nothing tells the agent at which point in a transfer flow to call it versus rwa_sanctions_screening_evidence or payment_preflight.

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

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

No annotations exist, so the description carries the full behavioral burden. It discloses the 0.012 USDC fee, which is useful, but 'sign' implies an on-chain/write action and key requirements that are never explained, and nothing is said about reversibility or 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?

A single dense sentence with the core action front-loaded and the cost appended. It is efficient and waste-free, though arguably too terse for a four-parameter tool.

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

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

For a tool with nested object parameters, 0% schema coverage, no output schema, and no annotations, the description leaves too much unexplained: parameter shapes, signing requirements, and return behavior are all 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% across 4 parameters (3 required), including nested objects like asset/previous_state/current_state. The description only hints at attributes ('NAV, income, maturity, redemption or freeze state') that likely live inside those state objects, leaving source_urls and the nested shapes 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?

States specific verbs (detect, sign) and a concrete resource domain (material RWA changes in NAV, income, maturity, redemption, freeze state), which is far more informative than the bare name. It does not, however, distinguish itself from siblings like rwa_nav_reserve or rwa_compliance, so the agent must infer boundaries.

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

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

No when-to-use guidance, no prerequisites, and no alternatives are named despite dense sibling overlap (rwa_nav_reserve, rwa_compliance, rwa_asset_due_diligence). The only routing-adjacent info is the price tag, which is not usage guidance.

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

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

With no annotations, the description carries the full burden and does disclose several real traits: the return metric (discrepancies in basis points), the fail-closed behavior on incomplete evidence, and the cost (0.015 USDC). It omits some profile details (whether it is purely read-only, permission needs, or what qualifies as 'incomplete'), but the failure semantics and pricing are genuinely useful context.

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

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

A single tightly-packed clause chain front-loads the core purpose, then appends behavior and cost. Every clause earns its place, with only mild density cost from compressing four distinct ideas into one sentence.

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

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

An output schema exists, so the return value need not be re-explained, and the fail-closed note is valuable. But for a complex tool with 5 parameters, nested objects, and 0% schema coverage, the description leaves the parameter surface and required-input shapes largely undocumented, which is a real gap 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 coverage is 0%, so the description must compensate and it partially does: it maps declared_facts and observed_facts to the declaration/observation distinction and source_urls to 'independently fetched evidence'. However it never mentions asset or tolerance_bps, and the nested required keys (nav, reserve_ratio, as_of, unit) go 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 uses a specific verb ('Compare') against clearly named resources ('declared NAV and reserve ratios' vs 'structured observed facts'), so the agent knows this is a reconciliation/attestation tool. It stands apart from generic siblings like verify or signed_result_comparator, though it does not explicitly name which sibling (e.g., rwa_asset_due_diligence, mandate_reserve) it replaces.

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 implies the inputs it needs (declared facts, observed facts, independently fetched evidence) but never states when to reach for it over sibling tools such as mandate_reserve or rwa_compliance, nor any prerequisites. No when-to-use or when-not-to-use guidance is present.

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

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?

No annotations are provided, so the description carries the full behavioral burden, yet it only discloses the price (0.020 USDC). It does not say whether this is a read-only or state-changing operation, what determines pass/fail, whether verification is deterministic, or how failures are surfaced.

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, and the cost is placed at the end where it is easy to scan. It is efficient, though the brevity reflects under-specification as much as discipline.

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 required nested-object parameters, no annotations, no output schema, and zero schema coverage, the description leaves critical context missing: no input shape guidance, no indication of what a successful verification returns, and no routing versus sibling 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?

With four parameters, three required, 0% schema description coverage, and nested objects, the description must compensate and does not. 'Asset, payment, delivery and transfer restrictions' is a loose gloss that never explains what belongs in the asset, transaction, or policy objects, nor the role or cap of source_urls.

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 ('Verify') and enumerates the resources covered: RWA asset, payment, delivery, and transfer restrictions. This is more than a restatement of the name, though it never distinguishes itself from close siblings like rwa_compliance or transaction_assurance, which appear to operate in the same space.

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 rwa_compliance, rwa_asset_due_diligence, transaction_assurance, or the preflight family. The agent is left to infer selection from the name alone, and the description gives no conditions, prerequisites, 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?

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 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?

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.