agent-erc8004-bridge

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

Annotations already declare this is a non-readonly, non-idempotent, non-destructive, closed-world write. The description adds real value beyond that by saying the result is an unsigned, content-addressed, order-independent attestation — a materially different behavior from a signed on-chain write. However, it does not say what is persisted, what authorization or proof is required, or whether repeated calls create duplicate state.

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, front-loaded with the action and followed by the artifact it produces. No filler or 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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. Still, for a four-parameter write operation with zero schema documentation, the description leaves the parameter contract and any prerequisites unexplained.

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 four parameters, so the description must compensate and largely does not. 'fleet DID' and 'ERC-8004 identity' loosely map to fleet_did and the chain_id/token_id pair, but there is no explanation of the integer identifiers or of the optional proof_note.

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 two concrete resources: it binds a fleet DID to an ERC-8004 identity. The mention of producing a 'binding attestation' implicitly separates it from siblings like verify_attestation and export_attestation, though no sibling is named explicitly.

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

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

No when-to-use guidance, no preconditions (e.g. proof of DID control), and no pointer to alternatives such as verify_attestation or import_registration. The agent must infer all routing from the name and description 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds little beyond that: 'capabilities and input contract' gestures at return content, which the output schema already documents, and it says nothing about cost, latency, or when the capability listing might be stale.

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 eight-word sentence with no filler, and the subject of the return value is front-loaded. It is efficient, though its brevity edges toward under-specification rather than pure conciseness.

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

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

For a zero-parameter introspection tool with an output schema, the essentials are technically present, but the description omits the one thing an agent most needs: that this is the discovery/onboarding call to make before invoking the mutation and verification siblings. Against a nine-tool sibling set, that gap is meaningful.

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 burden and the baseline of 4 applies. Nothing in the description conflicts with the empty input 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 says it returns 'the bridge's capabilities and input contract', a coherent verb+resource statement, but it doesn't reconcile the name 'describe_agent' with 'the bridge', leaving slight ambiguity about what object is being described. It also never distinguishes the tool from siblings like resolve_agent or list_registrations, which an agent could plausibly pick instead.

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 stated prerequisites, and no named alternative. The phrase 'input contract' faintly implies it should be called before other tools, but that inference is left entirely to the reader 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?

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, but the description adds context those fields cannot carry: the payload is UNSIGNED (the caller must supply their own signer) and content-addressed. That 'your own signer' detail is the key behavioral fact an agent needs and is not derivable from the annotations.

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

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

A single front-loaded sentence with no filler; the key qualifier (UNSIGNED) appears early. The all-caps emphasis is slightly noisy but does not obstruct reading.

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 explanation is not required, and the read-only, idempotent nature is covered by annotations. However, for a tool whose two required, zero-documented parameters determine which registry entry is exported, leaving both unexplained is a real 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% for chain_id and token_id, and the description adds no meaning for either — it never says which chain the ERC-8004 registry must live on or whether token_id refers to the agent's identity token. With both required parameters fully undocumented in schema and prose, the description fails to compensate.

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

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

The description names a specific verb (export) and a concrete artifact: an UNSIGNED ERC-8004 Validation Registry-shaped payload derived from the agent's current trust score. That format detail distinguishes it from generic siblings like score_agent, but it never explicitly contrasts itself with export_validation_response or verify_attestation, which also deal with attestation-shaped payloads.

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: 'ready for YOUR OWN signer to anchor on-chain' suggests this is a pre-signing step, so an agent can infer it should be called before signing and anchoring. There is no explicit statement of when to prefer it over export_validation_response or verify_attestation, and no prerequisites are stated.

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

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses that the output is unsigned, that the bridge holds no keys, that nothing is written to chain, and the conditional logic that gates response 100. That is meaningful behavioral context an agent cannot infer from annotations. It stops short of describing failure behavior if the receipt fails re-verification.

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

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

Four dense sentences, front-loaded with what the tool builds and ending with the ownership boundary the caller must respect. There is no filler, though the ERC-8004/ORC v0.1 jargon makes it terse to the point of being cryptic for an unfamiliar agent.

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 no explanation, and the description covers the key facts an agent needs: what goes in, what the output is (unsigned args), who signs, and the gating condition for response 100. Given the rich structured data, this is sufficient.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it only partially does so: it defines the semantics of receipt (an ORC v0.1 Outcome Receipt) and implies replay_ok's role via 'your replay succeeded'. request_hash and response_uri get no explanation at all, and the nested receipt object (additionalProperties: true) has its internal shape entirely undocumented.

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

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

States a precise verb+resource: it builds UNSIGNED ERC-8004 Validation Registry validationResponse args from an Outcome Receipt (ORC v0.1). That phrasing cleanly separates it from sibling exporters like export_attestation and from verify_attestation, since it explicitly produces unsigned args rather than signing or submitting anything.

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 usage rule: response is set to 100 only when the bridge re-verifies the receipt AND your replay succeeded, and the caller must sign and submit with their own signer. What is missing is an explicit statement of when to pick this over export_attestation, which is the nearest sibling, but the operational context is otherwise clear.

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 does add real behavioral content beyond the annotations — the per-item field spec, ISO-8601 timestamps, and the bool|0..1 value domain. However, 'Idempotent per feedback_id' conflicts with the supplied idempotentHint=false; an agent that reads the annotations and the description together gets two different answers about whether re-submitting the same arguments has additional effects, and nothing is said about permissions, batch limits, or partial-failure behavior on invalid items.

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

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

Three short lines, front-loaded with the operation and resource, then the payload contract, then the one caveat. No filler; the inline object notation is an efficient way to convey the item schema.

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 the item payload is well covered. What is missing for a three-required-parameter mutation is the meaning of chain_id/token_id, authorization requirements, and behavior on malformed or partially valid batches — meaningful gaps for an import tool.

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

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

Schema description coverage is 0%, so the description has to compensate, and it does partially: the 'feedback' array item shape (value, at, source?, weight?, feedback_id?) is documented in detail and is the most complex parameter. But chain_id and token_id receive no explanation at all — an agent cannot tell from either schema or description what registry/token these identify or what values are valid.

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

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

The description names a specific verb and resource — 'Import ERC-8004 Reputation Registry feedback records for an agent' — which is far more precise than the title 'Import feedback'. It is distinguishable from sibling writers like import_registration by the 'feedback records' resource, though it never explicitly contrasts itself with 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?

There is no when-to-use guidance: no statement of prerequisites (identity binding, chain/token ownership), no mention of when to prefer import_registration or score_agent, and no note on whether this is a one-time backfill or a repeatable sync. The only usage-adjacent statement is the idempotency note, which is behavioral rather than routing guidance.

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

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

The description asserts 'Idempotent: re-import updates in place', while the annotations declare idempotentHint=false. This is a direct contradiction about the tool's repeat-call semantics and would mislead an agent deciding whether to retry or re-run the import. The otherwise useful disclosure of the returned bridge DID format does not offset the conflict.

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

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

Three tight sentences, front-loaded with the resource identity before the idempotency and return-value notes; nothing is padded. Minor deduction because one of those sentences is actively misleading rather than earning its place.

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

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

An output schema exists, so spelling out the returned record and DID format is optional rather than required. For a mutating import tool with no annotation coverage of permissions or overwrite scope, the description leaves the 'metadata' parameter and any auth/prerequisite requirements unaddressed, and its idempotency claim conflicts with structured data.

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 burden, and it does add domain meaning by tying token_id to ERC-721 and chain_id to the registry chain. But 'metadata' (a fifth parameter with a null default) is never mentioned, and there is no format or constraint guidance for agentURI or owner.

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 (import an ERC-8004 Identity Registry record) and enumerates the identifying fields (chain_id, ERC-721 token_id, agentURI, owner), which is far more specific than the bare name 'import_registration'. It does not explicitly contrast itself with siblings such as bind_identity or list_registrations, so an agent must infer placement in the workflow.

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 're-import updates in place' implicitly tells the caller that repeated imports are safe to perform rather than needing a pre-check, which is a useful usage cue. However, there is no explicit when-to-use/when-not-to-use guidance and no mention of the sibling tools (bind_identity, list_registrations) that an agent might otherwise pick.

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, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered by structured data. The description's only added behavioral detail is that results are limited to registrations that have already been imported, which is useful but thin. It says nothing about ordering, volume, or whether the list can be empty.

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 short sentence with no filler, and the scope qualifier ("imported") is placed before the resource noun so the constraint is read first. Nothing is redundant with the title beyond the unavoidable verb-resource pairing.

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 parameters, an output schema present, and annotations covering safety, the definition needs little more. The remaining gap is minor: it does not indicate whether results are paginated or bounded, which an agent managing large registration sets might want to know.

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 explain and the baseline for an argument-free tool applies. The description correctly signals that no filtering input is expected.

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 pairs a specific verb ("List") with a specific resource ("imported ERC-8004 registrations"), so an agent can tell this is a retrieval operation over previously imported records rather than an import action. It does not explicitly contrast itself with sibling tools such as import_registration or describe_agent, which keeps it short of a 5.

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

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

There is no when-to-use or when-not-to-use guidance, and no named alternative among the siblings (import_registration, resolve_agent, describe_agent). The word "imported" hints at scope but does not tell the agent when to choose this listing over resolving or describing an 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 readOnly, idempotent, non-destructive, and closed-world behavior, so the bar is lower. The description adds only the 'imported' precondition, which is genuinely useful context, but says nothing about failure modes or lookup precedence, and an output schema covers return values.

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: verb, resource, and both lookup forms in one breath. Nothing is wasted.

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

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

For a simple lookup tool with full annotation coverage and an output schema, this is nearly sufficient. The remaining gaps are edge behavior: what a miss returns and which key wins when several are provided.

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 all three parameters are optional, so the description carries the burden. It adds real meaning by grouping chain_id with token_id as a pair versus bridge_did as a standalone key — information the flat schema does not convey.

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 ('Resolve') and resource ('imported ERC-8004 registration'), and names the two lookup keys. It is clearly distinct from siblings like list_registrations or describe_agent, though it does not explicitly name an alternative tool.

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?

'by bridge DID or by (chain_id, token_id)' implies the two mutually exclusive lookup modes, and 'imported' hints that the registration must already exist via import_registration. However, it never states precedence when both forms are supplied, nor what happens on a miss.

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

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

The description adds highly specific, valuable behavioral context that is not in the annotations, such as defining the decay mechanism and the neutral 0.5 prior for new feedback.

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 single sentence is concise and efficient, but its density packs a complex formula into a way that lacks immediate readability or logical breaks.

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?

While it is highly complete regarding the calculation methodology, it is entirely incomplete regarding the use case and the meaning of the input parameters.

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?

Context signals indicate 0% schema description coverage, and the description adds no semantic meaning or context to the required input parameters like chain_id or bridge_did.

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 defines the output as a 'decay-weighted trust score' and a 'tier,' but fails to state the high-level business purpose or what the score actually represents to the user.

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 definition provides zero guidance on when or why an agent should invoke this tool over siblings like describe_agent or verify_attestation.

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, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds that the operation recomputes a hash rather than trusting a stored value, which is meaningful behavior beyond the annotations, but it does not say what happens on mismatch or what 'intact' is judged against.

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 or redundancy. It is efficient, though its terseness contributes to the gaps in the other dimensions rather than reflecting deliberate compression.

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 need not explain return values. But for a tool taking an arbitrary nested payload object with no documented structure, the definition leaves too much unstated — notably the hashing basis and mismatch behavior — to be considered complete.

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

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

There is one required parameter, 'payload', an open nested object with additionalProperties=true and zero schema description coverage. The description only implies the payload is hashed; it gives no indication of expected shape, which fields participate in the hash, or how extra properties are treated, so it fails to compensate for the schema 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 states a specific verb and resource pair — recomputing a payload's content hash and reporting intactness — which is concrete and actionable. However, it does not differentiate itself from the sibling export_attestation, which an agent could plausibly confuse with verification work.

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

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

There is no guidance on when to call this versus export_attestation or export_validation_response, nor any stated preconditions (e.g. the payload must come from an attestation already exported). The agent must infer the entire trigger condition from the name alone.

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