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

The description adds material behavior beyond annotations: Obsideo holds no copy of the encryption key, losing the local file makes encrypted objects unrecoverable, and destination format changes the copy mode (.tar.gz archive vs. plain files vs. default home archive). This is exactly the kind of risk context an agent needs before invoking the tool.

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

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

The description is compact: four focused sentences covering purpose, critical risk, call timing, and path behavior. Every sentence earns its place, and the most important caveat about the encryption key is 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?

For a simple one-optional-parameter tool, the description covers everything needed to invoke it correctly: what is copied, where it goes, how the destination format changes the result, and when to call it. The absence of an output schema is fine because the tool's action is a file-copy operation, not a returned data structure.

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 the destination parameter and its default. The description adds meaningful semantics on top by explaining what each destination form produces ('one archive' vs. 'plain copies'), which helps an agent choose the right value confidently.

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

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

The description names a specific action ('Copy everything needed to recover this account's data') and a concrete resource set (credentials, signing key, encryption key, upload commitments). It clearly distinguishes this from the sibling tools by framing it as a local backup/recovery operation rather than an account-management or data-plane call.

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 guidance is given on when to call: right after account creation and after any signup that rotates keys. It also explains how destination type changes behavior. It does not explicitly mention when not to call or name alternatives, but no sibling tool is a true alternative, so the guidance is strong.

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 goes well beyond the readOnlyHint annotation by disclosing that encrypted objects are automatically decrypted with the local key, that retrieval fails on machines lacking the key, and that small text objects return inline while local_path forces file output. These are critical behavioral traits not available anywhere else.

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

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

Three sentences, each carrying operational weight; the action is front-loaded and no filler is present. Slight redundancy with the title ('Retrieve an object') keeps it from a perfect score, but the structure is tight and scannable.

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 read tool, the description covers the main traps: encryption, key locality, inline vs file output. It does not specify what happens when a non-small object is requested without local_path, nor the key's format, but annotations and the simple schema cover most of what an agent needs.

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 50%; local_path has a schema description, and the description reinforces the inline-versus-path behavior-controlled decision. However, key remains semantically bare – the description never explains what a valid key is or where it comes from, so parameter semantics are only partially enriched.

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 clear verb and resource: 'Retrieve an object'. It is not a tautology because it adds detail about encryption and inline versus file output, but it does not explicitly distinguish itself from sibling tools such as ls or put.

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 when to use the tool (retrieving stored objects) and gives concrete parameter usage ('pass local_path for anything else'), but it never states when not to use it or names an alternative tool. The guidance is functional but selection context is left largely 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 already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds a little extra context by hinting at the output format ('size TAB key') and the prefix scoping, but it does not mention pagination, limits, or whether the listing is complete. This is sufficient for a simple read-only list but not richer than what annotations already imply.

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. The parenthetical 'size TAB key' is compact but slightly cryptic, which prevents a perfect score.

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 tool with one optional parameter meaningful read-only annotations, the definition is largely complete. It explains the listing behavior, the prefix filter, and hints at the output layout. The absence of pagination or limitation details is a minor gap given the functional simplicity.

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 clarify the 'prefix' parameter. It does state that listing is 'optionally under a prefix', which adds meaning to the bare schema property. However, it does not specify the exact prefix semantics, such as whether a trailing slash is required or whether the prefix is a key prefix or a directory-like path.

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 operation: 'List stored objects' with an optional prefix filterabile. It does not explicitly distinguish this from sibling tools like get/put/rm, but the verb and resource make the core behavior 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?

There is no guidance about when to choose ls over alternatives or when to use the prefix option. The optional prefix is mentioned, but no context, examples, or exclusions are provided, so the agent must infer how this tool fits among its siblings.

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 carry readOnlyHint=true, and the description reinforces this while adding a meaningful external guarantee: 'Never contacts Stripe.' It also discloses that it surfaces pending upgrade offers, which adds useful behavioral context beyond the structured 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, front-loads the core purpose, and includes only high-value details: pricing model, status fields, read-only behavior, and Stripe non-contact. There is no filler 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?

For a zero-parameter read-only tool with no output schema, the description adequately covers what the caller should expect to receive: plan type, pricing details, status, period end, and pending upgrade offers. 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?

The tool has zero parameters and an empty input schema, so there is no parameter burden for the description to carry. Per calibration, this earns the baseline score of 4.

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, 'Show the account's plan', and enumerates exactly what will be shown: free tier or paid blocks, status, period end, and upgrade offers. It also distinguishes itself from mutation siblings like upgrade by stating it never changes anything and never contacts Stripe.

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 usage context is inferable: this is the read-only tool for inspecting the account's plan and pending upgrade offers. However, it does not explicitly name alternatives like upgrade, trial, or usage, nor does it state when not to use this tool.

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 mark the operation non-destructive and idempotent; the description adds specific behavioral detail about cancellation (data remains stored/readable and the account reverts to free quota at period end). It does not address things like link expiration or auth requirements, but for this simple tool the added context is valuable.

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

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

Three short sentences, each earning its place: the core function, the intended user, and the cancellation behavior. The main action 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 zero-parameter billing-portal-link tool, the description tells the agent what the tool does, who should receive the link, and what happens on cancellation. No output schema exists, but 'link' plus 'for the human to open' sufficiently communicates the returned artifact.

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 has zero parameters and the schema coverage is essentially complete, so there is no parameter meaning left for the description to add. Baseline for no parameters is 4, and the description contains nothing that muddies parameter behavior.

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

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

The description names a specific verb ('Get') and resource ('Stripe Customer Portal link for a paid plan') and lists the supported actions (cancel, change card, download invoices). It does not explicitly contrast itself with sibling tools, so it stops short of the clearest possible 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 clear context: the link is intended for a paid-plan human user and is meant to be opened by the human, not used programmatically. It does not explicitly name alternatives or state when not to use the tool, which keeps it from a 5.

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

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

The description richly discloses client-side AES-256-GCM encryption, local-only key custody, irrecoverability on key loss, zero-byte rejection, 3-provider replication, continuous verification, first-call account creation delay, and lack of cross-user sharing. This far exceeds the sparse annotations and gives an agent the critical security and latency expectations.

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 each sentence delivers essential security, validation, or performance information stole. The most important fact, encryption by default, is front-loaded in ALL CAPS, and the supporting caveats follow in a logical order with 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?

The description covers encryption, key backup, the plaintext exception, zero-byte limits, replication, first-call latency, and sharing restrictions, leaving little ambiguity for a storage operation. The only notable gap is that it does not state the exact success return value, but that is non-critical for a put operation with no output schema.

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

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

Schema description coverage is 100%, so each parameter is already explained structurally. The description adds minor context such as zero-byte rejection and the key-loss implication, but it does not substantially expand parameter meaning 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?

The opening line, 'Store a local file or inline content as an object', gives a specific verb, a clear resource, and the two supported input forms. This distinguishes it from sibling read/list/delete tools such as get, ls, and rm without requiring schema inspection.

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 core usage is unmistakable, and the description explicitly limits the one major deviation: 'Pass encrypt=false only when another tool must read the stored bytes directly (S3 interop)'. It does not explicitly name alternatives like get or rm for non-use cases, but the storage intent and encryption caveat provide adequate operational 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?

The description merely restates the destructive nature that annotations already capture via destructiveHint=true and readOnlyHint=false. It adds no extra context about irreversibility, missing-key behavior, authentication, or side effects, but it does not contradict the 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 a single short sentence with no filler and the core operation is front-loaded. Every word earns its place, making this an appropriately concise definition.

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 one-parameter destructive tool, the annotations carry important context through destructiveHint=true and idempotentHint=true. However, the description leaves key format and return behavior unspecified, and the lack of an output schema makes this slightly 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?

With 0% schema description coverage, the description must compensate for the undocumented 'key' parameter. It only repeats the property name by saying 'by key,' without explaining what a valid key looks like or where it comes from, adding minimal meaning 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?

The description states the operation directly ('delete') with a clear target resource ('object') and the identifying mechanism ('by key'). This is specific enough to distinguish it from sibling tools like put, get, and ls, though it does not name an alternative or scope.

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 when-to-use or when-not-to-use guidance is provided, and no alternative sibling is mentioned. The intended use is only implied by the verb 'delete' rather than explicitly stated.

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

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

Beyond the annotations (openWorldHint=true, idempotentHint=false), the description discloses concrete external effects: sending an email with a verification code, claiming or creating an account, preserving existing bucket/keys/data, and refusing placeholder or disposable domains with labeled errors. This gives the agent a strong picture of side effects and failure modes.

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 dense sentences, each earning its place: the core action and email behavior are front-loaded, the trial-claim conditional is explained concisely, and the 'then call signup_verify' next step is a useful, non-redundant closing. No filler 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?

For a stateful signup flow with no output schema, the description is largely complete: it covers both account-creation and trial-claim modes, validation behavior, and the next step. A small gap is that it does not describe the response/return shape or the existing-account (email_in_use) path, though the schema does document abandon_trial for that case.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful parameter behavior for the main required parameter by explaining the email must be readable and that placeholder/disposable domains are rejected. It does not add much for source or abandon_trial, but the schema already describes those adequately.

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 ('Start Obsideo signup') followed by concrete behavior: it emails a 6-digit verification code, claims an existing no-email trial if configured, or creates a new account. This distinguishes it from signup_verify, which is the follow-up verification step, and from the other 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 gives clear conditional context: if a no-email trial is configured, this tool claims it; otherwise it creates a new account. It also provides operational guidance ('Use a real inbox...' and 'Then call signup_verify'). It does not explicitly compare against alternatives like portal or upgrade, but the context is clear and no exclusions are needed.

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

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

Discloses detailed side effects beyond the annotations: local Ed25519 keypair generation, only the public half being sent, S3 credential storage at ~/.obsideo/mcp.json, credential/keypair rotation on re-run, no-overlap behavior, and a clear do-not-rerun warning. This is exactly the kind of non-obvious behavioral context an agent needs.

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 primary action is front-loaded in the first sentence, and every subsequent clause earns its place by conveying a distinct operational or safety requirement. Despite the density of caveats, there is no filler 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?

For a mutating tool with no output schema, it covers the critical operational facts: local key generation, credential file location, rotation behavior, and non-idempotence. The main gap is that it does not state the prerequisite signup_start step or how the tool knows whether the user is claiming a trial versus creating a new account.

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 only 50%: code has a description but email does not. The description reinforces that the code is emailed and tied to signup, but it does not clarify email semantics or how the trial-vs-new-account path is determined from the parameters. It adds some meaning beyond the bare schema but does not fully compensate for the missing email documentation.

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 action and resource: 'Complete signup with the emailed code.' It also clarifies two use paths (trial claim vs new account), which helps distinguish it from signup_start and verify. However, it never explicitly names or contrasts those sibling tools, so the differentiation is implicit rather than explicit.

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 concrete when-to-use context for two scenarios—claiming a trial and creating a new account—and explains what changes in each. It lacks explicit exclusion guidance, such as 'use signup_start to initiate' or 'do not use verify here,' but the described conditions are clear enough for an agent to infer the intended usage.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, openWorldHint=true, idempotentHint=false. The description adds valuable context: it refuses when an account exists unless replace is set, it saves credentials locally, it takes 15-30 seconds with progress reporting, and it creates a real production account with specific limits (100 MB, ~7 days, RF=3). It does not contradict annotations. The only minor gap is not detailing what 'destructive' means for replace (e.g., whether old credentials are overwritten or lost), but the description covers the key behavioral traits.

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

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

The description is dense but well-structured: it front-loads the core purpose, then covers the auto-provisioning exception, the upgrade path, and the timing. Every sentence earns its place, and the most important guidance ('You usually do NOT need to call this') appears early. 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?

For a tool with no output schema and two optional parameters, the description covers everything an agent needs: what it does, when to call it, when not to, what happens on refusal, what the result is (real account, limits, local credentials), how long it takes, and how to extend the trial. The sibling list confirms the alternative paths. Nothing critical is missing.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds meaning beyond the schema: it explains the default behavior of source ('mcp') implicitly and, more importantly, clarifies the replace parameter's purpose ('Only if the human explicitly wants a fresh, separate account') and the refusal behavior without it. This goes beyond the schema's bare description.

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 ('Create') and resource ('free Obsideo account') with explicit qualifiers: no email, no human in the loop, proof-of-work, ~10 second wait. It clearly distinguishes this from signup_start (email-based claim) and from the auto-provisioning behavior of put/get/ls/usage. An agent can tell exactly what this tool does and how it differs from 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?

The description explicitly says 'You usually do NOT need to call this' and explains that the first put/get/ls/usage auto-creates a trial if no account is configured. It also names the alternative for keeping data beyond the trial (signup_start) and the condition for using replace. This is exemplary when-to-use 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?

The description explicitly discloses side effects: 'This tool charges NOTHING and changes nothing' and explains that the human must pay on Stripe's page. It also clarifies that plan size is never changed from here, only via the human's click on the emailed agree link. This goes beyond the annotations (readOnlyHint=false, idempotentHint=true) by explaining exactly what side effects do and do not occur, providing 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 slightly longer than minimal but every sentence serves a purpose: it states the action, clarifies side effects, gives usage conditions, and covers the edge case. The main action is front-loaded, and the additional sentences provide necessary safety and behavioral context. It is well-organized and not 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?

For a tool with one parameter and no output schema, the description is comprehensive. It explains what the tool returns (checkout link or existing plan), how it should be handled (hand to human, do not submit), and the exact side-effect behavior. An agent has all the information needed to call it correctly and interpret the result.

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 already documents the single 'blocks' parameter with a description ('Number of 200 GB blocks (default 1)') at 100% coverage. The description mentions 'N x 200 GB blocks' but adds no new semantic detail beyond the schema. The baseline of 3 applies because the schema carries the parameter meaning.

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

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

The description opens with a specific verb and resource: 'Get a Stripe-hosted checkout link for a paid plan of N x 200 GB blocks at $5/month per block.' It clearly states what the tool does, distinguishing it from siblings like 'usage' or 'plan' by focusing on the checkout link generation. The scope is unambiguous.

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

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

The description gives explicit when-to-use guidance: 'Call it only when the human has asked for more space, and hand the link back to them; do not open or submit it yourself.' It also provides a when-not condition (do not open/submit) and an edge-case behavior (if already on a paid plan, returns the plan). It does not name specific alternative tools, but the context is clear enough for an agent to decide.

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 and openWorldHint. Description adds 'versus quota' context but does not disclose additional behavioral traits like rate limits or data format. Satisfactory given 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?

Single sentence, front-loaded, no waste. Every word earns its place.

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

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

Description is adequate for a simple read-only tool with no parameters, but lacks detail about output format or structure. With no output schema, a bit more context would improve completeness.

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?

No parameters exist; baseline score of 4 applies. Description adds no parameter info since none are needed.

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?

Description clearly states the verb ('Show') and resource ('account storage usage versus quota'), distinguishing it from generic sibling tools 'get' and 'put'. It is specific and 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?

No guidance on when to use this tool versus alternatives. Siblings 'get' and 'put' are present but not mentioned; no explicit when-to-use or when-not-to-use 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?

Annotations already indicate readOnlyHint=true, and the description adds substantial behavioral detail: it trusts nothing from the coordinator, challenges each provider, recomputes the merkle root locally, checks signatures, and reports per-provider results. It also discloses the return value semantics ('how many providers proved possession right now and whether any returned bad data'), going well beyond the 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 front-loaded with the core purpose, then delivers mechanism, trust behavior, parameter guidance, and return semantics in a compact, well-organized paragraph. Every sentence adds distinct value; there is no filler or tautology.

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 read-only annotations, only two parameters, full schema coverage, and no output schema, the description is complete: it explains what the tool does, how it behaves cryptographically, when local_path is needed, and what the call returns. An agent has everything needed to invoke 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 baseline is 3. The description adds useful meaning beyond the schema by explaining that objects stored through this server need no extra arguments and that local_path is used to prove possession against a local file instead. This contextual guidance helps the agent decide how to populate the optional 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 opens with a precise verb and resource: 'Independently verify that the network still holds an object, without downloading it.' It then details the mechanism (challenging providers, recomputing merkle root, checking signatures), which clearly distinguishes verify from siblings like get or ls.

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 clear context for when to use verify: for independent possession proofs, and specifically distinguishes the local_path case as only needed for objects this server did not upload. It does not explicitly name exclusions or sibling alternatives, but the context is sufficient for an agent to select it appropriately.

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