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 add real behavioral value: keys must be generated and retained outside Proofable, only the public address is passed, and the same agentId must be reused on retries (idempotency hint). It omits what happens on duplicate agentId creation, whether the operation is reversible, and what a successful call returns.

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

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

Short, front-loaded, and every sentence carries information: default account, key handling, retry rule. The key-handling sentence is slightly compressed ('Optional separate account and controls') but nothing is padded.

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 annotations, no output schema, and an empty parameter schema, the description must do all the work. It covers key custody and retry identity well, but leaves the import-vs-create branch and the channel for supplying the public address/agentId 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?

The schema declares zero properties, so there is nothing formal to document; per the baseline that would be a 4. But the description references input values ('pass only its public address', 'same agentId') that have no corresponding schema fields, leaving the agent unsure how or where to supply them — a genuine ambiguity rather than added meaning.

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 ('Create or import an agent on your profile'), which distinguishes it from sibling tools like proofable_agent_link and proofable_agent_mount that act on existing agents. The 'create or import' duality is named but not disambiguated (what makes it an import vs. a create).

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?

'Default: signed-in account. Optional separate account and controls' implies when the separate-account path applies, and 'Keep the same agentId on retries' gives retry guidance. However, it never names alternatives or states exclusions (e.g., when to use agent_link instead), leaving selection largely inferred.

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 declares the read-only nature explicitly, and describes the two possible outcomes ('linked:true with the identity proof and active delegation, or link_required with the one next step'). It omits permissions/authentication requirements and error behavior, keeping it short of a 5.

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 sentences, each doing distinct work: what it does, how it responds, and what it does not do. The read-only constraint and the sibling redirect are front-loaded rather than buried.

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?

Good on the output side — with no output schema, the description still explains the two return shapes and key fields. But the mismatch between the stated inputs (agentWallet, agentId) and the empty input schema is a real gap an agent must resolve before it can call the tool 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 input schema has zero properties, yet the description says 'Given agentWallet (plus agentId when one account hosts several)', which names inputs that are not documented anywhere in the schema. This adds conceptual meaning but leaves the agent unsure how to actually supply those values, so it neither earns a high score nor is it useless.

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 ('Check whether an agent is set up to act for your profile') and adds a second concrete facet ('what it may currently do'). It is clearly distinguishable from siblings like proofable_verify or proofable_agent_create, which it explicitly positions itself away from.

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 both the when ('check whether an agent is set up...') and the when-not ('does not create, change, or remove anything'), and names the exact alternative tool (proofable_verify with agent-delegation) for the excluded case. Routing is unambiguous.

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 at all, the description bears the full behavioral burden, and it is silent on whether 'load ... into this project' mutates persistent state, whether it is idempotent, whether it requires prior authentication, and what happens if an agent is already mounted. 'Load' suggests a write-like side effect but nothing is confirmed.

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

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

A single front-loaded sentence with no filler, and the action verb leads. The trailing enumeration of abstract nouns is slightly vague but costs little space.

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

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

For a zero-parameter tool with no annotations and no output schema, the description would need to carry the return value, side effects, and idempotency story, and it delivers none of these. An agent knows roughly what the tool does but not what it gets back or what state it changes.

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 beyond the schema. Baseline of 4 applies; the enumeration of what gets loaded is a small extra, though it is not a 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?

Names a concrete verb ('Load') and enumerates the resources being loaded (agent identity, permissions, skills, context) into a target ('this project'). It differentiates by implication from siblings like proofable_agent_create and proofable_agent_link via the 'mount' framing, but the description never states how mounting differs from creating or linking an agent, so an agent cannot fully disambiguate with confidence.

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

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

There is no statement of when to call this versus proofable_agent_create or proofable_agent_link, and no prerequisites or preconditions are given. 'Into this project' hints at project scoping, but the agent must infer the rest from the tool name 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, non-destructive and closed-world, so the safety profile is fully covered by structured data. The description reinforces this with 'read-only context' and the once-after-sign-in cadence, but adds little beyond that; with an output schema present it needn't describe 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?

Two tight sentences: content first, invocation cadence second. No filler, no repetition of the schema or annotations.

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

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

A zero-param, read-only snapshot tool with a full output schema and complete annotation coverage needs only to say what it returns and when to call it, both of which are present. Only a hint about whether it is a prerequisite for other Proofable calls is absent.

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

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

There are zero parameters, so there is nothing for the description to disambiguate. Baseline for a no-argument tool applies.

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

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

States a specific verb and resource ('Return the signed-in Proofable profile') and enumerates the payload (proof index, agents, permissions, verifier summary), which is far more than a restatement of the title. It does not, however, explicitly distinguish itself from siblings that also surface this data, such as proofable_agents_list or proofable_verifiers_catalog.

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?

'Use once after sign-in' gives a genuine timing cue for invocation. It offers no exclusions or named alternatives, so an agent must infer that agents_list/verifiers_catalog are the scoped-down substitutes when only one slice is needed.

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 behavior, so the safety profile is covered. The description adds real value beyond that: the pass/fail (not records) return shape and the auth/session constraint that gates richer access. It stops short of describing rate limits or partial-failure behavior, but this is solid added context.

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

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

Three front-loaded sentences that answer the core question first, then qualify with auth context. Slightly dense in the middle sentence but no wasted 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?

With an output schema present, the description needn't explain return fields, and it caps its return-value discussion at the useful 'pass or fail, not records' distinction. Auth behavior for signed-in versus signed-out callers is covered, leaving little an agent needs that is missing.

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

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

Schema description coverage is 100%, so all seven parameters are already documented in the schema, including the 'omit wallet when signed in' rule the description repeats. The description adds no new parameter meaning beyond what the schema provides, matching the baseline for full coverage.

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 question the tool answers ('Does this wallet already have the required proofs?') and clarifies the output shape ('Returns pass or fail, not records'). It implicitly separates itself from proofable_proofs_get, but does not differentiate itself from the three actual siblings listed (context, verifiers_catalog, verify_or_guide).

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 a clear conditional: signed-out callers get this check, and reading proof bodies requires a signed-in session, which routes the agent to proofable_proofs_get. There is no explicit 'do not use when' for the other siblings, but the auth-based selection rule is 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?

With no annotations, the description carries the burden and discloses meaningful behavior: unfiltered calls return an index hint, scope=all pages metadata, include=content changes the response, and signed-in users can omit the identifier. It stops short of covering errors, pagination, or full return shapes, so it is not exhaustive.

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

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

The description is dense and front-loaded, starting with the primary read/search behavior and then adding edge cases. Every sentence contributes useful information, though the final sentence about omitting the identifier is somewhat terse without surrounding context.

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 the empty input schema, no annotations, and no output schema, the description does a reasonable job explaining behavioral variants and some parameter usage. It still leaves gaps around accepted value types, pagination, and exact return formats, which matter for an agent invoking a search-like read 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?

The description mentions key parameters such as qHash, scope, tags, verifier, text, include, and includeComments, which adds semantic value. However, the input schema lists zero properties, so these parameters are not formally defined and no types or defaults are available, creating a mismatch between description and 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 opens with a specific verb and resource: 'Read a proof by qHash or search proofs by scope, tags, verifier, or text.' This clearly distinguishes the tool's read/search role from sibling verification and mutation tools, although it does not explicitly name alternatives.

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 usage conditions: no filter returns an index hint, scope=all pages metadata, include=content retrieves proof bodies, and includeComments requires qHash. It also says to omit identifier when signed in. It lacks explicit when-not guidance or named alternatives, but the conditional behavior is well specified.

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

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

With no annotations, the description carries the behavioral burden well by disclosing that private visibility revokes public access and should be confirmed, and by stating the one-change-per-call constraint and permission requirement. It does not describe return values or failure behavior, but the safety-critical effects are surfaced.

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

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

The description is front-loaded with the primary update action, then adds important constraints and permission notes. It is dense but every sentence contributes useful operational information.

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

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

Given no annotations, no output schema, and an empty input schema, the description explains behavior and constraints but does not explain how an agent should pass the mentioned fields. It is adequate for understanding intent but incomplete for confident invocation.

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

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

The schema has zero parameters, so the baseline is 4. The description adds useful conceptual semantics for metadata, vote, and comment changes and names visibility enum values, though the empty input schema leaves ambiguity about how these fields are actually supplied.

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 and resource: update a proof, including title, tags, and visibility, or leave feedback. It clearly distinguishes owner metadata updates from voting/commenting, though it does not explicitly compare against sibling tools like proofable_proofs_get.

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 explicit usage rules: one kind of change per call, confirmation before making an already-shared proof private, owners may vote on their own proofs, and delegated agents need manage_proofs. The alternative paths (metadata/vote/comment) and safety condition are clearly 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?

With no annotations, the description carries the full burden and does meaningful work: it discloses that re-saving an alias replaces AND revokes the prior value (a destructive side effect an agent must know), and that only metadata is returned and the stored value is never readable back. It omits any permission/entitlement requirements or error behavior, which keeps it below a 5.

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 sentences, each earning its place: capability first, then the replace/revoke consequence, then the return-value contract. Nothing is repeated from the title or from structured fields.

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 mutation tool with no annotations and no output schema, the description covers the destructive side effect and the return contract well. What it does not cover is the mechanics of supplying inputs, which is especially problematic given the schema declares no parameters despite the description referencing an alias and a value.

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

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

The schema has zero declared properties, so the baseline would be 4, but the description repeatedly references an 'alias' and a secret 'value' that do not exist anywhere in the schema — a real mismatch the description does not resolve. It adds semantic meaning about alias identity (reuse replaces) but leaves the agent without any indication of how those inputs are supplied.

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 — 'Encrypt and save one secret in the Vault' — scoped to 'the signed-in profile', which is enough to distinguish it from proofable_secret_list and proofable_secret_revoke without opening any schema.

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 agent can infer this is the write path for storing a secret, and the alias-overwrite note hints at idempotency semantics. However, no sibling is named as an alternative, and there is no explicit statement about when to prefer create vs. revoke or how it relates to proofable_secret_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 carries the burden and does disclose one important behavioral fact: secret values are never returned, only metadata. It says nothing about scope (which workspace/user), ordering, pagination, or whether auth or elevated permission is required to enumerate secrets.

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; every clause earns its place by naming the resource, the returned fields, and the security constraint.

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 list tool with no output schema and no annotations, the description covers the essential: what comes back and what explicitly does not. Only the absence of scoping/ordering or auth context keeps it from full marks.

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 schema is trivially complete and there is no parameter meaning for the description to add. Baseline of 4 applies.

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 (list) and resource (saved secrets), and enumerates the fields returned: names, types, update times. It also names the boundary condition 'without exposing their values', which cleanly separates it from the write-oriented siblings proofable_secret_create and proofable_secret_revoke.

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 read-only framing and 'without exposing their values' clause imply when to reach for this tool versus creating or revoking secrets, but no alternative is named and no preconditions are stated. Usage is inferred rather than directed.

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 supplied, so the description carries the full burden; it does disclose the core effect (the secret becomes unusable), which is more than nothing for a mutation tool. It stays silent on irreversibility, whether revocation can be undone, permission requirements, and impact on proofs or verifiers already tied to the secret.

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

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

A single front-loaded sentence with no filler. It is not bloated, but it is also thin for a destructive operation, leaving obvious questions unanswered.

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

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

A destructive, zero-parameter mutation with no annotations and no output schema needs more: what identifies the target secret, whether the action is reversible, and what happens to dependent artifacts. None of that 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?

Zero parameters, so the baseline is 4 and the schema imposes no documentation burden. However, the description never explains how the target secret is identified (presumably from session/mount context), which is the one semantic ambiguity left in a zero-arg call.

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 (revoke) and resource (saved secret) plus the resulting effect ('can no longer be used'), so the agent knows exactly what operation this is. It does not distinguish itself from siblings like proofable_secret_create or proofable_secret_list, but the verb alone separates it from the other secret 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?

No guidance on when to revoke versus rotate, recreate, or list secrets, and no mention of prerequisites or when revocation is inappropriate. The agent must infer all routing decisions from the one-line purpose.

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

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

Annotations already declare this a safe, idempotent, read-only, closed-world lookup, so the safety profile is fully covered. The description adds that the payload includes per-check inputs and networks, which is useful content context, but says nothing about caching, refresh cadence, or whether the catalog is static.

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, front-loading the return content and its shape. Every clause earns 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?

A zero-parameter catalog with a full output schema and rich annotations is nearly self-describing; the description covers what the catalog contains. It could be marginally stronger by noting the catalog is the entry point for the verify workflow, but nothing an agent strictly needs is missing.

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

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

The tool takes zero parameters and schema coverage is 100%, so the baseline is 4. There is nothing for the description to disambiguate, and it correctly avoids inventing argument 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?

States a specific verb (return) and resource (supported check definitions, with the inputs and networks each requires), which distinguishes it from action-oriented siblings like proofable_verify and proofable_verify_submit. However, it never clarifies the relationship between 'check definitions' in the description and 'verifiers' in the name/title, leaving mild ambiguity about whether checks and verifiers are the same concept.

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 guidance, no prerequisites, and no named alternatives. An agent must infer on its own that this catalog is meant to be consulted before configuring verification, rather than, say, a runtime check like proofable_proofs_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?

With no annotations and no output schema, the description carries the full disclosure burden for what is clearly a mutation (creating a proof). It says nothing about required permissions, rate limits, whether a proof can be recreated or overwritten, or what the call returns on success/failure.

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 sentences, front-loaded with the action and followed by the routing rule. The wallet sentence is wasted given the empty schema, but there is no padding otherwise.

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 mutation tool with no annotations and no output schema, the description covers the primary path and the fallback path, which is the essential core. It leaves out what the created proof is, how it is identified afterward, and error/duplicate behavior, which an agent would want before calling.

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

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

The schema declares zero properties, yet the description instructs the agent to 'Omit the wallet' — a parameter that does not exist. Rather than clarifying parameters, this actively invites an agent to reason about or attempt a wallet argument that the schema will not accept.

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

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

The description gives a concrete verb and effect ('Create a proof') plus a scope qualifier ('directly for the signed-in account'), which is enough to separate it from proofable_verify_prepare/submit. It does not reconcile the mismatch between the name 'verify' and the described behavior 'create', but the description 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?

It states the default path (use this tool for the signed-in account) and explicitly routes to proofable_verify_prepare plus proofable_verify_submit when another signer is required. It omits the sibling proofable_verify_or_guide, which appears closely related, so the routing is clear but not exhaustive.

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 idempotentHint=true, destructiveHint=false, and openWorldHint=false, and the description usefully adds that no proof is created. But readOnlyHint=false signals some write side effect (likely session/state), and the schema note that `data` is 'Used only when a new Proof is needed' sits in tension with 'does not create a proof' — the description never resolves what actually gets written.

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 sentences, front-loaded with the core action and no filler; each sentence carries information (action, branching outcome, non-goal). Minor slack in the vague qualifier 'for the selected Proofable checks', but overall efficiently structured.

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 shapes need not be described, and the schema fully covers the six parameters including the nested `data` and `options` objects. Combined with two of three behavioral hints covered by annotations, the description is nearly complete; the only real gap is sibling routing within a crowded verify family.

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 100%, so all six parameters are documented in the schema itself (verifierIds sourcing from the catalog, chain as an optional network hint, walletAddress fallback to the signed-in account). The description adds no parameter-level meaning beyond that, which is the expected baseline when the schema does the heavy lifting.

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 ('Resolve a verification request for the selected Proofable checks') and clarifies the dual-mode behavior (return proofs or return the next step). It also adds a negative discriminator ('This tool does not create a proof'), but it never names the close siblings proofable_verify, proofable_verify_prepare, proofable_verify_submit, or proofable_proofs_check, so an agent must still infer the boundary from the description alone.

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

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

The branching sentence implies when the tool applies ('Returns current qualifying proofs when they exist; otherwise returns the single next step'), which is useful precondition context. However, with four verify-family siblings in the list there is no explicit routing guidance on when to pick this tool over proofable_verify_prepare or proofable_verify, and no stated 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 meaningful work: it enumerates the return payload (signing string, timestamp, chain, hosted fallback) and explicitly rules out submission and proof creation, so the agent knows this step has no side effects. It stops short of stating prerequisites (how checks are 'selected' with zero parameters) or any auth/session requirements.

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 action and the returned artifacts, with the non-mutating constraint last. No filler or repetition of the tool name.

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

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

The return contents are explained (which matters since there is no output schema) and the non-submission behavior is clear. However, with zero input parameters the description never explains where the 'selected Proofable checks' come from (presumably proofable_context) nor what the caller should do with the signing string next, leaving a real operational 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?

Zero parameters, so there is nothing to disambiguate; baseline 4 applies. The schema is empty and consistent with a no-arg prepare call.

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?

A specific verb (prepare) on a specific resource (a signature request over selected Proofable checks), plus an explicit statement of what it is not (not a submit, not a proof creation). An agent can place it relative to proofable_verify_submit and proofable_proofs_check without opening a schema.

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 negation 'does not submit the check or create a proof' suggests it is the pre-step to submission, but no sibling tool is named and no when/when-not condition is stated. Adequate for a small family of verify tools, but the agent must infer the sequencing.

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 safety-behavior burden. It discloses the key conditional mutation that a proof is created only when verification succeeds, but leaves failure behavior, authorization needs, and return handling unstated.

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 are used efficiently, with the action and prerequisite front-loaded. Every sentence adds useful information without repetition.

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 tool, the description gives the critical prepare-submit sequencing and the condition under which a proof is created. It still lacks detail on failure outcomes, return value, and sibling selection, which matters more because there are no annotations or output 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?

The schema has zero parameters, so the baseline is 4. The description mentions conceptual inputs such as wallet, checks, data, chain, timestamp, and signature, but there are no schema parameters for it to clarify.

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 action and resource ("Submit a signed Proofable check") and states its outcome ("Creates a proof"). It ties the required inputs to the prior prepare step, but does not explicitly call out how it differs from proofable_verify or proofable_verify_or_guide.

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 specifies the sequencing and prerequisites: reuse the wallet, checks, data, and chain from preparation and supply the returned timestamp and signature. It does not name when not to use it or which sibling to prefer outside the prepare-to-submit flow.

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