NEUS MCP

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

Annotations declare write, non-idempotent, non-destructive behavior, so the safety profile is covered structurally. The description adds genuinely non-obvious context the annotations cannot: the key must be created externally and only the public address submitted, and retries should reuse the same agentId. It omits what happens on an agentId collision and any authorization requirements beyond 'signed-in profile'.

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

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

Five short, front-loaded sentences with the purpose first and no filler. The telegraphic 'Default: signed-in account. Optional separate account and controls.' is compact but slightly clipped, and 'import an agent' is never explained, which costs a point.

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, return values need not be explained, and 100% schema coverage handles the 23 parameters. The description supplies the missing operational framing (external key custody, reuse of agentId) for what is clearly a multi-step provisioning call. Only conflict/error behavior on an existing agentId is left unaddressed.

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 100% across 23 parameters, so the schema already documents chain, preset, wallet, delegation, and spend fields in detail. The description largely restates the agentWallet semantics ('omit to use the signed-in profile') and the key-handling rule that the schema also states, adding little semantics beyond it. Baseline 3 applies when the schema carries the load.

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 — 'Create or import an agent on your profile' — so an agent immediately knows this is provisioning, not linking or mounting. It does not name or contrast with siblings like proofable_agent_link or proofable_agent_mount, so the boundary between 'create' and 'link/mount' must be inferred.

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 concrete operative guidance: default to the signed-in account, optionally use a separate account and controls, generate/retain the key outside Proofable and pass only the public address, and reuse the same agentId on retries. It stops short of explicit when-to-use-this-instead-of-a-sibling routing or any 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered by structured data. The description adds a useful caveat that a separate spend account also requires signed limits, but does not explain what a failed confirmation means, whether anything is mutated, or what is 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?

Two short sentences with the core purpose front-loaded and no filler. The second sentence is a little cryptic and loosely connected to the first, keeping it short of a 5.

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 spelled out. However, for a tool whose name implies linking, the description never clarifies whether it only verifies or also establishes the link, nor what an agent should do when confirmation fails.

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 agentId, principal and agentWallet are fully documented in the schema, including when agentId is required. The description adds no syntax, format, or conditional detail beyond that, so the baseline 3 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 (Confirm) and resource (the agent's linkage to your profile with identity and permissions). It is clear what the tool checks, though the name 'link' hints at a mutation while the verb 'Confirm' reads as a verification, and no sibling is named to disambiguate from proofable_agent_mount or proofable_agent_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?

There is no explicit when-to-use guidance or comparison to alternatives like proofable_agent_mount. The trailing sentence about a spend account needing signed limits gestures at a scenario but never states the condition that should make an agent pick this tool over a sibling.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the scope of what is loaded (identity, permissions, skills, context), which is useful, but says nothing about failure modes, required authorization, or what happens when the referenced agent cannot be resolved. With annotations doing the heavy lifting, a 3 is appropriate.

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 first and zero filler. It is tight, though arguably undersized for a five-parameter tool with a resolution/mount semantic.

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 and annotations exist, so return values and the safety profile need not be described. The remaining gap is selection guidance: the description does not explain that at least one of agentId/agentWallet must be supplied or how controllerWallet defaults, leaving the caller to reconstruct intent from 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 description coverage is 100%, so the schema already explains agentId, agentWallet, identityQHash, controllerWallet, and requiredResources. The description adds no parameter-level meaning, such as the interplay between agentId and agentWallet or how requiredResources is enforced. Baseline 3 applies when the schema carries the 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?

The description names a specific verb ('Load') and a concrete set of resources (agent identity, permissions, skills, context) plus the destination ('into this project'). However, it does not distinguish itself from siblings such as proofable_agent_create or proofable_agent_link, so an agent cannot tell from the text alone why it would mount rather than create or link an agent.

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

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

There is no when-to-use guidance, no prerequisites, and no reference to alternatives among the many agent/proof/secret siblings. The agent must infer from the name alone that this resolves an existing agent into the project rather than creating or linking one.

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 covered. The description adds real context beyond that: it handles both signed-in and offline modes and consolidates multiple lookups into one call. Nothing is contradicted, but no limits or failure behavior are mentioned.

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 with the imperative 'Start here' front-loaded, then the payload, then the mode handling. Every sentence carries information and none is padding.

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 values, and it still helpfully enumerates them. For a no-param bootstrap tool with annotations covering safety, the definition is essentially complete; the only soft spot is the unaddressed overlap with proofable_verifiers_catalog.

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 parameter semantics are not a concern and the baseline is 4. The description correctly implies no input is required to obtain context.

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 purpose: a bootstrap call that returns the signed-in profile, available verifiers, and a recommended workflow in a single call. This clearly distinguishes it from the agent/secret/proofs siblings. It does not, however, clarify how its 'available verifiers' output relates to the proofable_verifiers_catalog sibling, leaving a small ambiguity.

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?

'Start here' is an explicit routing instruction that tells the agent to call this first, and 'no separate profile tool needed' steers it away from hunting for a profile tool. There is no explicit when-not guidance or named alternative among the siblings, so it stops short of a 5.

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, so the safety bar is low. The description still adds value by clarifying the boolean/pass-fail semantics of the result and the signed-in-wallet fallback behavior, which are not encoded in 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?

Three short sentences, front-loaded with the core question and immediately followed by the disambiguation rule and the auth shortcut. 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?

With an output schema present, return-value detail is unnecessary, and the description covers purpose, the sibling alternative, and the signed-in default. It is essentially complete, though it says nothing about behavior when verifiers are not found or how minCount/requireAll interact with the pass/fail verdict.

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

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

Schema description coverage is 100%, so every parameter (gateId, handle, wallet, minCount, namespace, verifiers, requireAll) is already documented in the schema. The description's only parameter note ('Omit the wallet when signed in') restates the wallet schema description verbatim, adding no new 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 question ('Does this wallet already have the required proofs?') and clarifies the output nature ('Returns pass or fail, not records'), which separates it from the sibling that returns data. It explicitly names proofable_proofs_get as the contrasting read tool, so an agent can route correctly without opening either 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?

Gives an explicit alternative: 'To read proofs, use proofable_proofs_get.' It also supplies the condition for omitting a parameter ('Omit the wallet when signed in'), which is real when-to-use guidance tied to auth state.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context: an unfiltered call returns only an index hint, scope=all pages metadata, content requires a known qHash or narrowing filter, and filtered content pages are capped at source. The auth note ('omit identifier when signed in') further clarifies permission behavior.

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

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

Three tight sentences with zero filler, front-loading the primary read/search purpose before the modifier flags. The telegraphic phrasing is dense but each clause carries distinct 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?

With 17 parameters, no required fields, and an output schema present, the description does well to cover the main modes, authentication, and pagination behavior without needing to restate return values. Minor gaps remain for the undocumented traversal and depth 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?

Schema coverage is 82%, so most parameters are already documented. The description still adds value beyond that by explaining interplay: tags precedence over scope, include=content prerequisites, includeComments requiring qHash, and the scope=all behavior. A few parameters (depth, traverse, searchQuery) remain undocumented in both.

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 with both operating modes: 'Read a proof by qHash or search proofs by scope, tags, verifier, or text.' This clearly separates it from siblings like proofable_proofs_update and proofable_proofs_check, though it never names them 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?

Gives concrete conditional guidance: use include=content for bodies, includeComments with qHash for discussion, and omit identifier when signed in. It lacks explicit routing to alternative siblings (e.g., when to use proofs_update instead), but the when-to-use conditions for each mode are 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?

Annotations declare the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds real context beyond them: the single-change-per-call constraint, the ownership rule for voting, and the manage_proofs scope needed by delegated agents. It does not cover failure behavior when change kinds are mixed, but the additions are substantive.

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, front-loaded with the primary purpose and then the constraints; no filler or restatement of the tool name. The middle sentence packs two rules together but remains readable.

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 9-parameter multi-purpose mutation tool with an output schema, the description covers the variables an agent actually needs to choose: ownership, permission scope, and one-change-per-call. Return values are correctly left to the output schema; only edge-case error handling is unstated.

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 100%, so the baseline is 3, but the description adds a constraint the schema cannot express: which parameters may be combined in one call (metadata vs vote vs comment). It also restates the visibility enum values inline, which helps an agent orient before reading 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 and resource ("Update a proof you own") and enumerates the mutable fields (title, tags, visibility) plus the secondary capabilities (vote, comment). An agent can separate this from proofable_proofs_get 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?

Gives an explicit operational rule ("Send one kind of change per call: metadata, vote, or comment") and states who may act (owners on their own proofs; delegated agents need manage_proofs). It stops short of naming an alternative tool for any of the three change kinds, so it is clear context rather than full when/when-not routing.

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=false and destructiveHint=false, so the write nature is covered. The description adds genuinely useful behavioral context beyond that: the value is stored encrypted in a Vault and is never returned by tools, which sets correct expectations about read-back. It stops short of covering permissions, duplicate-alias behavior, or idempotency.

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

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

Two short sentences with no filler; the core action leads and the non-return behavior follows as the key caveat.

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 a full schema and an output schema present, the description needn't document parameters or return values, and it correctly adds the write-only caveat. It is nearly complete, missing only operational context such as auth requirements or what happens on alias collision.

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 alias, content, secretType, tags, and walletAddress are all documented in the schema itself. The description adds no parameter-level detail (e.g., the single/bundle/json distinction or alias rules), so the baseline 3 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 ('Store a secret ... as an encrypted Vault record') with a concrete example of what a secret is. It is clearly distinguishable from the sibling tools proofable_secret_list 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?

Usage is implied by the verb 'Store', and an agent can infer this is the tool for persisting new secrets rather than listing or revoking them. However, there is no explicit when-to-use guidance, no mention of prerequisites (e.g., needing a wallet/session), and no statement of when not to use it.

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

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

Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds a valuable security trait—that secret values are not exposed—which goes beyond the annotations and is important for a secrets listing 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?

The description is a single, front-loaded sentence with no wasted words. It efficiently states the operation, 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?

Given the rich annotations and full schema coverage, the description is largely complete for a simple list tool. It could mention pagination behavior or when to omit walletAddress, but those are covered by the schema, and an output schema exists to explain return values.

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 three parameters (limit, offset, walletAddress) are fully documented in the schema. The description adds no additional parameter meaning, making the baseline score of 3 appropriate.

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 (List) and resource (saved secret names, types, update times), clearly distinguishing it from the create/revoke siblings. However, it does not explicitly name an alternative or contrast with siblings, which would be needed for 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?

The purpose implies usage for viewing saved secrets, but there is no explicit guidance on when to use this tool versus alternatives like proofable_secret_create or proofable_secret_revoke. No exclusions or 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description usefully adds the consequence that the secret 'can no longer be used,' but it says nothing about irreversibility, whether revocation can be undone, or that repeated revokes may error (idempotentHint=false).

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 effect; no filler or redundant restatement of the 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?

Output schema exists and annotations cover the destructive safety profile, so the description need not explain return values. It conveys the operation and its consequence adequately for a two-parameter tool, though the permanence of revocation is left implicit.

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 both qHash and walletAddress are already documented in the schema. The description adds no format hints or clarification about the walletAddress fallback beyond what the schema states, so the baseline 3 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 ('Revoke a saved secret') plus the resulting effect ('so it can no longer be used'). It is clearly distinguishable from siblings like proofable_secret_create and proofable_secret_list, but it never names an alternative 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives or when-not-to-use this tool. The agent must infer the context entirely from the name.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds only the useful framing that this is the 'full' catalog versus the compact summary; it discloses nothing else behavioral, 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?

Two sentences, zero waste, with the catalog contents front-loaded before the routing guidance. 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?

For a parameterless, read-only lookup with annotations covering safety and an output schema covering the return shape, the description supplies exactly the missing piece: what the catalog contains and when to prefer it over the compact summary. Nothing needed to invoke it correctly 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?

The tool takes zero parameters, so the baseline is 4. There is no parameter syntax or format for the description 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 the specific resource (the full verifier catalog) and states its contents: supported networks and required inputs. It also distinguishes itself from the compact verifierSummary in proofable_context, so an agent can tell the two apart. It lacks an explicit verb, 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?

It gives a clear activation condition: use it when a verifier needs schema details beyond the compact verifierSummary in proofable_context. This implicitly routes the agent to proofable_context when the summary suffices, but it never states that exclusion outright.

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 destructive=true, non-idempotent and openWorld, so the safety profile is covered. The description adds useful flow context ('Signed-in ownership proofs finish here', 'Share a hosted link only when this tool returns one') but never explains the two-phase prepare/approve flow implied by the signature parameter, nor what a refresh overwrites.

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 short sentences, purpose front-loaded, no filler. 'Signed-in ownership proofs finish here' is slightly cryptic but carries flow 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?

Output schema exists so return values need no explanation, but for a destructive, openWorld, 7-param tool with nested objects, the description omits the prepare-then-sign two-step flow, what gets mutated, and any auth prerequisites beyond the signed-in note.

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 100%, so the schema documents all seven parameters thoroughly. The description only restates wallet omission ('Omit the wallet when signed in'), adding no syntax or format meaning beyond the schema — the baseline 3 for full coverage 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+resource ('Create or refresh a portable proof') with scope. It does not name or distinguish itself from close siblings like proofable_verify_or_guide or proofable_proofs_get, so sibling differentiation is left to inference.

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?

'After confirming that one is needed' implies a prior check but never names the checking tool (e.g. proofable_verify_or_guide). It gives conditional guidance on omitting the wallet and when to share a hosted link, but no explicit when-not or alternative routing.

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, closed-world. The description adds meaningful context beyond that: it discloses reuse behavior ('reuse a qualifying portable proof') and the specific condition under which a hosted link is produced. This goes past the safety profile the annotations cover.

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, front-loaded with the core behavior followed by routing conditions. Every sentence carries information, though the density makes it slightly hard to parse on first read.

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. For a complex tool with nested objects and six parameters, the description covers routing and key conditions adequately, leaving only minor ambiguity around the 'one next step' concept.

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 the baseline is 3. The description's 'omit the wallet when signed in' merely restates the walletAddress schema description. It adds no syntax, format, or inter-parameter details beyond what the schema already documents.

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 dual purpose: 'Reuse a qualifying portable proof or return the one next step needed to finish verification.' It distinguishes itself from sibling proofable_verify by routing signed-in ownership proofs there. The verb+resource is clear, though the hybrid 'reuse-or-guide' nature is slightly abstract and not tied to a single concrete resource.

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 conditions: omit the wallet when signed in, continue ownership proofs with proofable_verify, and a hosted link is returned only for outside login/payment/different account. It names the alternative tool and when it applies. Missing an explicit statement of when NOT to use this tool at all.

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