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

Annotations only carry destructiveHint=true; the description goes well beyond that by flagging irreversibility, the exact response shapes for both success and no-op cases, the post-hoc remediation ('if it was already read, the recipient has the value, so rotate the credential'), the creator-only auth requirement, and that the call is free.

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?

Front-loaded with the verb and consequence, and every clause earns its place given the absence of an output schema. The no-op return path is a dense run-on sentence, but it carries genuinely necessary 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 no output schema and minimal annotations, the description compensates fully: it documents both success and no-op responses, states the irreversible mutation, and identifies the required credential source, leaving nothing an agent needs before calling 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 description coverage is 100%, so both parameters are already documented. The description restates the receiptToken constraint ('only works for secrets you created (needs their receiptToken)') but adds no syntax or format detail beyond the schema, 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 ('Permanently destroy an unread secret you created') plus the observable effect ('its link stops working'), which cleanly separates it from ncrypted_create, ncrypted_read, and ncrypted_status.

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 situations for invocation ('sent to the wrong place or is no longer needed') and a hard restriction ('Only works for secrets you created'), but never names the sibling tools an agent might otherwise reach for, so the when-not is implied rather than routed.

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

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

With no annotations, the description carries the full burden and does so: one-read-then-self-destruct semantics, free tier of 3/day at 24h TTL with no email, then 0.005 USDC charged automatically from a Base wallet via x402, and the failure mode if no funded wallet exists. It also adds a security constraint ('never echo the secret value in chat', 'treat the link like the secret itself') and notes the service transiently sees the link on email sends.

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

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

Purpose is front-loaded in the first sentence, and every subsequent sentence carries distinct information (return shape, pricing, delivery, safety, alternatives) — nothing is filler. The later sentences are dense and run together return shape, key retention, and three sibling alternatives in one block, which slightly hurts scanability.

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?

No output schema exists, but the description supplies the return shape ({ link, id, receiptToken, expiresAt }) and explains why id and receiptToken matter (ncrypted_status for delivery, ncrypted_burn to revoke). For a 5-param mutation/payment tool with no annotations, this covers cost, auth requirement (funded wallet), irreversibility, and next steps.

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 earns above that by naming emailTo and TTL explicitly and by adding the free-tier constraint on TTL ('up to 24h, no email') that the schema does not state. The passphrase delivery caveat ('different channel') also adds meaning. It does not add much for emailNote or the secret payload beyond 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?

Specific verb and resource: 'Encrypt a password, API key, or sensitive note locally and store it as a one-time secret. Returns a link that works exactly once, then self-destructs.' It also distinguishes itself from ncrypted_read, ncrypted_request, ncrypted_to_vercel_env and ncrypted_to_dotenv by name, so an agent can pick it without opening sibling 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?

Explicit routing: 'Use ncrypted_request instead when you need a secret FROM the user' and ncrypted_to_vercel_env / ncrypted_to_dotenv 'when a value from a link must be installed somewhere.' It also states the delivery options (human, email, another agent) and when email is appropriate ('If the user asks you to email it'), which covers both when to use and when to choose an alternative.

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 idempotentHint=false, and the description supplies the concrete consequence beyond that: the secret is consumed on read and can never be read again. It also adds cost (free) and a confidentiality constraint, which annotations cannot express.

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?

Severity is front-loaded: what the tool does, then the irreversible destruction, then the alternatives. Every sentence carries distinct information (destruction, cost, handling rule, two alternative routes) with 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 two-parameter tool with no output schema, the description covers the return ('the secret'), the destructive side effect, the privacy handling rule, and the alternative paths an agent might mistakenly choose. Nothing needed to call this correctly is missing.

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

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

Both parameters are fully documented in the schema (100% coverage), including the passphrase's conditional requirement and the need for the #key fragment. The description restates the link format including the fragment but adds no new syntax or edge-case guidance, 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 concrete verb chain (open link, decrypt locally, return secret) and the exact resource shape (https://.../s/{id}#{key}). It is unmistakably the consumption/read path of the ncrypted family, distinct from create, status, and the env-writing siblings.

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?

Explicitly routes to alternatives with conditions: use ncrypted_to_vercel_env or ncrypted_to_dotenv when the value only needs to land in an env var so the agent never sees it, and use ncrypted_status to check opens without consuming. It also states the in-task handling rule (use only for the task, don't echo in chat), which is a usage constraint, not filler.

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?

Since there are no annotations, the description carries the full burden of transparency. It explicitly discloses critical security traits: the data is 'encrypted in their browser' and 'encrypted on this machine,' guaranteeing the AI never sees the secret. This is highly valuable behavioral 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 long, but every part serves a crucial functional or security purpose (e.g., the instructions on ending the turn). While a bit verbose, it prioritizes instruction over brevity, which is appropriate for a complex, multi-step 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 zero-annotation context, the description is exceptionally complete. It covers the entire security mechanism, the user interaction flow, and the necessary subsequent steps, leaving no practical question for the agent to ask before use.

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%, meaning the schema already defines the parameters. The description adds no specific linguistic semantics beyond restating the purpose of the tool, thus meeting the baseline requirement for high 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 is extremely clear and specific: it is used when 'you need a password, API key or token from the user.' It states exactly what the tool initiates: returning a secure link to collect the secret.

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 extremely detailed, step-by-step usage instructions, including explicitly telling the agent to 'END YOUR TURN' and referencing the subsequent tool (ncrypted_request_fulfill) to complete the workflow. This eliminates ambiguity about the entire interaction flow.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses that vercel_env/dotenv writes without revealing the value, that 'return' exposes the value and must not be repeated, and that wait_seconds can yield a pending status requiring another call. It does not cover permission requirements, overwrite behavior, or what happens to the secret afterward, but the core behavioral traits are disclosed.

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?

Every sentence earns its place: precondition, preferred destination behavior, restricted return behavior, and wait/pending handling. The precondition is front-loaded, and there is no filler.

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

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

For a 9-parameter tool with no annotations and no output schema, the description covers the essential calling context: when to invoke, destination semantics, secret-handling constraints, and async/pending behavior. Gaps remain around failure modes, permissions, and overwrite semantics, but the schema fills in most parameter detail.

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

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

Schema coverage is high at 89%, so the baseline is 3. The description adds meaningful semantics for the key destination parameter by explaining the practical effect of each enum value, and it explains wait_seconds in terms of pending status. Other parameters are left to the already-rich 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 states a specific verb and resource: collect and deliver a requested secret after the user submits an ncrypted_request. The destination modes clarify what 'deliver' means. It does not explicitly distinguish itself from sibling tools like ncrypted_to_vercel_env or ncrypted_to_dotenv, so it falls just short of full sibling differentiation.

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 precondition ('After the user says they've submitted an ncrypted_request') and guidance on destination choice, including a preferred path (vercel_env/dotenv) and a restrictive when-not for 'return'. It also explains retry behavior for pending status. It does not name or route among sibling tools, leaving some alternative selection implicit.

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 only declare readOnlyHint=true; the description adds substantial context beyond that: the operation is non-consuming, it requires creator credentials (receiptToken, not just the link), it enumerates the possible status outcomes and their meanings, and it notes the call is free. This is rich behavioral disclosure for a read-only 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?

Front-loaded with the core action and its key non-destructive property, followed by return shape, then usage routing, then the constraint, then a one-word cost note. Every clause earns its place; no 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 no output schema present, the description compensates by documenting the return payload shape ({ status, expiresAt, readAt? }) and the meaning of each status value. Combined with the precondition and sibling routing, an agent has everything needed to call this 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 both parameters are already documented, but the description adds semantic meaning the schema repeats only implicitly ('only works for secrets you created (needs their receiptToken)'), clarifying why the token is required and who holds it. That is a genuine increment over the baseline.

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 ('Check whether a secret ... has been opened') with the critical qualifier 'without consuming it'. It explicitly distinguishes itself from ncrypted_read (opening a link) and ncrypted_burn, so an agent can route correctly without opening any schema.

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

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

Gives concrete when-to-use guidance ('confirm delivery, or before deciding to ncrypted_burn a link'), an explicit precondition ('Only works for secrets you created (needs their receiptToken)'), and names the alternative tool for the other use case (ncrypted_read). 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 only declare destructiveHint=true, and the description adds real context beyond that: the file is written with mode 600, the secret is deliberately never displayed, and a warning fires if the file isn't git-ignored. It stops short of saying what happens to an existing KEY entry or whether the file is overwritten or appended.

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 dense sentence with the action front-loaded and the two behavioral caveats (mode 600, git-ignore warning) packed into a parenthetical/clause. Efficient, though stacking the warnings inline makes it slightly dense.

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 destructive write tool with no output schema, the description covers the safety-relevant basics (permissions, secret never shown, git-ignore check) but omits overwrite semantics, passphrase handling, and any indication of what is returned. Adequate but with clear gaps.

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

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

Schema coverage is only 50%, so the description needs to compensate. It clarifies 'KEY=value' for key and that the target is a .env file for path, but says nothing about the passphrase parameter (undocumented in the schema too) or what link looks like, leaving one of four parameters with no explanation anywhere.

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 concrete verb and resource: opens an ncrypted link and writes its value to a local .env file. The word 'local' implicitly distinguishes it from the sibling ncrypted_to_vercel_env, but that sibling is never 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?

The description implies the use case (materializing a one-time secret into a local env file) and mentions a git-ignore warning, but gives no explicit when-to-use vs. when-not guidance and never routes to alternatives like ncrypted_to_vercel_env or ncrypted_read.

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 only supply destructiveHint=true; the description adds the material context: the link is one-time and gets consumed, Vercel access is verified before consumption (a fail-safe ordering the agent would otherwise have to guess), auth comes from `vercel login` or VERCEL_TOKEN, and the var is written as type sensitive. This is consistent with, and additive to, the destructive 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?

Three short sentences, front-loaded with the core action, then the security property, then the auth/ordering behavior, then the alternative. No filler sentences.

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-param mutation with no output schema and thin annotations, the description covers the critical unknowns (auth source, pre-check ordering, secret exposure). What it leaves out is what happens on overwrite—whether an existing env var of the same key is replaced or rejected—which matters for a destructiveHint=true tool.

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

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

Schema coverage is 71%, so cwd/key/team/project/targets are already documented upstream. The description adds no parameter-level detail beyond restating the link's role—it never mentions key, targets, team, project, cwd, or passphrase semantics (e.g., whether passphrase is required for protected links).

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 chain and resource: open an ncrypted link and write its value into a Vercel project environment variable of type sensitive. This clearly separates it from ncrypted_read (which would surface the secret) and from ncrypted_to_dotenv (a different sink).

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?

Explicitly says 'Prefer this over reading a secret and running `vercel env add`', naming the alternative workflow and the condition that selects this tool. Combined with the 'never appears in this conversation' rationale, an agent knows exactly when to route here versus reading the link.

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, so safety is covered. The description adds genuine context beyond that: the free-secret allowance is daily ('today's remaining'), the balance is denominated in USDC on Base, and the call itself is free — all useful for deciding whether to invoke it.

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 dense sentence with no wasted words, and the most decision-relevant fact (remaining free secrets) is front-loaded. Slightly telegraphic phrasing ('pays for more') costs it 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?

For a no-parameter read tool with no output schema, the description adequately tells the agent what comes back and that it is free. The only gap is the absence of any routing hint against the closely related ncrypted_status sibling.

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

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

The tool takes zero parameters and the input schema is an empty object, so there is nothing for the description to disambiguate. Baseline 4 applies.

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

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

The description states a specific verb ('Show') and enumerates the exact resources returned: today's remaining free secrets, the payer wallet address, and its USDC balance on Base. That is materially clearer than the name alone and separates it from ncrypted_wallet_setup, though it never explicitly contrasts itself with ncrypted_status, which could also plausibly report quota.

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

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

There is no statement of when to call this versus sibling tools such as ncrypted_status or ncrypted_wallet_setup, and no prerequisites or exclusions. The agent must infer from the returned fields alone that this is the quota/balance check.

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

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

With no annotations to lean on, the description carries the full load and does it well: pricing (0.005 USDC per secret on Base), the 1 USDC = 200 secrets conversion, idempotent create-if-none behavior, the private key living in a local file and never being shown to the agent, and the one-time-link nature of the backup. These are exactly the facts an agent needs before invoking a wallet-creation 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?

Three compact sentences, front-loaded with the primary action, then the funding instruction, then the security caveat and the optional parameter. 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?

No output schema exists, yet the description names the key return field (`fundUrl`) and explains what to do with it. For a 2-parameter, 0-required setup tool it covers action, cost, security model, and follow-up steps completely.

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, but the description adds real meaning: it explains the funding conversion rate that makes amount_usdc interpretable and clarifies the intent behind backup_to_owner (a copy of the key for the owner, delivered as a one-time link).

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 the local wallet that pays for secrets') plus the secondary effect of returning a funding link, and it explains the wallet's role in the free-tier/paid-secret flow. It does not name or distinguish itself from the sibling ncrypted_wallet, so an agent must infer the split between 'set up' and whatever ncrypted_wallet does.

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 operational context: call it when no wallet exists, then send the user `fundUrl` and ask for USDC on Base. It also gives conditional guidance for backup_to_owner ('only if the user wants a copy of the key'). It stops short of routing against alternatives such as ncrypted_wallet or ncrypted_status.

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