FOGA node

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

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description still adds real behavioral context beyond them: it discloses that the response is role-dependent, with budget books, open operations, and running jobs visible only to the operator. That auth-scoped output variation is the kind of thing annotations cannot express.

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 sentence with the resource front-loaded and no filler, which is good. But the bulk of it is a semicolon-delimited enumeration of returned fields that the output schema already documents, so a large share of the text does not earn its place as 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?

Because an output schema exists, the description does not need to enumerate return values, and the role-conditional note is a valuable addition. What is missing is anything about when this snapshot should be taken versus the many sibling inspection tools, which is the main decision an agent faces here.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. Nothing in the description misrepresents or omits parameter 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 description names the resource ('the node's own cell') and enumerates the facets it reports (account and roles, anchor state, binding verdict, skills, policy summary), so the general purpose is inferable as a status snapshot. However, there is no verb and no differentiation from adjacent status/inspection siblings such as identity_resolve, kya_check, safety_status, or docs_status, so an agent cannot tell from the text alone why it would pick this one over those.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives, despite a sibling set containing at least four overlapping inspection tools. The only conditional statement ('for the operator also...') describes output variation by role, not when to invoke the tool.

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

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

The annotations already establish that this is a safe read-only, idempotent operation. Beyond that, the description adds meaningful context about the comparison being performed and the categories of returned data, including agreement between local manifests and chain commitments.

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 one dense sentence with no wasted filler, and the core purpose is front-loaded. The parenthetical and em-dash list add necessary detail, though the sentence is compact enough to be slightly hard to parse at first glance.

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

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

Given that there are no parameters, annotations cover the safety profile, and an output schema exists, the description is sufficiently complete. It briefly but clearly establishes what data the tool surfaces and what relationship it checks.

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 are no parameter semantics to explain beyond the schema. The baseline for a zero-parameter tool is 4.

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

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

The description clearly states that the tool returns the cell's built document manifest and the corresponding on-chain commitment data, including whether they agree. It is specific about resources and fields, but does not explicitly distinguish itself from siblings such as cell_status.

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

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

Usage is implied by the description: use it to inspect document build state versus chain state. However, it gives no explicit when-to-use guidance, no exclusions, and does not name alternatives for similar status checks.

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, so safety is well covered. The description does add real behavioral context beyond them: results are assembled from multiple registries (reference and backing) and one facet is conditional on the address being a cell account. It stops short of stating what happens for unknown addresses, unregistered addresses, or non-EVM input, which matters for an open-world resolver.

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 sentence with no filler, which is appropriately sized. But the structure is a dense colon-list of five ERC identifiers, front-loaded with an abstract noun phrase rather than the action, making it slower to parse than it needs to be.

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 facet list need not be re-explained and return values are documented elsewhere; the schema constrains the single input. What is missing relative to the tool's complexity is disambiguation from the single-facet siblings and any statement about behavior on unresolved addresses. 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?

With one parameter and 0% schema description coverage, the schema carries only a regex pattern (0x + 40 hex). The description mentions 'an address' and ties it to identity facets, which implies an EVM account address and connects the argument to the resolution semantics. It never states the accepted address forms or that the regex enforces EVM format, so the compensation is partial.

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 sentence enumerates the facets returned (ERC-8004 agent, ERC-8434 registry state, ERC-8444 record, KYA level, ERC-8468 cell status), so the resource is identifiable as a consolidated identity record for an EVM address. However, it is a noun phrase rather than a verb+resource statement, and the phrase 'ten-ERC view' does not match the five standards actually listed, which leaves the scope of the resolution ambiguous. It also never states what the returned object is (a merged record vs. multiple records) or that resolution is read-only lookup.

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 at all. The sibling list contains kya_check, cell_status, and world_describe, which appear to cover a subset of what this tool aggregates, yet the description gives no routing rule such as 'use this for a full profile, use kya_check for just the KYA level'. The conditional clause 'when the address is a cell account' hints at behavior but is not framed as 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely new context by disclosing that resolution happens via the registry and that scheme and issuers default to the cell's standing configuration. It does not, however, explain behavior for accounts with no KYA level or what a check against a threshold 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?

It is a single dense sentence with no filler, and the default-behavior caveat is packed into a parenthetical rather than buried later. The phrasing is compact and front-loaded, though the fragment style makes it feel like a schema docstring rather than an actionable instruction.

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 the description leaves important gaps for a registry-backed lookup with zero schema documentation. Most critically, the minLevel parameter's effect is never stated, and there is no indication of what happens when an address has no resolvable level. For a four-parameter tool with no documented parameters, this is insufficient.

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

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

Schema description coverage is 0%, so the description carries the full burden for four parameters. It only sheds light on 'issuers' and 'schemeId' through the defaults clause; 'address' is self-evident from its pattern, but 'minLevel' is left entirely unexplained, leaving the agent unable to tell whether it acts as a filter, an assertion, or a threshold on the returned level.

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

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

The description identifies the resource (an account's level under a KYA scheme) and the resolution source (the registry), which is more specific than the title alone. However, it is written as a noun phrase describing a return value rather than stating an action, so the agent must infer that it performs a lookup. It also does not distinguish itself from the sibling identity_resolve or safety_status 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 explicit when-to-use guidance, no prerequisites, and no mention of alternatives among the many siblings such as identity_resolve or safety_status. The parenthetical about defaults ('the cell's standing scheme and issuers by default') hints at a default context but does not tell the agent when this tool is the right 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?

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered by structured data. The description adds real context beyond them: no chain interaction, no key required, no cost, and that the payload is inert data the caller applies at its own discretion. It does not describe size, freshness, or whether the returned pointer/covenants are versioned.

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 dense sentence with no wasted paragraphs, and the substance is front-loaded. But the adjective stacking ('free, off-chain', 'declinable') and unexplained proper nouns make it slower to parse than its length warrants.

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, read-only fetch with a declared output schema, the description covers the essentials: what comes back, that it is safe and free, and that consumption is caller-defined. The remaining gap is ecosystem terminology that is never grounded, which matters because sibling tools reference the same vocabulary.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The enumeration of returned material usefully primes the caller on what the payload contains even though the output schema already defines it.

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

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

The description enumerates what the kit contains (replication pointer, discovery coordinates, ten covenants, a cell-creation command) and that it is free/off-chain data, which is more than a restatement of the name. However, it is a noun phrase with no verb and heavy in-group jargon ('FOGA', 'declinable replication pointer', 'cell'), so an agent unfamiliar with the ecosystem cannot confidently say what the call returns or how it differs from spec_read or docs_status.

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 only usage statement is that 'the agent chooses where and how to use it', which defers all decision-making to the caller. There is no indication of when to call this rather than spec_read, world_describe, or docs_status, and no prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered without description help. The description adds that the default subject is the node's own account and enumerates the verdict payload (reasons, restrictions, bindings and states), but says nothing about where the verdict comes from, whether results are cached or can change over time, or any auth requirements — relevant given openWorldHint implies external data.

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 the resource, the default, and the returned fields; there is no filler. It is dense with domain jargon (ERC-8468, bindings), which costs some readability but not length.

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

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

An output schema exists, so the description need not explain return values, and the safety profile is fully covered by annotations. What remains missing is routing context against the many sibling status/check tools and any indication of verdict provenance or freshness, which matters for a read of an externally sourced verdict.

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 parameter meaning. It does explain the default behavior when the address is omitted (the node's own account) and implies the address identifies a cell account, but it does not state what the address format is, whether it may reference an arbitrary remote account, or what happens when no verdict exists for the given address.

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 and operation: the ERC-8468 safety verdict on a cell account, with an explicit default target (the node's own account). It is a noun phrase rather than a verb, and it does not differentiate itself from nearby siblings like cell_status or kya_check, so an agent must infer which one answers a safety question versus a general cell-status or KYA question.

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 guidance, no when-not-to-use, and no named alternative. The only routing hint is the parenthetical default, which tells the agent what happens if the address is omitted but not why it would pick this tool over cell_status or kya_check.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description's contribution is limited to enumerating returned fields, and it says nothing about behavior for an unknown token, error handling, or why the tool is flagged open-world — a modest addition given annotations carry the main burden.

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 short sentence with no filler, front-loaded on the resource. It is structurally sound but so compressed that the leading word is 'One' rather than a verb, making it read as a data label more than a usable directive.

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 spending the entire description enumerating return fields (mdHash, packageHash, version, owner, URI, ARD record) is redundant, while the one thing only the description could clarify — the tokenId parameter and how to obtain it — goes unaddressed. For a lookup tool whose selection hinges on argument format, this is 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?

Schema description coverage is 0% on the single required parameter, so the description must supply its meaning. It only implies that tokenId refers to a 'skill token'; it never states the numeric-string format enforced by the pattern, nor where a token comes from. That is not enough compensation for the coverage gap.

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

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

The description identifies a specific resource: a single skill token's commitment data (mdHash, packageHash, version) plus owner, URI and ARD record. The word 'One' distinguishes it from the plural sibling skill_list without the agent needing to open either schema, though the phrasing is a noun fragment rather than a verb+resource statement of purpose.

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

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

There is no when-to-use guidance, no mention of skill_list as the listing alternative, and no stated precondition such as needing a token from another call. The only implicit cue is 'One skill token', which hints at single-item lookup but does not route 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?

Annotations already declare read-only, idempotent, non-destructive and open-world, so the bar is lower; the description nonetheless adds real behavioral context by disclosing that the cell's own tokens are verified against the chain while a third party's are reconstructed from Transfer events within a lookback window, which signals result completeness depends on that window. It stops short of stating rate limits, failure modes, or what happens if the lookback is too short.

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 economical sentence with no padding, but the colon-and-appositive fragment structure reads as an internal note rather than a front-loaded statement of what the tool does, forcing the reader to reconstruct the action.

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-value detail is not required, and annotations cover the safety profile. Still, for a two-parameter tool with zero schema descriptions, the definition leaves the default behavior of both optional parameters underspecified, which is a meaningful gap for an agent deciding how to call it.

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

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

Schema description coverage is 0%, so the description must carry the meaning, and it does explain the semantic role of both parameters (holder selects whose tokens; the lookback window bounds the Transfer-event scan). However, it never states the default when holder is omitted, that lookbackBlocks is measured in blocks and capped at 100000, or what happens to the window for the cell's own configuration path.

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 (skill tokens held by a holder) and distinguishes two derivation modes, but it is a noun-phrase fragment with no explicit verb, so the agent must infer that this is a listing/enumeration operation. It does help separate this tool from skill_inspect in spirit (list vs. inspect), though it never names that sibling.

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 only implied: including a holder means querying another holder's tokens via Transfer events, omitting it means reading the cell's own configuration. There is no statement of when to prefer this over skill_inspect, no note about prerequisites such as chain access, and no explicit instruction on defaulting behavior.

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, so the safety profile is covered. The description adds semantic framing ('the texts the cell acts under') but does not disclose whether the texts are static or mutable, whether access is gated, or how they are returned (the output schema covers the return shape).

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 no filler, and the content enumeration is front-loaded. The fragmentary noun-phrase construction is slightly harder to parse than an explicit verb phrase would be.

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

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

For a one-parameter lookup tool with rich annotations and an output schema, the description supplies the essential content vocabulary. It still omits which sibling tool to prefer for status versus content, leaving a small completeness 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?

Schema description coverage is 0%, so the description must compensate, and it largely does: its four listed texts map one-to-one onto the four enum values (foga-cell-v1, policy, compatibility-matrix, cell-config-schema). The mapping is positional rather than explicit, leaving minor ambiguity about which label binds to which enum string.

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 four concrete texts retrievable (safety spec, policy block, compatibility matrix, config schema), and pairs with the name/title 'spec_read' / 'Read a rule text' to convey the verb. However, the sentence itself is a noun phrase with no explicit verb, and it does not distinguish this tool from siblings like safety_status or docs_status.

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

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

The description gives no when-to-use or when-not-to-use guidance and never references an alternative such as safety_status or world_describe. An agent must infer from the document names alone which situations call for spec_read.

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 non-destructive behavior, so the description adds useful conditional context: the task document appears only when the task URI is a data: URI. It does not mention auth or rate limits, but the annotations carry the safety profile.

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 compact sentence with no wasted words. The parenthetical about data: URIs is dense, and the overall fragment structure is terse rather than fully readable, but it remains front-loaded.

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

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

An output schema exists, so return values need not be explained in detail. For a single-tender read tool, though, the description omits the meaning of tokenId and when to choose this tool over tender_list, leaving gaps.

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

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

The only parameter, tokenId, has 0% schema description coverage, and the description never explains that tokenId identifies the tender or what format it expects. It adds no meaning beyond the bare schema definition.

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 that it returns one tender's terms, acceptance authority, escrow, deadlines, task document, and submissions, which is specific to the single-tender resource. However, it is a noun phrase without a verb and does not name tender_list as the alternative, so sibling differentiation is only 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?

There is no explicit when-to-use guidance, prerequisites, or comparison with tender_list or tender_precheck_simulate. The phrase 'One tender's' only weakly implies it is used after a tender is known.

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 safety (readOnly, idempotent, non-destructive, openWorld), and the description adds genuine context beyond them: the event source it indexes, the newest-first ordering, and the precise definition of the default filter (funded, not cancelled, completions remaining, deadline not passed). It does not state the default lookback size or any pagination/cursor 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?

A single dense sentence with the scoping and ordering facts front-loaded and no filler. The nested parenthetical of four open-condition criteria is compact but slightly heavy for one pass.

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 explained, and annotations cover safety. However, for a list tool with an undocumented limit and lookbackBlocks, the description should mention paging and the default window size; those omissions leave an agent guessing at result volume.

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, so the description must carry all parameter meaning and does not. It obliquely defines what includeClosed toggles and hints at lookbackBlocks via 'lookback window', but never names the parameters, states the default lookback, or explains the limit cap of 200.

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 (tenders), its origin (ERC-8414 TaskUpdated events), the scope (lookback window) and ordering (newest first), so an agent can tell this is a browse-style listing distinct from the sibling tender_inspect. It stops short of an explicit verb like "list", relying on the name for that.

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 only implied: the default open-only filter makes it read as a 'browse currently actionable tenders' tool, from which an agent can infer tender_inspect should be used for a single item. There is no explicit when-to-use or when-not-to-use statement, and no sibling is named as an alternative.

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

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

Annotations say readOnlyHint=false and openWorldHint=true, and the description usefully explains why: it writes a decision record but 'sends nothing', so no external action occurs despite being non-read-only. Listing the concrete checks performed adds real behavioral context beyond the structured hints. It could still say whether failed gates raise errors or are recorded as decisions.

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 gate list is front-loaded and informative, but the second and third sentences duplicate each other almost verbatim ('Writes a decision record; sends nothing' vs 'a decision record, nothing sent'). Roughly a third of the text is redundant restatement.

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, and the annotations plus the 'sends nothing / writes a record' note cover the safety profile. The remaining gap is the undocumented tokenId and the absence of any guidance on what a failed pre-check produces.

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 sole parameter tokenId is undocumented in both schema and description. The description never explains what the token identifies (the tender/cell being pre-checked) or its format, 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 enumerates the gates checked (anchor, skill, policy, acceptance authority, hashlock, budget) and states it is a dry run that writes a decision record, so the intent is inferable. However, it never states a clean verb+resource (e.g. 'validates a tender take'), instead opening with a noun phrase, and it does not distinguish itself from siblings such as tender_inspect or tender_list.

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 'Every gate the cell passes before taking a tender' implies the usage moment (before accepting a tender) but gives no explicit when/when-not or alternative routing. An agent must infer that tender_inspect is for read-only inspection and this tool for preflight simulation.

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

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

The annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuine behavioral detail beyond them: it reveals the data source (a world file) and discloses that the doctor summary is included conditionally, only 'when a report sits next to the world file' — a non-obvious conditional field an agent would otherwise misread as always 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?

One compact sentence with the most important content (what world, which fields) front-loaded and no filler. It loses a point for being a bare fragment with no verb and for the slightly convoluted trailing clause about the report sitting next to the world file.

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 and annotations fully cover safety, so the description needn't explain return values; it nevertheless enumerates the key fields, which is helpful. What is missing for a tool in a crowded status/inspect family is any statement of how it relates to cell_status or docs_status, so an agent knows which one to reach for.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. The description correctly implies the call is scoped implicitly to the current cell rather than accepting an identifier, which is consistent with the empty 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 is a noun phrase that identifies the resource ('the world this cell lives in') and enumerates its contents (id, chain, network, contracts by id, bundle hash, doctor summary), so an agent can infer it returns the world record for the current cell. However, no verb states the action, and nothing distinguishes it from close siblings such as cell_status or docs_status, leaving the agent to guess at the boundary.

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 guidance and no mention of alternatives. The phrase 'the world this cell lives in' only weakly implies 'call this to learn about your environment', and an agent choosing between this and cell_status or safety_status gets no routing help at all.

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