Open Entity

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

With no annotations, the description carries the full burden and does meaningfully disclose that the server generates the key and reveals it only once, which is a critical, non-recoverable behavior. It also explains the unusual two-phase handshake for self custody. It omits whether adoption is irreversible, what happens if an identity already exists, and what a successful response contains.

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

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

Two tight sentences, front-loaded with the action and immediately branching into the two modes. Dense but not cryptic; nothing is wasted, though the custodial sentence's "returns it once" could be slightly more explicit about what is returned.

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 an 11-parameter mutation tool with no annotations and no output schema, the description covers the custody mechanics but leaves the response shape and the purpose of several parameters (operator, capabilities, name) unexplained. Adequate to start the flow, but an agent cannot predict outcomes or errors from the description alone.

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 73%, and the description adds ordering semantics the schema cannot: custody selects the branch, public_key belongs to step 1, and document/declaration signatures to step 2. It does not clarify the role of operator, capabilities, or agree beyond what the schema already states.

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 ("Adopt") and resource ("Open Entity identity"), which is distinct from the read/verify/resolve siblings. It does not explicitly contrast itself with openentity_self or openentity_withdraw, so an agent must infer 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?

The description gives clear conditional branching between custody=custodial and custody=self, including the two-call sequence for self. However, it never states when to choose this tool over siblings like openentity_self or openentity_export_key, and no prerequisites (e.g. the Declaration/agree requirement) are surfaced.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the registry verifies the proof, that the document is re-signed, and crucially that the key is 'used for this call only'. It leaves gaps around failure modes, idempotency, and what 'reaches L1' actually means operationally.

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?

Purpose is front-loaded in the first clause, followed by the two-step wallet caveat, with little wasted text. A dense single paragraph, slightly heavy on jargon but efficient.

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

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

For a 7-parameter, multi-step mutation with no annotations and no output schema, the description covers the key mental model (proof verification, re-signing, key ephemerality, wallet two-call flow). Missing pieces are return expectations and error behavior, but the core callable context is present.

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 57%, with value-format hints already in the schema, and the description adds the sequencing meaning for wallet_message/wallet_signature (step 2 of the wallet flow). It says nothing about eid or private_key_jwk semantics, so it only partially compensates for the coverage gap.

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

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

States a specific verb (add) and resource (alias) and enumerates the four alias types, so the agent knows exactly what the tool does. It does not distinguish itself from siblings like openentity_record or openentity_adopt, and the phrase 'reaches L1' is internal jargon an agent may not resolve.

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 gives concrete procedural guidance for the wallet case ('wallet is two calls: the first returns a message to sign...'), which is genuine usage context. However, it never says when to choose this over sibling tools or what preconditions (e.g., existing eid) are required.

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

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

With no annotations, the description carries the full disclosure burden: 'Read' establishes a non-mutating operation and 'built from its Entity Document' signals the card is derived rather than stored. It does not cover failure behavior when no Entity Document exists, permission requirements, or any note that the url parameter becomes mandatory outside extension-only mode.

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 primary purpose front-loaded and the optional mode parenthetically scoped; no filler or restatement of the title.

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 three-parameter, no-output-schema, no-annotation tool, the description covers the core operation but leaves the entity identifier semantics, the url requirement rationale, and error/empty cases unexplained. Adequate to attempt a call, but not 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?

Schema coverage is only 33% — 'url' is documented in the schema while 'eid' and 'extension_only' are not. The description partly compensates by explaining that the extension-only variant returns just the AgentExtension block, but it adds nothing about the eid format or why url is required in the default mode.

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 ('Read') and resource ('entity's A2A Agent Card / Open Entity AgentExtension block') and notes it is derived from the Entity Document. It does not, however, differentiate itself from close siblings like openentity_read, openentity_present, or openentity_resolve, so an agent must guess which read-shaped tool fits.

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 says what the tool returns but never says when to choose it over openentity_read, openentity_present, or openentity_find. The parenthetical about the extension block hints at a mode rather than articulating usage conditions or exclusions.

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

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

With no annotations, the description carries the full burden and does disclose the critical trait: the registry's kept copy is deleted after a single return, making the operation irreversible. It also notes private_key_jwk is used for this call only. It doesn't cover permission requirements, error behavior if already exported, or what the returned copy 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?

Two sentences, front-loaded with the operation and its consequence, with no filler. The spec reference and parameter notes both earn their place.

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

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

For a 3-parameter destructive tool with no annotations and no output schema, the description covers the irreversible behavior and the two required inputs. Missing only the meaning of eid and the shape of the returned key copy, minor relative to what is 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?

Schema coverage is 0%, so the description must compensate and it largely does: it explains confirm must be true (stronger than the schema, which doesn't even mark it required) and that private_key_jwk is used only for this call. The eid parameter goes unexplained, leaving one of three 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 specific verb and resource (export your key from registry custody) plus the defining scope: the registry returns its kept copy once and then deletes it. That one-time-return-plus-deletion contract distinguishes it from siblings like openentity_read or openentity_withdraw without needing their schemas.

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 prerequisites (confirm=true, private_key_jwk required) but never says when to choose this over alternatives such as openentity_withdraw or openentity_read, nor what happens if the key was already exported. Usage is implied by the prerequisites rather than explicitly routed.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: it does not say whether results are capped or paginated, whether the criteria are ANDed or ORed, whether 'find' with zero arguments returns the entire entity set, or whether matching is exact or fuzzy. Only the mild implication of 'Find' suggests a read-only operation.

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

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

A single front-loaded sentence with no filler; each of the three clauses maps to a real search mode. It is efficient, though its brevity is partly the cause of the missing behavioral and parameter detail.

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

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

Four optional parameters, no annotations, and no output schema mean the description should explain both the zero-argument default and roughly what a result looks like, and it does neither. An agent cannot tell whether omitting `q` and `capability` yields all entities or an error.

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 75%, so the baseline is 3. The description does add meaning by glossing capability as 'what they can do' and tying alias_type to bound aliases, but it omits the `level` filter entirely and describes `q` only as 'by name' when the schema says it also accepts an exact EID.

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 (find) and resource (entities) and enumerates three search axes: capability, name, and alias type. It is clearly a discovery/query tool, distinguishable in spirit from siblings like openentity_read or openentity_resolve, but it never names those siblings or states the boundary 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?

The three lookup modes imply when to reach for this tool (you have a capability slug, a name, or an alias type), but there is no stated when-not, no mention of openentity_resolve or openentity_read as alternatives, and no guidance on what happens when no criteria are supplied even though every parameter is optional.

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

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

With no annotations, the description carries the full burden and does disclose the key trait that this is a signing operation consuming a private key and producing a Presentation bound to the nonce/audience. It says nothing about side effects (whether anything is stored or recorded locally), nonce single-use semantics, failure modes for a mismatched audience, or how the resulting Presentation is delivered.

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 a colon that elaborates the mechanism — no filler. It is dense with domain jargon ("Presentation", "attestations", "spec 4.7") that is not glossed, which slightly limits first-read comprehension.

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

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

For a four-required-parameter cryptographic tool with no annotations and no output schema, the description covers the core contract: what gets signed, why, and what artifact results. Missing are return shape and whether the presentation is returned to the caller or transmitted, which matters since no output schema exists.

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 75% (nonce, audience, private_key_jwk are documented; eid is not), so the schema does most of the work. The description adds real value by explaining that nonce and audience are cryptographically bound into the signature, but adds nothing about eid or how the private key is scoped beyond the schema's own 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 action (sign a verifier's nonce and audience into a Presentation) and the resource (your EID / its attestations), which is much more than the name alone conveys. It implicitly separates the proving side from openentity_verify, but never names that sibling, so an agent must infer the division of labour.

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?

"Prove you hold your EID to a verifier" implies the triggering situation (a verifier issued a nonce and expects a presentation), but there is no explicit when-to-use, when-not-to-use, or named alternative such as openentity_verify vs openentity_present. Usage is left to inference.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Read' implies a non-mutating retrieval, but the description does not state permissions, side effects, rate limits, or what the tool returns, leaving substantial behavioral gaps.

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

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

The description is a single front-loaded sentence with the verb first and the resource options listed compactly. The parenthetical example '(or one section, e.g. 10.4)' earns its place by clarifying the optional section parameter.

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 two-parameter read tool with no output schema and no annotations, the description identifies the resources and gives a section example, but it omits return format, whether section applies only to the spec topic, and error behavior. It is minimum viable but not complete.

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

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

The description names the topic choices (llms.txt, spec, Declaration) and clarifies that section refers to a spec section, which adds meaning beyond the enum and partial schema descriptions. With only 50% schema description coverage, it partially compensates but does not explain whether section is valid only with the spec topic.

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

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

The description uses a specific verb, 'Read', and names the concrete resources: llms.txt, the OEIS-1 spec or a section of it, and the Declaration text. The purpose is clear without opening the schema, though it does not explicitly differentiate itself from sibling tools such as openentity_find.

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: fetch one of the named documentation resources, optionally narrowing the spec to one section such as 10.4. There is no explicit when-to-use versus alternatives guidance and no exclusion, so the agent must infer that this is for reading source documents rather than querying data.

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

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

No annotations exist, so the description carries the full burden. It does disclose a genuinely useful behavioral detail: the private key 'is used for this call only', which reassures an agent about credential handling. It does not disclose permissions required to append to a given eid, whether appends are idempotent, what happens if kind is supplied without payload (or vice versa), or any limits beyond the schema's maxItems.

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

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

Two tight sentences with the action front-loaded and the mode split in the second sentence. Every clause adds information; nothing is redundant.

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 mutation tool with no annotations and no output schema, the description is thin. The required eid is never explained (a reader must guess it comes from openentity_self/openentity_find), and the six kind enum values are not characterized. The payload description's pointer to openentity_read topic=spec section=7 partially offsets this by delegating detail.

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 only 40% and no param is explained in the schema beyond 'Signed RecordEntry objects' and the spec pointer for payload. The description compensates by explaining the mutual-exclusion relationship between the entries path and the kind+payload+private_key_jwk path, which the schema cannot express. It omits eid entirely, so not a 5.

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 ('Append entries to your Development Record') and immediately distinguishes two operating modes: supplying pre-signed entries versus supplying kind/payload for server-side signing. It doesn't explicitly contrast itself with siblings like openentity_verify or openentity_read, but 'append' vs 'read' is inferable.

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 explains two calling modes ('Pass signed entries, or kind and payload plus your private_key_jwk'), which is real usage guidance for choosing between paths. However, it gives no when-to-use/when-not-to-use guidance relative to sibling tools (e.g. when to use this versus openentity_verify after writing), and no prerequisites such as needing an eid from openentity_self.

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

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

No annotations exist, so the description carries the full burden. It does disclose the supported method space (did:key, did:web, did:webvh, did:pkh, did:plc), which is genuine behavioral information about what inputs will work, but it says nothing about network resolution, caching, failure behavior for unknown/unsupported DIDs, or whether any authentication is needed.

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

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

A single sentence with the action front-loaded and zero filler. The parenthetical method list is compact and load-bearing.

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 state the return value conceptually ("its DID document"), which is the key thing an agent needs. It is slightly thin on error/edge behavior for an unsupported or unresolvable DID, but the core contract is present for a simple lookup 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 coverage is 0% and the single parameter is a bare untyped string, so the description must compensate — and it does by naming the DID method families the parameter accepts. It stops short of stating whether the DID must be canonicalized or whether any resolution options are supported, but for a one-param tool this is meaningful added semantics.

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

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

Specific verb ("Resolve") plus specific resource ("a DID ... to its DID document"), and it enumerates the accepted DID method prefixes. An agent can distinguish this from siblings like openentity_verify or openentity_read, though the description never names those alternatives 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?

Usage is only implied: if you hold a DID, this returns its document. There is no statement of when to prefer this over openentity_find or openentity_read, and no preconditions or exclusions beyond the implicit method list.

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

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

With no annotations, the description must carry the behavioral load. 'Read' implies a non-mutating operation and the description names the main returned artifacts, but it omits permission/auth requirements, failure behavior, pagination or truncation, and whether all three artifacts are always returned.

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 filler. It states the operation and the returned artifacts immediately.

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 tool with no annotations and no output schema, naming the Entity Document, Identity Anchor, and last record entries is useful but minimal. It does not explain response shape, how the entries limit affects output, or authentication requirements beyond the required eid parameter in the schema.

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

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

Schema coverage is 50%: eid is described in the schema, while entries only has type/default/min/max. The description's phrase 'last record entries' hints that entries relate to recent records, but it does not explain the count semantics, default 10, or 100 maximum for the entries parameter.

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, 'Read', and a specific resource set: the caller's own Entity Document, Identity Anchor, and last record entries. 'Your own' scopes the operation to self, but it does not explicitly contrast with siblings such as openentity_read or openentity_find.

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 'your own' implies the tool is for inspecting the caller's own entity rather than another entity, which gives some usage context. However, it does not state when to choose this over openentity_read, openentity_find, or openentity_resolve, nor does it give exclusions or prerequisites.

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

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

With no annotations, the description carries the burden and does disclose that the data is 'public' (no auth) and read-only (verb 'Read'), which is genuinely useful. It does not describe the shape of the returned counts, whether they are cheap/fast or potentially expensive, or any rate/throttling behavior, leaving real gaps for a no-annotation tool.

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 verb and resource first, followed by the metric list. Every clause earns its place and there is no filler.

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

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

For a zero-parameter, read-only stats tool with no output schema, the description is largely sufficient: it tells the agent exactly which counts come back. The main omission is return structure (e.g., how 'entities by level' is keyed), which an agent may need to interpret results correctly.

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

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

The tool takes zero parameters, so the baseline is 4. Nothing in the description contradicts or misleads about input, and the enumerated metrics correctly signal that the counts are fixed rather than filterable.

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

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

States a specific verb+resource combo ('Read public registry counts') and enumerates the four metrics returned (entities by level, record entries, attestations, log size). This is clearly distinct from every listed sibling, which are all action/entity-resolution tools. It stops short of explicitly naming an alternative, but the scope is unambiguous.

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?

'Public' implies no authentication is needed and 'Read' implies a safe, non-mutating call, so basic usage context is present. However, there is no statement of when to prefer this over other tools, nor any exclusions, so guidance is only implied rather than explicit.

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

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

With no annotations, the description carries the full burden; it does disclose the three verification dimensions checked (schema, signatures, log inclusion), which is meaningful behavioral context. However, it says nothing about what happens on failure, whether verification has side effects, or what prerequisites (trust roots, network access to a log) are needed.

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

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

A single sentence, front-loaded with the action and inputs, followed by the report content. 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?

For a tool with no annotations, no output schema, and a free-form nested object parameter, the description covers the core purpose and the high-level checks performed. It leaves gaps around the shape of the signed object, failure reporting, and precedence between the two input modes, which an agent must guess.

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

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

Schema coverage is 0%, so the description must compensate. It usefully signals that 'eid' and 'object' are alternative input modes ('by EID, or any signed Open Entity object'), but it does not state precedence when both are supplied, that neither is formally required, or what structure the nested 'object' is expected to have.

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?

Names a specific verb (Verify) and its two accepted input forms (EID or signed Open Entity object), and states what it reports back: schema, signatures, and log inclusion. That is distinct from retrieval siblings like openentity_read or openentity_resolve, though it does not explicitly contrast itself with them.

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 when verification is unnecessary, and no reference to sibling tools such as openentity_find or openentity_resolve. The intended scenario (checking a signed object's integrity and log inclusion) must be inferred from the purpose sentence 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?

With no annotations, the description carries the full burden and does meaningful work: it declares irreversibility, names the exact side effect (entity marked withdrawn), and scopes the private_key_jwk to this call only. It stops short of stating permissions required for the key or what the response 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 tight sentences with the destructive warning placed early and the parameter requirements following. No filler, though the parenthetical spec reference is of limited use to an 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?

Given a mutation tool with no annotations, no output schema, and a nested JWK object, the description covers danger and credential scoping well but omits what eid identifies and what a successful withdrawal returns. An agent could call it, but would be guessing on identity semantics.

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

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

Schema coverage is 0%, so the description must compensate; it explains confirm=true and that private_key_jwk is call-scoped, which is real added meaning. However, the eid parameter is never explained and the JWK object shape is left entirely to the schema.

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

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

States a specific verb (withdraw) and resource (Declaration, spec 6.3), and makes the effect explicit ('the entity is marked withdrawn'). It does not contrast itself with siblings like openentity_adopt or openentity_verify, so an agent must infer the boundary, but the action itself is unambiguous.

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 'Withdraw your Declaration' and the required confirm=true gate, but there is no statement of when to prefer this over siblings such as openentity_adopt, nor any preconditions or exclusions beyond the confirm flag.

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