NEUS MCP

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

Annotations cover safety (readOnly=false, destructive=false) but do not say anything about key custody or retry behavior; the description adds the important operational constraint that private keys must be generated and retained outside Proofable with only the public address passed in. The retry guidance is valuable context given idempotentHint=false — it tells the agent which field makes repeated calls safe. Does not describe the response or the multi-step dedicated-account flow beyond a hint.

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 sentences, front-loaded with purpose and scope before the key-handling caveat and retry rule. No filler, though the sentences are telegraphic enough that some ("Optional separate account and controls") are ambiguous on their own.

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 23-parameter creation tool with a full output schema and complete param documentation, the description supplies the essential non-schema context: default identity, key custody, and retry identity. It omits any mention of the two-phase identityQHash import flow, which is the one workflow an agent is most likely to get wrong.

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 documents all 23 parameters in depth. The description's account/key sentence largely restates the agentWallet schema text rather than adding new semantics, and it says nothing about preset, capabilities, or the delegation* policy fields. 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?

The description gives a concrete verb+resource ("Create or import an agent on your profile") and states the default scope (signed-in account). But it never distinguishes this tool from sibling tools like proofable_agent_link or proofable_agent_mount — an agent can't tell from this text which of the agent-* tools to pick.

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 optional path applies, and "keep the same agentId on retries" gives a procedural rule. But there's no explicit when-to-use versus proofable_agent_link / proofable_agent_mount, and no prerequisites (e.g., that a dedicated account needs a prior proofable_verify step) stated up front.

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?

Adds useful context beyond annotations: it describes the two possible outcomes (linked:true vs link_required) and states it does not create, change, or remove anything, reinforcing the readOnly/non-destructive hints. This edges above baseline, though it slightly restates what readOnlyHint/destructiveHint already convey.

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

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

Three tight sentences, front-loading the purpose and following with inputs and the alternative. Mostly earns its space, with minor overlap between the outcome description and the 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?

Complete for a read-only check: annotations cover safety, an output schema exists, and the description supplies the decision outcomes and the redirect to proofable_verify. No further information is needed to call it 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?

Schema coverage is 100%, so the schema already documents all four parameters. The description restates the agentWallet/agentId conditional but adds no syntax, format, or edge-case detail beyond the schema, so 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+resource ('Check whether an agent is set up to act for your profile') and explicitly scopes what is reported (linked:true with identity proof and delegation, or link_required). It also distinguishes itself from proofable_verify, so the agent can pick it over siblings without opening 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 concrete usage conditions ('Given agentWallet, plus agentId when one account hosts several') and an explicit alternative with the condition that selects it: 'to grant or change authority, use proofable_verify with agent-delegation.' Nothing 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is documented. The description adds only that the mount is scoped 'into this project'; it says nothing about failure modes when requiredResources cannot be satisfied, or about the identity proof requirement behind identityQHash. The phrase 'into this project' mildly suggests state changes that the readOnly/idempotent annotations deny, though not enough to constitute a direct contradiction.

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 front-loaded sentence with no filler, easy to scan. It is terse relative to the tool's identity-resolution complexity, but 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?

An output schema and full annotation coverage reduce the burden, so the description does not need to explain return values. However, for a tool that resolves an on-chain identity proof and optional required resources, an agent still lacks enough context: what a 'resolved mount' means and what happens on failed resolution are 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 the schema already documents all five parameters. The description mentions none of them and does not surface the schema's implicit cross-field rule (agentWallet is required when agentId is omitted). Baseline 3 applies 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?

Names a concrete verb ('Load') and enumerates the resources being mounted (identity, permissions, skills, context), so an agent can grasp the operation. It never contrasts itself with near-siblings such as proofable_context, proofable_agent_link, or proofable_agents_list, 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?

The description gives no conditions for when to use this tool, no prerequisites (identity proof, signed-in profile), and no alternatives. Nothing tells the agent whether to mount first, or whether proofable_context or proofable_agent_link already covers the need.

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 closed-world scope, so the safety profile is covered. The description adds the useful constraint that the context is read-only and should be fetched once after sign-in, and signals the returned facets; it doesn't discuss auth failure behavior, which is a minor residual gap.

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 filler, with the payload description front-loaded and the usage cue second. Every clause carries 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 an output schema present, the description needn't explain return values, and it correctly summarizes them at a high level instead. Combined with rich annotations and a no-arg schema, this is nearly complete; only the signed-out/error case is 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?

The tool takes zero parameters, so the baseline is 4 and there is no parameter meaning the description could add or omit. Nothing about argument semantics is left ambiguous.

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 ('the signed-in Proofable profile and its current read-only context'), then enumerates the payload (proof index, agents, permissions, verifier summary). That enumeration also separates it from siblings like proofable_agents_list or proofable_proofs_check, which each return one slice.

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 an explicit timing cue and an implicit anti-pattern (don't poll it repeatedly), which is more than most definitions offer. It stops short of naming alternatives or when-not-to-call conditions, so it is clear context without full 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?

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses the auth model (signed-out access, signed-in unlock) and the result shape ('pass or fail, not records'), which is meaningful behavioral context. It could go further on what happens with gateId scoping, but the annotations and output schema already carry the safety and return-format burden.

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

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

The purpose and the pass/fail result constraint are front-loaded, and each sentence carries distinct information. The middle sentence about sessions and proofable_proofs_get is a bit convoluted, but nothing is 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 7-parameter tool with an output schema and full annotations, the description covers what an agent needs: the question it answers, the pass/fail result shape, and the auth gating. A minor gap is that 'pass or fail' does not align precisely with the schema note that signed-in owners get 'eligible + matchedCount', leaving the exact response shape slightly ambiguous.

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 is already documented in the schema, including 'Omit when signed in to use the current account.' The description's only added parameter guidance is the wallet-omission rule, which largely restates the schema. Baseline 3 applies 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?

The description states a concrete question the tool answers ('Does this wallet already have the required proofs?') and explicitly limits the output to pass/fail rather than records. It also distinguishes itself from sibling proofable_proofs_get by contrast (that one reads proof bodies). The framing is a question rather than a verb+resource phrase, which slightly weakens the top score.

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 routing guidance: signed-out callers should use this check, and reading actual proof bodies requires a signed-in session via proofable_proofs_get. It also notes 'Omit the wallet when signed in.' However, it does not mention other nearby verification siblings (proofable_verify, proofable_verify_or_guide, proofable_verifiers_catalog) that an agent might confuse with this 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 read-only, idempotent, non-destructive behavior, so the bar is lower, yet the description adds real context: the index-hint fallback with no filter, the metadata paging behavior of scope=all, the content-access constraint, and the auth shortcut of omitting identifier when signed in.

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

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

Four dense sentences, front-loaded with the primary read/search modes and followed by the parameter pairings that matter. No padding 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?

Covers the main retrieval paths, defaults, and auth behavior for a 16-parameter tool, and the output schema handles return values. However, graph traversal (traverse/depth) is a distinct capability completely absent from the description, leaving an agent dependent on the schema to discover it.

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

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

Schema coverage is 100%, so baseline is 3; the description adds value by explaining parameter interlock rather than definitions — includeComments requires qHash, include=content needs a known qHash or narrowing filter, and identifier may be omitted when signed in.

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 ('Read a proof by qHash or search proofs') and enumerates the alternative access modes (by scope, tags, verifier, text). An agent can distinguish this read/index tool from the mutating siblings (proofs_update, proof_revoke) without opening the 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 clear mode-selection guidance: no filter returns an index hint, scope=all pages metadata, include=content unlocks bodies, includeComments requires qHash, and identifier can be omitted when signed in. Strong internal routing, though it never explicitly contrasts with sibling tools like proofs_check or context.

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?

Goes well past the annotations (destructiveHint=true, idempotentHint=false): it names the concrete destructive consequence — setting visibility to private revokes public access — and adds an authorization constraint that only the owner's own session can change visibility, not a job run. It also states the mutual-exclusivity rule of one change kind per call, which is behavioral context no annotation provides.

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

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

Four dense sentences with no filler, front-loaded on the primary update action before the vote/comment modes. The mid-paragraph pivot to 'Or leave feedback on an accessible proof' slightly disrupts the flow and reads as an afterthought, but nothing is wasted.

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

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

For a 10-parameter, destructive, multi-mode mutation with an output schema and full schema coverage, the description supplies exactly the missing pieces: destructive consequence, permission gate, per-call exclusivity, and self-vote permission. Return values are covered by the output schema, so no further explanation is needed.

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; the description earns above that by adding semantics the schema lacks — that metadata, vote, and comment are mutually exclusive per call, and that owners may vote on their own proofs. It leaves disclosePortableProof, walletAddress, and parentId unmentioned, so it does not fully cover the 10-parameter surface.

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 (update) and resource (a proof you own) and enumerates the mutable fields: title, tags, visibility. It also discloses the secondary modes (vote, comment) that the same endpoint handles, so an agent knows this is a multi-purpose mutation rather than a pure metadata edit, distinguishing it from proofs_get and proof_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?

Gives concrete when-to guidance: confirm before making an already-shared proof private, send only one kind of change per call (metadata, vote, or comment), and delegated agents need manage_proofs. It never names a sibling alternative (e.g. proof_revoke for revocation), so it stops short of the top tier, but the exclusions and prerequisites are 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds that each entry carries its required inputs and networks, which is meaningful shape information, but says nothing about whether the catalog is static or dynamic or how large it is.

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

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

A single sentence with no filler, and the resource noun is front-loaded ahead of the returned detail. Nothing to trim.

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

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

An output schema exists, so the description need not explain return values, and there are no inputs to document. The only missing piece an agent would want is where this catalog fits in the verify workflow, which is a minor gap for such a simple 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 tool takes zero parameters, so the baseline is 4; there is nothing for the description to compensate for. It correctly implies the response is not filterable, which matches the empty schema.

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

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

States a specific verb ("Return") and resource ("supported check definitions" plus their inputs and networks), so the agent knows this is a discovery/catalog read. It is clear on its own, but it never names the sibling it feeds into (proofable_verify / proofable_verify_prepare), so the differentiation is left implicit.

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

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

Calling a zero-argument "catalog" immediately before a verify flow is strongly implied, but nothing is stated explicitly — no "use this before X", no when-not, and no mention of which sibling consumes the result. Usage is inferable rather than guided.

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 that this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds meaningful context beyond that: creation is tied to the signed-in account, wallet omission is allowed for self-verification, and multisigner cases must use the prepare/submit flow. It does not explain persistence or proof privacy here, but the schema covers privacy options.

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 primary action and followed by the two key routing rules. 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 mutation tool with rich schema descriptions, an output schema, and safety annotations, the description supplies the critical routing and account-context information an agent needs. Nothing essential is missing for correct 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?

Schema description coverage is 100%, so the schema already explains most parameters in detail. The description still adds a useful rule not stated in the walletAddress schema: omit the wallet when creating a proof for the signed-in account.

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 and resource ('Create a proof directly') plus an explicit account scope ('for the signed-in account'). It also distinguishes the direct path from the prepare/submit flow, so an agent can tell it apart from sibling verification tools without inspecting each 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?

It states when to use this tool directly and names the alternative when another signer is required: proofable_verify_prepare and proofable_verify_submit. It also tells the caller to omit the wallet for their own account, which is a useful selection rule.

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?

Adds real context beyond the annotations: it discloses the two-branch outcome (return existing qualifying proofs, otherwise a single next step) and explicitly scopes out proof creation, which matters given readOnlyHint=false suggests some state may change. The mild tension between the read-leaning description and readOnlyHint=false is not explained, keeping it from 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, zero padding, with the core action and the negative constraint both front-loaded.

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

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

With an output schema present and full schema coverage on all six parameters, the description carries only the job of explaining the outcome branches and the non-creation constraint, which it does. It stops just short of tying those branches back to specific parameters such as requireAll.

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 verifierIds, data, chain, options, requireAll, and walletAddress. The description adds no extra parameter meaning (e.g., how requireAll interacts with partial proofs), 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 ("resolve a verification request for the selected Proofable checks") and discloses the branch behavior of the result. The closing line "This tool does not create a proof" partially distinguishes it from the verify/verify_submit family, but no sibling is named explicitly.

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

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

Usage is implied by "resolve a verification request" and by the exclusion of proof creation, but there is no explicit guidance on when to pick this over proofable_verify, proofable_verify_prepare, or proofable_verify_submit, nor any 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds real value by enumerating the return payload (signing string, timestamp, chain, hosted fallback) and asserting no proof is created. It does not mention any auth/signing prerequisites, which is the remaining behavioral gap.

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 return shape and the explicit non-effect. Nothing redundant and 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 a full output schema and 100% parameter coverage, the description need not explain returns in depth and correctly doesn't. The only shortfall is the missing hand-off to the submit step, which an agent calling a two-phase sign flow would want spelled out.

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% and the nested options/meta and data fields are documented in detail in the schema itself, so the description adds no parameter-level meaning. Baseline 3 is appropriate when the schema carries the full burden.

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 ('Prepare a signature request for the selected Proofable checks') and immediately defines the boundary: it returns a signing string but 'does not submit the check or create a proof.' That negative scope cleanly separates it from proofable_verify / proofable_verify_submit without needing to name 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?

The 'does not submit' clause implies this is a pre-step to a submit call, so usage is inferable. But it never says explicitly when to choose this over proofable_verify, proofable_verify_or_guide, or proofable_verify_submit, nor what the agent should do with the returned signing string next.

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 that this is a non-readonly, open-world, non-idempotent, non-destructive operation. The description adds important behavior beyond that: proof creation is conditional on successful verification and requires the signature and timestamp returned from preparation.

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 two sentences, front-loaded with the action and followed by the key success condition. It contains no redundant or filler text.

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, full parameter descriptions, and annotations present, the description covers the essential submission semantics and success condition. It could be slightly stronger by explicitly naming proofable_verify_prepare as the required prior call and clarifying failure behavior.

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 most parameter meaning is already documented. The description still adds a critical relational constraint: wallet, checks, data, and chain must match what was used to prepare, and signature/signedTimestamp are the returned values from that step.

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: submit a signed Proofable check and create a proof on success. It clearly separates this from preparation by requiring the same wallet, checks, data, and chain used to prepare, plus the returned timestamp and signature.

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 clear context for use: this is the submission step that consumes values from the preparation step. It does not explicitly name proofable_verify_prepare as the prerequisite tool or state when to use proofable_verify instead, so it stops short of full when/when-not guidance.

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