NEUS MCP

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals the internal sequence (creating proofs, linking delegation), the wallet selection logic (generate only when asked, otherwise use signed-in user's wallet), and retry idempotency. It doesn't mention side effects like transaction costs or authority requirements, but it adds meaningful context beyond the schema.

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 four sentences, front-loaded with the main purpose. Every sentence adds value: the high-level action, the step-by-step process, the success condition, and retry guidance. No wasted words.

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 24 parameters, no output schema, and no annotations, the description is incomplete. It covers the high-level workflow but leaves out parameter details, return values, and edge cases. The retry guidance is helpful but insufficient for a tool with this complexity.

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 24 parameters with 0% description coverage, and the description does not explain any of them beyond mentioning agentId and agentWallet in the retry context. It gives no guidance on what 'scope', 'preset', 'skills', 'permissions', etc. mean or how to set them. This is a critical gap for such a parameter-heavy tool.

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

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

The description clearly states the tool's purpose: 'Create a Trusted Agent in one call' with a specific sequence of operations (pick wallet, create identity proof, create delegation proof, link delegation). It also distinguishes itself from siblings by noting that the agent is 'ready to mount' on success, implying a separate mounting step handled by neus_agent_mount.

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 provides clear context for when to use this tool: when creating an agent in one call, including retry guidance ('Keep the same agentId and agentWallet on retries') and the outcome ('ready to mount'). It does not explicitly name alternatives like neus_agent_link or neus_agent_mount, but the flow implies they are separate steps.

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 present, so the description must fully disclose behavior. It only states the core action (checking identity and permissions) and output, but does not mention side effects (e.g., whether it is read-only), required permissions, or any other behavioral traits. The description is non-committal about mutation or state changes.

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 sentence, making it concise. However, it is poorly structured: the core action and output are combined without clear separation, and key details (parameters, usage context) are omitted. It earns its place but does not optimize for quick scanning.

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 three parameters, no output schema, and multiple sibling tools with overlapping functionality, the description is incomplete. It fails to define 'linked status' or 'one setup step', explain how this tool differs from neus_proofs_check or neus_verify, or provide parameter context. The description covers only the most basic purpose.

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

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

Schema description coverage is 0%, and the tool description does not explain any of the three parameters (agentId, principal, agentWallet). With no guidance on what these fields represent or how they map to the 'Trusted Agent' concept, the agent cannot correctly populate the input schema.

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

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

The description uses the verb 'Check' and specifies the resource ('Trusted Agent' with 'identity and permission proofs'), clearly stating the action and expected output ('linked status or one setup step'). However, it does not differentiate from sibling tools like neus_proofs_check or neus_verify, which also involve checking proofs.

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

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

There is no guidance on when to use this tool versus alternatives such as neus_proofs_check or neus_verify. No prerequisites, exclusions, or context for usage are provided, leaving the agent to guess the appropriate scenario.

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

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

With no annotations, the description must disclose behavioral traits. It mentions what is loaded (identity, permissions, skills, settings) but does not indicate whether the operation is read-only, has side effects, requires authentication, or what happens to the current 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?

The description is a single, front-loaded sentence with no wasted words. It is concise, though the brevity contributes to vagueness.

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 tool has 4 undocumented parameters, no output schema, no annotations, and a rich set of sibling tools, the description is insufficient. It lacks information about return values, prerequisites, side effects, and how it relates to other tools.

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

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

Schema description coverage is 0%, and the description does not mention any of the four parameters (agentId, agentWallet, identityQHash, controllerWallet). Thus it adds no meaning beyond the bare property names in 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?

The description clearly states what the tool does: it loads a Trusted Agent's identity, permissions, skills, and settings to connect agent context. The verb 'connect' and resource 'agent context' are specific, though it does not explicitly differentiate from sibling tools like neus_agent_link.

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 is provided for when to use this tool versus alternatives such as neus_agent_link or neus_context. The description implies a use case (loading agent context) but offers no exclusions or explicit conditions.

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 provided, the description carries full burden for behavioral disclosure. It reveals the tool returns data (profile, verifiers, workflow) and handles two modes. However, it does not state whether it is read-only, idempotent, or has any side effects, which is a gap for a tool that likely has no destructive 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?

The description is two sentences, contains zero wasted words, and front-loads the critical 'Start here' directive. Every sentence adds value: the first states purpose and distinguishes from a profile tool, the second clarifies mode handling. Excellent conciseness.

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

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

Given the tool has no parameters, no output schema, and missing annotations, the description provides the essential information: what it returns and its role as an entry point. It could mention idempotency or that it is safe to call multiple times, but overall it is sufficiently complete for a simple context 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 input schema has zero parameters, so schema coverage is trivially 100%. Per guidelines, 0 parameters earns a baseline of 4. The description does not need to add parameter details, and it correctly focuses on what the tool returns rather than extraneous parameter info.

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

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

The description clearly states the tool's function: 'Returns the signed-in profile, available verifiers, and the recommended workflow in one call.' It also explicitly positions it as the starting point ('Start here') and distinguishes it from any separate profile tool, making its purpose unambiguous and differentiated from sibling 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?

The description explicitly says 'Start here,' which is strong guidance that this should be the first call. It also notes that it handles both signed-in and offline modes, implying it is the universal entry point. However, it does not explicitly state when not to use it or list alternatives, though the sibling tools have distinct functions (agents, proofs, secrets) making this less necessary.

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

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

With no annotations, the description carries the full burden. It discloses the read-only nature ('never creates a proof') and gives a behavioral instruction about the wallet parameter. However, it does not describe return values, error handling, or what happens when no proofs match. The transparency is minimal but not contradictory.

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 main purpose, then a read-only clarification and a practical usage hint. Every sentence earns its place with no fluff or 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?

Given the tool has 7 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain the meaning of most parameters, the return value, or edge cases. The description covers only the basic purpose and a couple of behavioral notes, leaving significant gaps for an agent to correctly invoke the tool.

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

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

Schema description coverage is 0%, so the description must compensate. It only hints at the wallet parameter ('Omit the wallet when signed in') and generally refers to 'requirements', likely mapping to verifiers, but it does not explain minCount, requireAll, namespace, handle, or gateId. The description adds minimal value beyond the schema and fails to clarify the purpose of most parameters.

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

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

The description clearly states the tool checks existing portable proofs against requirements, using the verb 'check' on the resource 'existing portable proofs'. It explicitly notes it is read-only, distinguishing it from sibling tools like neus_verify_or_guide that might create proofs. The mention of 'requirements' implies the verifiers parameter without naming it, and the scope is precise.

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 provides one specific guideline: 'Omit the wallet when signed in', but does not explicitly state when to use this tool versus alternatives like neus_verify or neus_proofs_get, nor when not to use it. The context is implied from the purpose (checking existing proofs) but not clearly articulated. No exclusions are given.

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 transparency burden. It does disclose that the operation is a read and that results are 'current', implying a non-mutating, snapshot-like behavior. However, it does not mention auth requirements, pagination behavior, or any side effects or limitations beyond the 'omit wallet' tip.

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 sentence with a front-loaded verb and resource, followed by a short usage tip. Every word earns its place; there is no redundancy or 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?

Given the high complexity (16 parameters, no annotations, no output schema), the one-sentence description is not enough. It mentions output fields but does not explain the meaning of most parameters, traversal options, return structure, or behavior under different scopes. Significant gaps remain for an agent to invoke this 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 schema has 16 parameters with 0% description coverage, and the description adds no parameter-level meaning. 'Wallet or DID' loosely maps to possible identity parameters but does not explain q, tags, limit, offset, include, traverse, identifier, verifierId, searchQuery, or any other field. This is a major gap given the very low schema 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 uses a specific verb ('Read') with a clear resource ('current portable proof details') and scope ('for a wallet or DID'), then lists included fields (titles, tags, status, content). This clearly differentiates the tool from siblings like neus_proofs_check or neus_verify, which imply validation rather than reading details.

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

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

The phrase 'Omit the wallet when signed in' gives a concrete invocation guideline tied to authentication context. However, it does not explicitly state when to choose this tool over siblings like neus_proofs_check or neus_verify, so it falls 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.

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals that the tool stores secrets encrypted and that tools never return the saved value, which is useful context about response semantics. However, it omits other behavior such as handling of duplicate aliases, potential overwrites, or required permissions.

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 consists of two concise, front-loaded sentences with no fluff. Both the primary purpose and a key behavioral caveat are expressed efficiently.

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 5-parameter tool with no annotations or output schema requires a more thorough description. The current text only addresses basic functionality and one security property, leaving parameter semantics and operational edge cases 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 description coverage is 0%, and the description adds no parameter-level meaning. It only vaguely suggests that content might be an API key, but fails to explain walletAddress, alias, secretType, or tags. This is a critical gap given three required parameters.

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

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

The description clearly states a specific action ('Store a secret') and resource ('as an encrypted record'), distinguishing from sibling tools like neus_secret_list and neus_secret_revoke through the 'create' verb.

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 is provided on when to use this tool versus alternatives. There is no mention of using neus_secret_list for viewing or neus_secret_revoke for invalidation, leaving the agent to infer usage from the tool 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?

With no annotations provided, the description carries the full transparency burden. It does disclose a critical behavioral property—that values are not exposed—which is genuinely useful. However, it omits other behavioral details such as authentication requirements, pagination behavior when limits are exceeded, and behavior when no secrets exist.

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 13-word sentence that front-loads the action and resource, then appends the safety qualifier. Every word contributes meaning—no fluff, no repetition of the tool name, and the information density is high for a listing tool.

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 tool has 3 parameters, no annotations, and no output schema, the description should cover parameter meanings, return format, and edge-case behavior. It partially covers the return (names, types, update times) but leaves pagination semantics, wallet scoping, error behavior, and authentication needs unexplained. For a moderately complex tool with zero structured metadata, this is incomplete.

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

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

Schema description coverage is 0% and the description explains none of the three parameters (limit, offset, walletAddress). While limit/offset are somewhat self-evident for a list operation, walletAddress's scoping semantics are unknown, and at 0% coverage the description was required to compensate but provides nothing about any parameter.

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

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

The description uses a specific verb ('List') and resource ('saved secrets'), and clearly distinguishes this from sibling tools like neus_secret_create and neus_secret_revoke. It even enumerates the fields returned (names, types, update times) and adds a crucial safety qualifier ('without exposing their values'), making the purpose 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?

The description gives no explicit guidance on when to use this tool versus alternatives, and it doesn't mention wallet scoping or pagination context. There are no when-to/not-to-use rules, no exclusions, and no mention that walletAddress might filter results, which is significant given the sibling tools operate on the same secret domain.

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 present, so the description carries full responsibility for disclosing behavior. It does not mention that revocation is likely irreversible, whether it affects existing proofs or verifications, or any required permissions. This is a significant gap for a destructive-like operation.

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

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

The description is a single, front-loaded sentence with no filler words. It is concise, though the brevity comes at the cost of potentially useful elaboration.

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 two unexplained parameters, the description is too minimal to fully equip an agent. It provides a basic purpose but omits critical details like parameter roles, side effects, and irreversibility concerns.

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

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

Schema description coverage is 0%, and the description names no parameters. An agent cannot infer whether walletAddress or qHash is the secret identifier or how they are used, so the description adds no parameter meaning beyond the schema field names.

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 ('Revoke') and resource ('saved secret'), clearly distinguishing it from sibling tools like neus_secret_create and neus_secret_list. The intended action is unmistakable.

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

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

The phrase 'so it can no longer be used' implies the tool's purpose but does not explicitly state when to use it versus alternatives, nor does it mention prerequisites or exclusions. Usage context is only implied.

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

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

The description discloses that the tool returns a catalog with supported networks and required inputs. With no annotations provided, behavior is partially transparent but lacks detail on data freshness, authorization requirements, or side effects. The description does not contradict any 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?

The description is two sentences long with no wasted words. The first sentence states what the tool does, and the second provides usage guidance. Excellent front-loading.

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

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

With no parameters, no output schema, and no annotations, the description adequately covers the tool's purpose and usage. It references a sibling tool for context. It could mention whether the catalog is exhaustive or if it supports real-time updates.

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 0 parameters, so the description does not need to explain parameters. The baseline is 4 for zero-parameter tools, but the description doesn't elaborate on how the catalog is returned (e.g., pagination, filtering). Since schema description coverage is 100% and no parameters exist, this is acceptable but not exceptional.

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

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

The description clearly states it provides a full catalog of verifiers with supported networks and required inputs. It distinguishes this tool from the verifierSummary in neus_context, which is a sibling tool.

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

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

The description explicitly says to use this tool 'when a check needs schema details beyond the compact verifierSummary in neus_context.' This provides a clear use case and references a sibling tool as an alternative for simpler cases.

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

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

With no annotations, the description must fully disclose side effects. It mentions the session-authorization path and that the operation creates or refreshes, but it does not explain what happens to an existing proof, what triggers a refresh, error behavior, or return values. Significant gaps remain for a mutating 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?

Two sentences, no fluff, action front-loaded. Both sentences carry essential usage or conditional 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 the tool's complexity (7 parameters, nested objects, no output schema), a two-sentence description is insufficient. It covers purpose and a key auth nuance but omits parameter meanings, return behavior, and failure modes, leaving the agent under-equipped to invoke it confidently.

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

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

Schema description coverage is 0%, so the description must compensate. It adds some meaning for walletAddress ('Omit the wallet when signed in'), but the remaining six parameters (data, chain, options, signature, verifierIds, signedTimestamp) receive no semantic guidance.

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?

Clearly states the action (Create or refresh) and resource (portable proof), with a condition ('after checking that one is needed'). It distinguishes itself from proof-checking tools (neus_proofs_check) and proof-retrieval tools (neus_proofs_get), though 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?

Provides explicit usage context: use after checking that a proof is needed, and omit the wallet when signed in. This gives clear timing and authentication guidance, though it does not mention when not to use or name sibling alternatives.

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?

There are no annotations, so the description carries the full burden. It reveals the conditional behavior (reuse vs guide) and includes an auth-related nuance (omit wallet when signed in), but it does not clarify what 'qualifying' means, whether the operation mutates any state, or what the return value looks like. The disclosure is useful but incomplete.

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, with the core behavior front-loaded and a concise usage tip following. Every word earns its place, and there is no redundancy.

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

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

For a 6-parameter tool with nested objects and no output schema, the description is too sparse. It does not explain parameter formats, verification semantics, or the structure of the 'next step' guidance, leaving significant gaps for an agent trying to invoke 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?

Schema description coverage is 0%, and the description only hints at walletAddress via the signed-in instruction. No meaning is added for verifierIds, data, chain, options, or requireAll. The description fails to compensate for the lack of schema-level explanations.

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

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

The description clearly states the tool's dual function: reuse a qualifying portable proof or return the next step needed to complete the check. This distinguishes it from sibling tools like neus_verify and neus_proofs_check by emphasizing reuse/guidance rather than direct verification.

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 explicit alternatives are named, and the usage context is only implied ('reuse a qualifying proof' vs 'next step'). The note about omitting the wallet when signed in provides conditional context but does not explain when to prefer this tool over neus_verify or other siblings.

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