FET112

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds the useful behavioral constraint that it performs no model or chain RPC calls, but it does not describe the returned catalog structure or any limits, so the added transparency is modest.

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

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

Two tightly written sentences with no filler, and the main purpose is front-loaded. The second sentence adds an important contrast without wasting space.

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

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

For a zero-parameter catalog tool with full annotation coverage, the description sufficiently explains the catalog's contents and its non-RPC nature. It could be stronger by explicitly tying the catalog to analytics_query, but it is complete enough 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?

The tool has zero parameters, so parameter semantics are not a meaningful burden. The schema has 100% description coverage and the description correctly discusses only what the catalog contains, not parameter usage.

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 clear verb ('Discover') and lists specific resources: native metrics, semantics, aggregations, coverage requirements, and executable query examples. It distinguishes itself from an execution tool by being a catalog and by stating it makes no model or chain RPC calls, though it does not explicitly name the sibling analytics_query.

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

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

Usage is implied by 'Discover' and by the contrast with RPC calls, suggesting this is a reference/discovery step rather than query execution. However, it never explicitly says when to call this versus fet112.analytics_query or that it should be used before querying.

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, so the description's added value is the domain semantics: missing coverage errors instead of returning zero, top rankings cannot span buckets, amount maxima do not reveal tx hashes, and no native security or anomaly decisions. These are real, non-obvious traits beyond the annotations. It still says nothing about result shape or row limits, which matters since there is no output schema.

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

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

Front-loaded with the operation, then a prerequisite, then caveats; no filler sentences. A few clauses are telegraphic to the point of ambiguity ('Inspect integrity and consumer_policy'), which costs a bit of clarity.

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 14-parameter tool with no output schema needs more: the description covers pitfalls and prerequisites but leaves every parameter's meaning and the returned structure undocumented. The caveats are the right kind of content, but coverage is insufficient for a query tool this wide.

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 14 parameters, so the description carries the full explanatory burden and does not meet it. Nothing is said about metric selection, period/start_date/end_date interaction, grain, rollup, compare, group_by, dimension_filter syntax, or the 'schema' field. Only the vague phrase 'comparable UTC windows' gestures at compare 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?

States a specific verb and resource ('Execute a validated read-only native Fetch query') and enumerates the analytical shapes supported (sums, extrema, weighted means, groupings, rollups, UTC windows). It is clearly the query-execution counterpart to analytics_catalog, though that differentiation is implied rather than explicit.

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

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

Gives an explicit prerequisite ('Read analytics_catalog first') and names the sibling, plus concrete constraints on when a result is invalid ('Top rankings cannot be combined across buckets'). It does not give an explicit when-not-to-use case or point to the security/anomaly siblings by 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?

Beyond the readOnly/idempotent/openWorld annotations, the description discloses the freshness model (fresh/stale/partial/unavailable), what is included (signed coverage, source cursor, issue/expiry times), and real operational constraints — the archive is process-local, capped at 128 documents, one hour, and lost at restart. That is material context an agent would otherwise discover only by failing.

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

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

Front-loaded with scope in the first sentence and the retrieval mode plus limits last; no filler. It is telegraphic and dense, but every clause conveys distinct information.

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

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

There is no output schema, yet the description enumerates what comes back (signed coverage, source cursor, issue/expiry times, observation status) and what explicitly does not. Combined with the archive limits and the single optional parameter, an agent has everything needed 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 coverage is 0%, so the description must carry the lone parameter, and it does: content_hash 'retrieves an exact retained document', with the retention limits given so the agent knows the hash may no longer resolve. The hash syntax itself is documented by the schema pattern, so no duplication is needed.

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

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

States a specific verb and resource ('Attest observed native fetchhub-4 gas, transactions and blocks') plus a precise scope ('latest available finalized hour, four 15-minute windows'). The exclusion clause ('No Ethereum data, native security verdict, anomaly assessment or live chain RPC') implicitly separates it from security_report and network_status, but no sibling is named outright.

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?

Exclusions hint at when this tool is the wrong choice, and the coverage/status framing implies its role, but there is no explicit 'use verify_network_state_attestation to check the signature' or 'use network_status for live chain data'. The agent must infer the routing from the sibling names alone.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds a genuinely non-obvious security caveat — that retrieved keys are not themselves a trust anchor — which is behaviorally important and not derivable from annotations. It stops short of describing return format or freshness/rotation 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?

Two sentences with zero filler, and the core capability is front-loaded before the caveat. The second sentence is terse to the point of being cryptic on its own, which slightly undercuts an otherwise efficient structure.

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

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

With no output schema and no annotations about authentication or freshness, the description is the only place an agent could learn what comes back (key format, fingerprint encoding, rotation) and whether any auth is required. It names the two returned artifacts but gives no shape or usage path, leaving gaps for a security-critical discovery call.

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

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

The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline for a zero-parameter schema applies. No parameter-related claims are made, correctly.

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

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

States a specific verb (discover) and resource (current Ed25519 public key and fingerprint), which separates it from the attestation-verification siblings that consume such keys. It does not name any sibling explicitly, so the distinction from network_state_attestation or verify_network_state_attestation is inferable 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?

The clause 'Discovery is not an independent trust anchor' implies the key must be corroborated through an attestation tool, but it never says so directly or names which sibling to use for that corroboration. Usage is suggested by security context rather than specified.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description adds substantive context beyond that: the verdict's provenance (copied from SecurityReportV1) and a semantic scope constraint about chain_id=1 versus fetchhub-4. It stops short of describing the shape or freshness of the returned verdict.

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

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

Two sentences with no filler: the purpose is front-loaded, followed immediately by the scope/provenance caveat and the exclusion. Every clause carries information an agent needs.

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 input parameters, no output schema, and annotations covering safety, the definition supplies the essential missing pieces: what the value represents and where it applies. The main remaining gap is that the returned "status" or "verdict" is never characterized (possible values, freshness), which the absent output schema would otherwise have covered.

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

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

The tool takes zero parameters, so there is no parameter semantics to document; this is the baseline case for a well-formed no-arg tool. The description appropriately spends its space on scope and provenance instead.

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

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

States a specific verb and resource ("Return FET112's current machine-facing network status") and pins the scope to configured Fetch/ASI contracts on Ethereum chain_id=1. It also clarifies the data is derived from SecurityReportV1, which partially distinguishes it from siblings like fet112.security_report, though it never explicitly names which sibling to use for other cases.

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

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

Provides a clear scope boundary with "Do not apply it to native fetchhub-4 traffic," which is an explicit when-not condition an agent can act on. However, it does not name the alternative tool to use for fetchhub-4 traffic or for non-configured contracts, leaving the routing inference to the agent.

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

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

The description says 'V1 commits the intended action,' which implies a state-changing commit, while the annotations declare readOnlyHint=true. This is an annotation contradiction, and the description otherwise does not explain permissions, output behavior, or what the deterministic check actually does.

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, front-loaded, and uses two sentences that each contribute purpose or scope limitations. It is efficient, though the dense V1 caveat could be clearer.

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 5-parameter tool with no output schema and no schema descriptions, the description omits what the pre-flight returns, what checks are performed, and how required parameters should be formatted. It does state V1 exclusions, which prevents a score of 1, but it is not complete enough for reliable 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 for undocumented parameters. It only mentions destination, amount, and asset in the negative ('does not classify') and never defines action, metadata, or expected formats such as Ethereum address versus string amount, leaving parameter semantics largely 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 identifies a deterministic pre-flight check in the Ethereum security domain and lists exclusions, but the phrase 'commits the intended action' is ambiguous and it does not clearly state what the check actually verifies or returns. It also does not distinguish the tool from siblings such as transaction_comparison or security_report.

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 term 'pre-flight' implies the tool should be used before executing an action, which gives some usage context. However, there is no explicit when-to-use/when-not-to-use guidance and no mention of alternative tools among the many fet112 siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds two genuine facts beyond that: results are bounded and scoped to the signed report context (an implicit auth/session dependency). It does not explain pagination behavior, ordering, or what an incident record 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 front-loaded sentence with no filler. It is efficiently structured, though its brevity is partly under-specification rather than 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?

Four undocumented parameters, no output schema, and a mutation-free but context-dependent read. For a tool whose inputs include an enum severity filter, a cursor, and a block-height bound, one sentence describing scope is not enough 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% and the description does almost nothing to compensate. 'Bounded' hints at the limit parameter, but severity filtering, cursor pagination, and since_height (presumably a block height) are entirely unexplained, leaving the agent to infer semantics from bare property 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?

States a specific verb ('Return'), resource ('recent incidents'), and scope qualifiers ('bounded', 'associated with the current signed report context'). It is clear what the tool fetches, though it never differentiates itself from siblings like fet112.security_report or fet112.transaction_activity, so an agent gets no routing help 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 a faint precondition ('current signed report context'), but no explicit when-to-use, when-not-to-use, or alternative tool. Nothing tells the agent whether incident data should come from here versus security_report or analytics_query.

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

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

Annotations already declare this read-only, idempotent, and non-destructive, so the safety profile is fully covered by structured data. The description adds scope value by noting it only covers configured contracts and omits native traffic, but says nothing about freshness/caching, who signs the report, or expected failure when nothing is configured.

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

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

Two sentences, front-loaded with the artifact returned, followed immediately by the negative scope. No filler and nothing repeated from the schema or annotations.

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

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

For a zero-parameter, no-output-schema tool, the agent cannot learn what fields the SecurityReportV1 contains, whether it answers the question at hand, or how to verify it (sibling verify_attestation exists). The description is accurate but thin on what the caller actually receives.

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

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

Zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the mention of chain_id=1 correctly signals that the chain is fixed rather than configurable.

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?

Specific verb + resource ('Return the current signed SecurityReportV1') with an explicit scope (configured Fetch/ASI contracts on Ethereum, chain_id=1). It distinguishes itself from the network_state_attestation siblings by naming the exact artifact type, though a reader still needs domain knowledge of what SecurityReportV1 is.

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 exclusion 'does not evaluate native fetchhub-4 traffic' implies that native traffic queries belong elsewhere, but no sibling is named and no positive trigger ('use this when you need an auditor-verifiable snapshot') is given. Usage is inferable rather than 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?

Beyond the read-only and idempotent annotations, the description discloses important behavior: finalized 15-minute buckets, exact afet strings, coverage and source cursor, signature status in integrity.signed, and a crucial error semantic that failures mean unavailable evidence rather than zero flow.

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 front-loaded with the core flow definition, then adds only high-value clarifications: exclusions, return shape, integrity field, error semantics, and defaults. Every sentence adds useful information without redundancy.

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

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

With no output schema, the description does a good job explaining what is returned: exact afet strings, coverage, source cursor, and signature status. It also covers error semantics and defaults. The main remaining gap is lack of explanation for the schema parameter and baseline_days range.

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 parameter meaning. It clarifies the period values and default (today) and baseline default (7 days), but leaves the schema parameter unexplained and does not mention the baseline_days 1-30 range. This is partially compensating but incomplete.

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 and scope: observed native Fetch staking flow on fetchhub-4 for today/yesterday UTC. It also explicitly distinguishes the tool from total staked balance, anomaly assessment, and security verdicts, so an agent can tell what it is and is not.

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

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

The description gives clear temporal usage boundaries (today or yesterday UTC) and explicit exclusions (not total staked balance, anomaly assessment, or security verdict). It does not name sibling tools as alternatives, but the exclusions and defaults provide sufficient usage context.

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

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

Annotations already establish read-only, idempotent, non-destructive, open-world behavior. The description adds substantial behavioral detail beyond them: empty periods with valid coverage return zero TPS and NOT_APPLICABLE/null success percentage, missing evidence returns an error rather than zero activity, and signature status is exposed explicitly in integrity.signed. It also clarifies that no anomaly or security verdict is provided.

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

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

The description is front-loaded with the core purpose and scope, then packs return semantics, edge-case behavior, exclusions, and integrity notes into a small number of dense, useful sentences. 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?

For a read-only tool with no output schema and only two simple parameters, this description covers what is returned, how empty or missing data is handled, and what the tool is not. The only meaningful gap is the unexplained 'schema' parameter, and there is no explicit routing to sibling tools for related comparisons.

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 parameter meaning. It explains the period parameter adequately ('today or yesterday UTC', default today) but does not describe the 'schema' parameter or its enum at all, leaving one of two parameters 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 data resource (native fetchhub-4 transactions in blocks for today/yesterday UTC) and precisely lists what the tool returns: successful/failed/total counts, success percentage, and average TPS over 15-minute buckets. It also explicitly excludes related but different metrics such as peak TPS, capacity, messages, and mempool attempts, which helps distinguish it from sibling tools.

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

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

Usage context is clear: the tool covers today or yesterday UTC and defaults to today. The description also provides useful exclusions ('Not peak TPS, capacity, messages, or mempool attempts'), but it does not name or route to specific sibling alternatives such as fet112.transaction_comparison or fet112.analytics_query.

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?

Goes well beyond the readOnly/idempotent annotations by disclosing consistency semantics ('Both windows come from one SQLite snapshot'), the cutoff definition ('today's latest authoritative finalized cutoff'), and failure behavior ('unavailable coverage returns ErrorV1'). It also flags trust obligations ('Inspect integrity.signed and verify the quantitative attestation before claiming verification'), which an agent could not infer from structured fields.

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 comparison scope is front-loaded in the first clause, followed by data-source, return-value, exclusion, and verification sentences in descending order of importance. No sentence is redundant despite the dense jargon.

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

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

With no output schema, the description still enumerates the return payload (counts, success rates, exact count difference, percentage change) and the error contract (ErrorV1). It also covers the trust/verification workflow, leaving nothing an agent needs in order to call and interpret it.

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

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

Schema coverage is 0%, but the single parameter is a fixed enum discriminator with no tunable semantics, so the description has little to add. It correctly spends no words on it; only the subtle meaning of the enum constant is undocumented, a minor 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 and resource ('Compare native fetchhub-4 transactions TODAY and YESTERDAY') plus the exact comparison basis (same elapsed UTC interval, today's finalized cutoff), which is far more precise than the title. It never names the adjacent sibling (fet112.transaction_activity) that an agent might confuse it with, so differentiation is by scope description rather than explicit contrast.

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

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

Provides clear operating context: 'Follow consumer_policy', and explicit exclusions ('No significance test, anomaly decision, cause attribution, forecast or native-chain security assessment') tell the agent when this tool is the wrong choice. It lacks a positive routing statement naming the alternative tool to use for those excluded needs.

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

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

The description says verification is performed 'offline', which conflicts with the openWorldHint=true annotation indicating possible interaction with an open world of external entities. Although it adds useful trust-anchor context, this direct tension with the annotations requires the contradiction score.

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

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

The description is a single front-loaded sentence with no wasted wording. It communicates the core action, mode, and optional trust anchor efficiently.

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

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

For a verification tool with opaque nested objects and no output schema, the description leaves important context unspecified: what verification returns, how failures are represented, and what format the report and attestation objects must take. The offline/openWorld conflict further reduces completeness.

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

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

The description maps the three parameters semantically: report is a SecurityReportV1, attestation is its paired proof, and trusted_key_fingerprint is optional. However, with 0% schema description coverage and nested object parameters, it does not explain the required object shapes, fingerprint format, or nested fields.

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

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

The description states a specific verb and resource: verify an arbitrary SecurityReportV1/attestation pair. The word 'arbitrary' implicitly distinguishes this generic verifier from specialized siblings such as verify_network_state_attestation and verify_quantitative_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?

It conveys the intended context—offline verification with an optional trusted key fingerprint—but does not explicitly say when to use this tool versus its specialized verification siblings or when not to use it.

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

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

Adds meaningful behavioral context beyond annotations: it discloses the verification checks performed and the important limitation that no live chain canonicality check occurs. However, it does not describe the return value or failure modes, which matters because no output schema is present.

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

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

Two tightly written sentences with the core verification scope front-loaded and the limitation stated second. There is no redundant or filler text.

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 a nested object parameter, no schema descriptions, and no output schema, the description leaves key invocation details unknown: the document shape, fingerprint format, and what verification result is returned. It gives enough to understand intent but not enough to call 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 coverage is 0% and neither parameter is named or described. The phrases 'signed payload' and 'pinned identity' loosely hint at the document and trusted_key_fingerprint parameters, but provide no format, type, or requiredness guidance.

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

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

States a specific verb (verify) and specific resources: canonical signed payload, pinned identity, expiry, and source age. It differentiates itself from a live chain canonicality check, though it does not name sibling verification tools such as verify_attestation or verify_quantitative_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?

Provides clear usage context by describing independent verification and an explicit exclusion: 'No live chain canonicality check.' It stops short of naming alternatives for live-chain checks or pointing to sibling tools for related operations.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real value beyond them by bounding what the verification does not cover (canonicality, freshness, security), but it says nothing about verification failure behavior, error signaling, or what a successful result 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?

Two short sentences, front-loading the action and then the constraints; nothing is redundant. The density is partly achieved by jargon compression, which costs clarity rather than words.

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

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

With no output schema, a required nested `context` parameter at 0% schema coverage, and undefined jargon, the description is insufficient for an agent to call the tool confidently or interpret the result. The scope disclaimer is the only genuinely complete piece of 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 carries the full burden. It clarifies the role of trusted_key_fingerprint ('to verify identity') but leaves the required `context` object — a nested object with no schema detail — completely unexplained, so the agent cannot construct a valid call from the docs 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 verb 'Verify' and resource 'native quantitative Ed25519 attestation' are stated, but 'quantitative context' is domain jargon that is never unpacked, so the agent must infer what is actually being checked. It is distinguishable in tone from fet112.verify_attestation and fet112.verify_network_state_attestation only by the word 'quantitative', not by any explicit contrast.

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?

'Supply a trusted fingerprint to verify identity' gives one concrete call precondition, and the negative scope ('does not evaluate chain canonicality, freshness or security') usefully implies which sibling to pick for those concerns. However, no sibling is named and no positive trigger explains when this should be called instead of verify_attestation.

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