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

The description discloses two critical behavioral traits: the key is returned only once, so it must be stored immediately, and only the owner can perform this action. The annotation openWorldHint is vague, so the description's details add significant value beyond structured data.

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 entire description is a single, dense sentence that effectively communicates purpose, permissions, and a key caveat. No filler 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?

While the description covers the key behavior and use case, it fails to explain the parameters, and because there is no output schema, it does not describe the response format beyond the key being returned once. Given the tool's simplicity, this is a moderate gap.

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 description does not explain the 'name' or 'org_id' parameters at all. With schema description coverage at 0%, the agent must guess the meaning of these parameters from context, which is insufficient.

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 specific verb 'mint' to indicate creation of an org API key, clearly distinguishing it from sibling tools like apikey_list and apikey_revoke. The phrase 'returned ONCE' emphasizes the creation aspect, 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 phrase 'Useful for long-lived machine VPN/usage via X-Api-Key' provides a clear use case and context for when this tool is appropriate. However, it does not explicitly name alternatives or state when not to use it, which is a minor gap.

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 the agent knows it is a safe read operation. The description adds the 'prefixes only' detail, which informs the user that full key secrets are not returned. However, it does not disclose pagination, ordering, or whether the list is scoped to the current user or an organization.

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, focused sentence with no filler. It front-loads the action and the key constraint ('prefixes only'), making it highly scannable and appropriately sized for such a simple 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?

With no output schema and minimal annotation detail, the description leaves gaps about what 'metadata' includes, how org_id affects results, and the shape of the response. For a list tool, some information about scoping and returned fields is expected.

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 explain the org_id parameter. The agent must infer that org_id is an optional organization filter from the parameter name alone, which is insufficient for clear understanding.

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 ('key metadata'), and adds a clear qualifier ('prefixes only') that distinguishes it from key creation/revocation tools. It is immediately obvious what this tool does, even without the title.

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 no guidance on when to use this tool versus alternatives like apikey_create or apikey_revoke. It does not mention the optional org_id filter, prerequisites, or when to prefer another 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?

The description adds the ownership restriction ('Owner only') beyond the annotations, which already include destructiveHint. It does not detail side effects of revocation, but the destructive hint covers the main behavioral trait. No contradiction with 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 extremely concise—two short sentences—and both carry meaningful information. No filler words or redundant content.

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 tool is simple, but the description omits any context about the optional org_id parameter or the consequences of revocation. The destructiveHint mitigates some need, but the org_id ambiguity remains, making it a basic but incomplete description.

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 explain the parameters beyond 'by id', which maps to key_id. The org_id parameter is unaccounted for, and the description fails to compensate for the lack of schema 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?

The description clearly states the action (revoke) and the resource (API key) by id. The title 'Revoke org API key' aligns with sibling tools like apikey_create and apikey_list, making its purpose distinct among the sibling set.

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 implicitly indicates usage (when you need to revoke an API key) and adds an explicit constraint ('Owner only'). It doesn't mention alternatives, but the directness provides clear context and no exclusions are stated.

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

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

The annotation openWorldHint=true suggests side effects, and the description explicitly names the side effect: sending an OTP email. It also discloses that it is public and requires no prior session. This goes beyond the annotation by specifying the exact action and scope.

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, front-loads the core action, and includes the endpoint as a precise reference. Every phrase earns its place without 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 simple tool without an output schema, the description sufficiently conveys the main action. However, it lacks next-step guidance, such as mentioning that the OTP must be used with auth_email_login_verify, and how the OTP is delivered or expires. This creates a minor completeness gap in the login flow context.

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 covers 50% of parameters descriptively, but the description itself adds no parameter semantics. The 'app' parameter is well-described in the schema, but 'email' only has a format constraint and no semantic description. The description does not compensate for this gap, leaving the meaning of 'email' implicit.

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 action: 'send a 6-digit OTP' for 'Passwordless email login', and includes the endpoint for precision. It is distinct from sibling auth_email_login_verify, which would handle the verification step, thus effectively differentiating purpose.

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: it is a passwordless email login that requires no prior session. This implies when to use it, though it does not explicitly reference sibling alternatives or exclusion conditions. It adequately orients the agent to the start of the login 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?

The description discloses the side effect of storing PASETO in the MCP session, which adds meaningful behavioral context beyond the sparse openWorldHint annotation. However, it does not mention potential side effects like invalidating previous sessions or failure behaviors, so transparency is limited but not absent.

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 concise sentences, front-loaded with the action and endpoint, followed by the side-effect. Every word earns its place, and the structure is easy to scan.

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 auth tool, the description covers the core action and side effect, but lacks prerequisites (e.g., that auth_email_login_start must have been called) and does not describe the response format since there is no output schema. This leaves some gaps for an agent choosing to 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 67% (code and ref are described; email only has a format). The description adds no additional parameter semantics, but the schema already provides clear descriptions for required fields. Baseline of 3 applies, with no significant added value from the 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 clearly states the tool's action: verify email OTP and log in, with the specific endpoint and the side effect of storing PASETO in the MCP session. This distinguishes it from siblings like auth_email_login_start (which likely initiates login) and auth_wallet_complete.

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 tool is used after receiving an OTP via email, but it does not explicitly say to use it after auth_email_login_start or provide alternatives. No exclusions are given, so usage context is only implied rather than fully specified.

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 adds session-scoped context ('store in this MCP session') but does not disclose whether the token is validated, whether it replaces an existing session token, or any security implications. Annotations only include openWorldHint: false, so the description carries most of the burden and only partially meets 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?

Two sentences, front-loaded with the action and resource, plus a useful alternative guidance. No filler or redundant 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?

For a simple two-parameter tool, the description covers purpose and use case adequately, but lacks important context about import behavior (e.g., whether the token is checked, what happens to existing auth state) and does not mention return/error behavior. Since there is no output schema, those details would be valuable.

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 token parameter is described in the schema, but user_id has no description and the description adds no meaning beyond the schema. With 50% schema coverage, the description should compensate for the undocumented user_id but does not.

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 ('Store') and a clear resource ('already-issued user PASETO in this MCP session'), distinguishing it from the wallet/email auth flow. It also gives a concrete example ('e.g. from a previous login') that clarifies the tool's role.

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 provides clear context: this is for reusing an existing PASETO rather than authenticating fresh. It also points agents to prefer wallet/email tools, but it does not explicitly state when NOT to use this tool or provide exclusionary 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?

The description discloses a behavioral trait beyond the only annotation (openWorldHint: false): the env fallback EREBRUS_BEARER_TOKEN continues to apply until process exit. This is crucial for the agent to understand the tool's effective scope and potential side effects, and it is not present in any structured field.

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, concise sentence that front-loads the action and includes the important env fallback caveat without any fluff. It is appropriately sized for a zero-parameter 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?

For a simple logout tool with no parameters, no output schema, and minimal annotations, the description covers the core operation and a key edge case. It is fully adequate for an agent to invoke 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 tool has zero parameters, which qualifies for the baseline score of 4. No parameter description is needed, and the schema coverage is trivially 100%.

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 states 'Clear the MCP session PASETO', which is a specific verb+resource combination. It clearly distinguishes from siblings like auth_import_token (importing a token) and auth_status (checking status). The title 'Clear session token' aligns perfectly.

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, but the tool's purpose as a logout action is self-evident. The description adds useful usage context by noting that the EREBRUS_BEARER_TOKEN env fallback still applies until process exit, implying this tool may not fully deauthenticate if that env var is set.

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 annotations already indicate readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the valuable context that the endpoint is public, which is not captured by the annotations, and clarifies that it returns which methods are configured. There is no contradiction with 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 concise sentence that immediately states the resource and provides a key qualifier (public). Every word earns its place, and there is no redundancy with the title or schema.

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 strong annotations, the description fully covers the necessary context. It tells the agent what the tool does and that it is public, which is sufficient for a simple read-only list operation.

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 100% (empty object). According to the rubric, 0 parameters earns a baseline of 4. The description does not need to explain any parameter semantics because there are none.

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: to list the login methods configured on the gateway. The phrase "which login methods the gateway has configured" is specific and distinguishes this from sibling tools like auth_status or auth_email_login_start by focusing on configuration discovery rather than authentication flow.

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 some context by noting the operation is "public," implying it can be called without authentication. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or 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?

Annotations already indicate read-only behavior (readOnlyHint=true). The description adds meaningful context beyond annotations by specifying the exact artifact being checked (PASETO) and how it might be obtained (login tools or EREBRUS_BEARER_TOKEN fallback). No contradiction with 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?

A single sentence concisely conveys the tool's purpose and key behavioral detail. It is front-loaded with the action ('Show whether') and avoids any redundant or filler text.

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

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

For a zero-parameter, read-only status tool, the description fully covers the necessary context: what is checked, where the token comes from, and the implied yes/no result. No output schema exists, but the description's wording sufficiently conveys expected behavior.

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

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

The tool has zero parameters, which sets a baseline of 4. The description does not need to elaborate on parameters and correctly focuses on the tool's purpose.

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 with a specific verb ('Show') and exact resource ('whether this MCP session has a user PASETO'). It distinguishes itself from sibling auth tools by focusing on session-level token presence, including the token source (login tools or EREBRUS_BEARER_TOKEN fallback).

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: to check if the session holds a user PASETO. It implies usage for status verification but does not explicitly mention alternatives or exclusions, so it stops short of the top score.

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 only the openWorldHint annotation, the description adds significant behavioral detail: it's a GET request, returns flow_id and message to sign. This goes beyond the annotation and gives the agent a clear picture of the tool's behavior. It doesn't mention side effects, but the openWorldHint suggests low risk.

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 concise sentence front-loads the action and includes the endpoint and return values. No wasted words; every phrase adds value.

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 the tool's purpose, the HTTP method, and the return values (flow_id and message). There's no output schema, but the textual return description suffices for this simple initiation tool. It doesn't explicitly mention the next step (auth_wallet_complete), but the sibling list and context signals hint at it.

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

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

Schema coverage is 100% with both parameters described (wallet_address and chain with enum). The description adds no additional parameter meaning beyond what the schema already provides, 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?

The description clearly states the action: 'Start wallet-signature login' with the HTTP endpoint. It distinguishes itself from sibling tools like auth_wallet_complete by indicating this is the initiation step, not the completion step.

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 clearly implies use when initiating a wallet login. It mentions 'wallet-signature login' which contrasts with email login alternatives, but it doesn't explicitly name alternatives or provide when-not-to-use conditions. Clear context without exclusions.

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

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

Annotations are minimal (openWorldHint only), so the description bears the burden. It discloses that it stores the PASETO in the MCP session, which is useful. However, it omits other behavioral details such as account creation on first signup, session replacement, or error 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?

One concise, front-loaded sentence that includes the endpoint and the key side effect. No wasted words, and the most important information is at the beginning.

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 gives the core action and session storage but lacks flow context, prerequisites, and edge-case behavior. It is minimally workable but leaves significant gaps for a multi-step auth process.

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 description adds no parameter information. Schema coverage is 75%, with flow_id lacking a description. Since the description doesn't compensate for that gap, parameters are only partially explained by the schema alone.

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 action ('Complete wallet login') and resource (wallet login), and includes the endpoint. It differentiates from sibling tools like auth_wallet_challenge by noting the PASETO session storage, but doesn't explicitly contrast with all related auth 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?

No explicit guidance on when to use this tool versus alternatives. It doesn't mention that it should follow auth_wallet_challenge or that it's the second step in a flow. There are no prerequisites, exclusions, or alternatives noted.

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 provide destructiveHint=true and openWorldHint=true, but the description adds no behavioral information beyond the verb 'Delete'. It does not mention irreversibility, side effects, or authorization needs. No contradiction, but no added value beyond 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 concise sentence that front-loads the action ('Delete') and resource. Every word earns its place; there is 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?

Tool complexity is low with one parameter and no output schema, and destructive annotations cover the risk profile. However, the description omits usage context and where file_id comes from, making it minimally adequate but not complete.

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 only parameter file_id is only referenced as 'by id', adding minimal semantic meaning. The description does not explain how to obtain file_id or what format it expects, leaving a gap for the single required 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 ('Delete') and resource ('Drop file') with the identifier mechanism ('by id'), making it clear what the tool does. It also distinguishes itself from sibling tools like drop_file_get and drop_files_list.

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, nor any mention of prerequisites like obtaining a file_id from drop_files_list or drop_file_get. The description gives no usage 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 declare readOnlyHint and openWorldHint, signaling a safe read operation. The description adds no additional behavioral context beyond what annotations provide, but it also does not contradict them. Given the annotations, the description is sufficient but minimal.

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 concise sentence that directly states the tool's function. It is front-loaded and contains no filler, earning a perfect score for 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?

This is a simple read tool with one parameter and no output schema. The description states the purpose adequately, but it omits how to obtain a valid file_id and what metadata fields will be returned. Given the simplicity, the description is minimally acceptable but lacks helpful context.

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 a single required parameter, file_id, with no description, and the tool description does not mention or explain it. With 0% schema description coverage, the description should compensate by clarifying what file_id is, but it only says 'one Drop file', which is implicit. The parameter name is self-explanatory, but no added semantic meaning is provided.

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 'Get metadata for one Drop file', with a specific verb ('Get'), resource ('Drop file metadata'), and scope ('one Drop file'). This distinguishes it from sibling tools like drop_files_list (list) and drop_file_delete (delete).

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 when-to-use or alternative guidance is provided. The intended usage is implied by the tool name and description: use when you need metadata for a specific file ID. However, it does not mention that file IDs can be obtained via drop_files_list, which would be helpful.

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 and dynamic nature. The description adds the scope 'authenticated user's', which is useful, but it does not disclose additional behaviors such as pagination, ordering, or whether only files (not directories) are returned. With annotations in place, this is an adequate but not rich disclosure.

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, concise sentence that conveys the essential purpose without wasting words. It is front-loaded with the verb 'List' and is immediately understandable.

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 list tool with no parameters and no output schema, the description is minimal but adequate in scope. However, it lacks any indication of the return structure (e.g., what fields a 'Drop file' includes), and there is no output schema to fill that gap. This leaves the agent without complete information about the response format.

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 schema coverage is 100% (vacuously). The description needs no parameter explanations. Baseline for 0 params is 4, and the description does not need to compensate further.

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 specific verb 'List' and identifies the resource as 'authenticated user's Drop files', which clearly distinguishes it from sibling tools like 'org_drop_files' that list org-level files. This is a specific and unambiguous statement of what the tool 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for personal/user-level files while 'org_drop_files' is for org-level files, nor any other selection criteria.

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 read-only nature is already declared in annotations (readOnlyHint: true). The description's only added details are the GET endpoint and scope/org_id constraint, but the latter is already present in the input schema. No new behavioral context (e.g., response format, pagination, or rate limits) is provided, so it adds little beyond the structured metadata.

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

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

A single sentence that front-loads the purpose and includes the key constraints. No redundant wording; every part earns its place. It is appropriately concise for a simple list 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?

The tool is simple and has good schema/annotation coverage, but the description does not mention what the returned nodes look like or how to interpret them. Since there is no output schema, the description should carry more weight in explaining the response. The details about scope/org_id are redundant with the schema, so the overall context is only minimally complete.

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 repeats the scope=public/private and org_id requirement, which is already in the schema. It does not add any additional meaning such as parameter formats, usage patterns, or how the parameters affect results.

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 lists nodes available for Drop uploads, with a specific verb (list), resource (nodes), and domain (Drop uploads). It distinguishes from siblings like drop_files_list and drop_upload_reserve by focusing on the node selection step.

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 establishes clear context: it is for listing nodes to use in Drop uploads. It mentions the scope parameter and the org_id requirement for private scope, which guides usage. However, it does not explicitly name alternatives or exclusions, so it does not fully differentiate from sibling tools beyond purpose.

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 only the vague openWorldHint annotation, the description carries the transparency burden. It clearly signals a mutating HTTP PUT and adds context about base64 encoding and size limits, but it does not disclose side effects (e.g., finalizing the upload, idempotency, fate of the reservation) or error behavior. This is adequate but not rich.

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, efficient sentence that front-loads the purpose and packs essential details (base64 body, size limit). No filler or 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 simple 3-parameter upload with no output schema, the description covers the core action, encoding, and size. However, it omits explicit context about the reservation lifecycle, what happens after a successful upload, and how to reference the reservation ID. This creates gaps for an agent trying to sequence steps 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 67% (content_type and content_base64 documented). The description adds value by explaining that the body must be base64-encoded and that the decoded size should be ≤15MB for MCP, directly clarifying the content_base64 parameter. It also implies upload_id is the reservation identifier, which is not stated 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 "PUT raw content for a reserved upload" uses a specific verb (PUT) and identifies the resource (raw content for a reserved upload). It clearly distinguishes from sibling tools like drop_upload_reserve, drop_upload_status, and drop_files_list by targeting the byte-content upload step in the flow.

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 "for a reserved upload" implies a prerequisite: the upload must already be reserved (likely via drop_upload_reserve), and the size limit "max ~15MB decoded recommended for MCP" provides an explicit constraint. However, it does not explicitly name the alternative/reservation tool or state when not to use this tool, though the implication 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 discloses the core behavior (reserving a slot) and the API endpoint, but does not elaborate on potential side effects like slot expiration or idempotency. The openWorldHint annotation already warns of unknown side effects, so the description adds some value but not rich detail.

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 extremely concise, using two sentences to convey the purpose and the follow-up action, with no redundant 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 has 11 parameters (2 required) and no output schema, the description is insufficient. It fails to mention which parameters are required, what the response contains, or how the reservation integrates with the overall upload flow beyond naming the next step.

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 description provides no information about any of the 11 parameters, despite the schema description coverage being only 36%. It only mentions the returned 'upload id' from the next step, leaving all parameter meanings unexplained.

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 action ('Reserve an upload slot') and the specific resource (POST /api/v2/drop/uploads), and it explicitly names the next step (drop_upload_content), distinguishing it from sibling upload 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 provides clear usage context by instructing to call drop_upload_content next, indicating this is the first step in a two-step upload flow. However, it does not explicitly mention when not to use this tool or list alternative approaches.

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 (readOnlyHint=true) already indicate a safe read operation, and the description adds the context of 'reserved/in-progress upload.' However, it does not disclose what status values may be returned or how errors are handled, leaving some behavioral ambiguity 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 a single, front-loaded sentence that directly conveys the action and target. Every word earns its place, with no filler or repetition of the tool name.

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

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

The tool is simple (one read-only parameter, no output schema), but the description omits details about the response format or possible statuses. While adequate for basic selection, it falls short of being fully complete for an agent that needs to interpret the result without additional 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?

With schema description coverage at 0%, the description carries the burden for explaining upload_id. It implies upload_id identifies the reserved/in-progress upload but does not explicitly state its origin (e.g., from drop_upload_reserve) or format, offering only marginal value over the raw 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 the tool's purpose: 'GET status for a reserved/in-progress upload.' It uses a specific verb (GET) and resource (status of an upload), and distinguishes itself from siblings like drop_upload_reserve and drop_upload_content by focusing on status checking rather than creation or content transfer.

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 tool is used for checking the status of a reserved/in-progress upload, but it does not explicitly state when to use it versus alternatives. It provides context but no exclusions or direct references to sibling tools, such as using drop_files_list for completed uploads.

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, but the description adds no additional behavioral context beyond calling it 'usage stats'. It does not disclose what metrics are included, whether data is cached, or any other relevant 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 extremely brief and free of extraneous words. However, it is a sentence fragment rather than a complete declarative sentence, which slightly reduces clarity.

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, the description should clarify what 'usage stats' includes (e.g., bytes used, file count, quota). It does not, leaving the agent without essential context about the return value.

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, so there is no parameter semantic burden. The schema coverage is effectively 100% by virtue of having no properties. A baseline of 4 is appropriate since there is nothing to explain.

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 'User Drop usage stats' identifies the resource (Drop usage) and scope (user-level), which distinguishes it from the sibling org_drop_usage. Although it lacks an explicit verb like 'get' or 'list', the noun 'stats' strongly implies retrieval.

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. It does not mention similar tools such as org_drop_usage or any conditions for use.

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, but the description adds complementary behavioral context: it is public (no auth) and covers three specific health indicators. This goes beyond the annotations and informs the agent that this is a safe, unauthenticated call.

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, well-structured sentence that front-loads the action ('Check') and packs all essential details (liveness, readiness, build version, public, no auth) with zero 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?

For a simple, parameter-less health-check tool, the description is complete: it names what is checked and the authentication requirement. No output schema is provided, but the description implies the result includes these health metrics, which is sufficient for the tool's 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?

With zero parameters and 100% schema coverage, there is no parameter information to add. The description does not need to explain parameter semantics, and no parameters are left undocumented.

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 with a specific verb ('Check') and distinct resources ('gateway liveness, readiness, and build version'). It fully separates this tool from any sibling tools, none of which perform health checks.

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 a use case: checking gateway health without authentication. It adds the context 'public, no auth', which helps agents decide when to use it. There are no alternative health-check tools among siblings, so no explicit exclusion is 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?

With annotations already marking readOnlyHint=true, the description adds valuable behavioral context: it does not SSH (no remote execution) and requires a registration token. This goes 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?

Two short sentences front-load the core purpose and key constraints with no wasted words. Efficient 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?

With 8 parameters and no output schema, the description is too sparse. It does not explain what the 'port checklist' contains, how the command is formatted, or what the return structure looks like, leaving significant gaps for a tool of 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?

Schema description coverage is 0%, so the description must compensate. It only clarifies the 'registration_token' parameter, leaving the other 7 parameters (zone, region, profile, node_name, etc.) unexplained in the 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 clearly states it 'Build install command + port checklist', specifying a concrete verb and resource. This distinguishes it from sibling tools like node_registration_token_create (which creates a token) and org_nodes_list (which lists nodes).

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 non-usage context via 'Does not SSH', indicating it is for planning rather than executing remote commands. Also states the prerequisite 'Needs a registration token string', giving clear guidance on when to use it.

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

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

Given annotations are minimal (only openWorldHint), the description carries the burden. It discloses 'Returned once' and 'Requires user session,' which are important behavioral details beyond what annotations provide. However, it omits potential side effects, error conditions, or idempotency, so coverage is moderate.

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. Every word contributes purpose or critical behavioral nuance, making it highly efficient.

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 tool has four parameters, no output schema, and minimal annotations. The description only covers purpose and one behavioral trait, leaving the agent without essential context on parameters, return value structure, or error handling. It is incomplete for a tool of 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?

Schema description coverage is 0%, with four parameters (org_id, scopes, peer_id, ttl_hours) lacking any descriptions. The tool description does not compensate for this by explaining parameter meaning or relationships, leaving the agent entirely uninformed about how to fill these fields.

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 ('ere_reg_* token for node install'), which clearly distinguishes it from sibling tools like node_install_plan and apikey_create. The purpose is unambiguous and directly tied to the tool name and title.

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 usage for node install and requires a user session, providing context but no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions or direct siblings like apikey_create, so usage guidelines are 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds the HTTP GET method, reinforcing the read-only nature. However, it doesn't disclose pagination, response format, or any rate limits. Since annotations cover the safety profile, a 3 is appropriate.

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

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

The description is a single sentence with no wasted words, and it front-loads the core information (public node directory) followed by the endpoint. 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?

For a tool with one optional parameter and no output schema, the description is too sparse. It fails to explain the parameter, expected response structure, or any filtering behavior. Annotations provide some safety context, but the description lacks enough detail for reliable 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 description completely ignores the 'region' parameter. With schema description coverage at 0%, the description should explain what the parameter does, but it does not. The agent is left to guess that 'region' is a geographic filter, which is not guaranteed.

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 identifies the tool as a public node directory and provides the GET endpoint, making it distinct from sibling tools like org_nodes_list or operator_nodes_list. However, it uses a noun phrase rather than an explicit verb like 'list' or 'fetch', so the action is slightly implicit.

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

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

There is no guidance on when to use this tool versus alternatives such as org_nodes_list or operator_nodes_list. The word 'Public' implies it covers public nodes, but no explicit exclusions or alternative references 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?

Annotations already declare readOnlyHint and openWorldHint. The description adds value by revealing that the result includes private nodes and is scoped to the caller's orgs, which clarifies the exact result set beyond the structured fields.

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, direct sentence conveys scope and inclusion without wasted words. The information is front-loaded and easy to parse.

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

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

For a parameterless, read-only listing tool, the description adequately defines the resource and its scoping. It does not describe the return structure, but no output schema exists and the annotations cover the read-only safety profile, so the description is sufficiently complete for its 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?

There are zero parameters, so the description carries no parameter burden. The baseline for parameterless tools is 4, and the description correctly makes no parameter claims.

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 returns 'Runtime VPN nodes for orgs the caller belongs to (includes private)', explicitly scoping to caller membership and private inclusion. This distinguishes it from per-org siblings like org_nodes_list, giving a specific verb+resource+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?

Usage context is implied by the phrase 'for orgs the caller belongs to', suggesting use for a multi-org or operator-level listing. However, there is no explicit mention of alternatives or when-not-to-use, such as 'use org_nodes_list for a specific org'.

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 caller becomes owner and that authentication is required, which adds value beyond the sparse openWorldHint annotation. However, it does not cover other behavioral aspects like idempotency, side effects, or error conditions, so the transparency is partial.

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 one concise sentence that front-loads the core purpose and includes essential context (ownership, auth). No wasted words, and the structure is ideal for quick comprehension.

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 two-parameter creation tool with no output schema, the description covers the essential points: what it does, the ownership consequence, and authentication requirement. It does not mention return value or edge cases, but these are less critical given the simplicity and lack of 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%, with both 'name' and 'slug' already having descriptions in the schema. The description text adds no additional parameter semantics, so the baseline score of 3 applies.

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

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

The description clearly states the action ('Create an organization') and adds a key consequence ('caller becomes owner'), which differentiates it from listing or retrieving tools like org_list and org_get. The verb and resource are specific and not a tautology.

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 usage by being the only creation tool among siblings, and it provides a prerequisite ('Requires user session/Bearer'). However, it does not explicitly mention when to use it versus alternatives or when not to use it, so the guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the org-scoping context and the endpoint, but does not disclose additional behavioral traits such as pagination, response format, or rate limits. With annotations doing the heavy lifting, this is adequate but not enriched.

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 that states the purpose and endpoint without wasted words. Every element 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?

Given a single parameter, no output schema, and good annotations, the description is minimally viable for a simple list operation. However, it lacks any mention of pagination, response fields, or how it differs from drop_files_list, leaving some gaps for a fully informed agent.

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 one parameter, org_id, with no description (coverage 0%). The tool description does not explain org_id directly, only implying it through 'Org-scoped' and the '{id}' placeholder in the endpoint. This adds little beyond the parameter's self-explanatory name.

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 lists org-scoped Drop file metadata, with the specific verb 'list' and resource 'Drop file metadata'. The endpoint 'GET /orgs/{id}/drop/files' further specifies the exact operation. The 'Org-scoped' qualifier distinguishes it from the sibling drop_files_list, which likely operates at a different 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?

The description explicitly notes the org-scoped nature, providing clear context for when to use this tool (when needing files belonging to an org). However, it does not name alternative tools like drop_files_list or provide explicit 'when not to use' guidance, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds the org-scoped scope and endpoint, which is useful context, but does not disclose any additional behaviors such as pagination, rate limits, or response shape. This mirrors the 'high' example where annotations plus scope earned a 3.

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 the key term front-loaded and the endpoint provided for reference. It contains no wasted words and is appropriately concise for the tool's simplicity.

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 tool is simple, with one parameter and a clear GET endpoint. The description gives enough context for an agent to select and invoke it correctly. However, with no output schema, it would be slightly stronger to mention what the usage data includes (e.g., bytes, count), so it stops short of a 5.

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 0% with one org_id parameter. The description compensates somewhat by showing the endpoint /orgs/{id}/drop/usage, implying org_id maps to {id}. The parameter name itself is self-explanatory, but the description does not provide extra detail like format or constraints, so a baseline 3 is appropriate.

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

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

The description clearly states it retrieves org-scoped Drop usage, with the specific endpoint GET /orgs/{id}/drop/usage. The 'Org-scoped' qualifier distinguishes it from general org_usage and drop_usage siblings, making the resource and scope 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?

The description implies use for org-level Drop usage but does not explicitly mention when to use it over sibling tools like org_usage or drop_usage, nor does it state any exclusions. The org-scoped wording gives a hint, but no direct guidance on tool selection is provided.

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 openWorldHint=true, and the description adds no further behavioral context. It does not disclose what is returned, whether permissions are needed, or any side effects. While it does not contradict the annotations, it adds no value beyond them.

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, compact sentence with no redundant wording. It is front-loaded with the key concept, though the brevity does border on under-specification. Still, as far as conciseness goes, it is appropriately small.

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 simple one-parameter tool, no output schema, and sparse description, the agent is left without context about return values or what constitutes an 'entitlement' or 'limit'. The description is too minimal to fully guide correct invocation and interpretation.

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 0%, and the description does not explicitly describe the 'org_id' parameter. The phrase 'for an org' weakly implies the parameter identifies an organization, but this is insufficient compensation for the complete lack of parameter documentation in both the schema and 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 'Plan entitlements / limits for an org.' identifies the resource (entitlements/limits) and scope (an org), but the verb 'Plan' is ambiguous—it could mean retrieving or configuring. It does not clearly state an action like 'get' or 'list', making it less distinguishable from siblings such as org_usage.

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 like org_usage or org_get. There are no stated exclusions or alternative tool references, leaving the agent to infer from the name alone.

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 the description simply says 'Get', which is consistent but adds no new behavioral context. No additional traits like return format, side effects, or auth requirements are disclosed. With the annotations in place, the description contributes nothing beyond what structured data already provides.

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

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

The description is a single, direct sentence ('Get one organization by id.') with zero filler. It is front-loaded and 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?

For a simple read-only getter with one optional parameter and no output schema, the description is sufficient. The tool's name and schema cover the essential details. It does not explain the return value, but given the simplicity and the read-only annotation, this is a minor gap rather than a critical omission.

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% with org_id fully described, including the default behavior. The description itself adds no parameter semantics beyond the schema. This matches the baseline of 3 for high 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 states a specific verb ('Get') and resource ('organization') with a clear identifier ('by id'). It clearly distinguishes from sibling tools like org_list (which lists organizations) and org_create (which creates), 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 context is implied: use this when you have an org id to retrieve a single organization. However, there is no explicit when-not-to-use guidance or mention of alternatives (e.g., 'use org_list to list all organizations'). The description does not state exclusions or prerequisites beyond the id.

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 and openWorldHint, so the safety profile is covered. The description adds the 'for the authenticated user' scope, but does not mention return format or pagination. No contradictions with 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 sentence, front-loaded with the action and resource, and contains no unnecessary 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?

The tool is simple with no parameters and no output schema, and annotations cover safety and open-world behavior. The description fully explains the operation and scope.

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?

There are zero parameters and schema coverage is 100%, so no parameter details are needed. The description correctly avoids repeating schema information.

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 'List organizations' which specifies the verb and resource, and scopes to 'for the authenticated user'. This distinguishes it from sibling tools like org_create and org_get, which involve different actions.

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 use when needing all organizations for the current user, with the scope 'for the authenticated user' providing clear context. It doesn't explicitly name alternatives like org_get, but the list-vs-get distinction is evident from the title.

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, and the description's 'Get' aligns with a read-only operation. However, the description adds no extra behavioral context such as error handling, return format, or what the openWorldHint implies, so it provides limited value beyond 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?

One concise sentence, front-loaded with the action 'Get', and no wasted words. The structure is optimal for the tool's simplicity.

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 low-complexity read-only get, the description is functional, but it leaves gaps around org_id, return value (no output schema), and how this differs from org_get or org_nodes_list. These omissions make it only minimally complete for an agent.

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 says 'by id' without explicitly naming node_id or explaining the role of the optional org_id. The agent must infer that node_id is the identifier, and org_id's purpose remains completely undocumented.

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 'Get one org control-plane node by id' uses a specific verb and resource, clearly distinguishing it from sibling tools like org_get (getting an org) and org_nodes_list (listing nodes). It explicitly states the operation scope (one node by id).

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

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

There is no explicit when-to-use or alternative guidance. The description implies fetching a single node when an id is available, but it does not contrast with org_nodes_list or mention when to prefer this tool over others.

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 annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds only the scoping phrase 'registered to the org control plane,' but does not disclose other behavioral traits such as pagination, filtering defaults, or return format.

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 concise sentence that front-loads the action and object. It contains no filler or redundant information, exactly the appropriate size for this simple 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?

For a simple read-only list tool with one optional parameter and no output schema, the description is minimally viable. It states the core purpose but lacks parameter semantics and return value structure, which are not covered elsewhere. Given the presence of multiple node-list sibling tools, 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?

The schema has 0% description coverage for org_id, and the description does not explain what org_id does or how it affects listing. The parameter name offers some clue, but the description fails to compensate for the missing schema details, leaving ambiguity about optionality or filtering 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 uses a specific verb 'List' and a clear resource 'nodes registered to the org control plane,' which distinguishes it from sibling tools like operator_nodes_list and nodes_directory. It clearly states what the tool 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?

The description provides no guidance on when to use this tool versus alternatives such as operator_nodes_list or nodes_directory. It does not mention scenarios, exclusions, or preferred contexts, leaving the agent with only the tool name and sibling names as hints.

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 readOnlyHint annotation, the description reveals the authentication mechanisms (X-Api-Key vs user Bearer) and how the tool routes based on org_id. This adds useful behavioral context. It does not describe response format, but the read-only safety is already declared by 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 sentence of 21 words, directly states the tool's purpose, and front-loads the key term 'Org usage'. There is no fluff or repetition, making it highly concise and well-structured.

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, the description carries the burden of explaining return values, but it does not describe what usage data is returned or its structure. It does cover the two auth modes and endpoints well. Given the simplicity of the tool and the clarity of the parameters, it is adequate but has a clear gap in response expectations.

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 already provides full descriptions for both parameters (org_id and period), covering 100% of the schema. The tool description essentially restates the org_id routing behavior found in the schema, adding no new semantic information beyond what the schema already provides. Baseline for full coverage is 3.

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 identifies the resource (org usage) and provides exact endpoints for two authentication modes, which distinguishes it from tools like org_get. It lacks an explicit verb like 'get' or 'list' but the intent is unambiguous. It does not explicitly distinguish from sibling usage tools like drop_usage, but the endpoint details help.

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 conditions for use: if org_id is set, use user Bearer on /orgs/{id}/usage; otherwise use org API key for self usage. This provides clear when-to-use guidance. It does not mention alternatives or exclusions, but the two-mode guidance is valuable for an agent.

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 only the openWorldHint annotation (indicating mutation), the description adds valuable context about the required API key, the X-Api-Key header, and the ownership constraint. This goes beyond the annotation, though it does not explain return values or side effects, which are not covered by 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 three concise sentences with no filler. Each sentence provides essential information: the route, the required environment variable, and a critical precondition. It is well-structured and 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?

While the description covers the endpoint and authentication, it omits parameter semantics, return value, and how it differs from the non-org vpn_client_create. Given the tool has 4 parameters and no output schema, these gaps make it incomplete for an agent to invoke 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 provides 0% description coverage, and the description does not explain any of the four parameters (name, node_id, wg_public_key, wg_preshared_key). Since the description must compensate for the lack of schema descriptions but does not, it fails to add meaning to the 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 states the specific verb 'Provision' and the resource 'VPN client' via the org API key route POST /api/v2/org/vpn/clients. It clearly distinguishes from sibling tools like vpn_client_create by emphasizing the org-level route and authentication method.

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: it requires EREBRUS_API_KEY and specifies that the node must belong to the key's org, implying this is for org-level provisioning. However, it does not explicitly mention when to use this over the non-org vpn_client_create or exclude other contexts, stopping short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the endpoint and the org-scoping, which is useful context. However, it does not disclose pagination, response shape, or any behavioral details beyond 'list clients', so it falls short of rich transparency.

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, compact sentence that front-loads the action ('List clients') and includes the endpoint. 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?

For a zero-parameter, read-only list operation with an explicit endpoint, the description is largely sufficient. It clearly states what the tool does and its scope. However, since there is no output schema, the description could have elaborated on the returned data shape, but this is a minor gap given the tool's 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?

There are zero parameters, and the schema coverage is trivially 100%. The baseline for no parameters is 4. The description adds meaning by implying that the API key provides the org context, so no additional arguments are needed. It does not attempt to describe nonexistent 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 uses the specific verb 'List' with a precise resource ('VPN clients') and clearly scopes it to 'the API key's org'. This distinguishes it from sibling tools like vpn_client_list and org_list. The endpoint is also included, removing any ambiguity.

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

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

The phrase 'for the API key's org' provides clear context for when to use this tool: when you need clients belonging to the org associated with the API key. It does not explicitly mention alternatives like vpn_client_list or when not to use it, but the scope is unambiguous enough to guide selection.

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 include openWorldHint, so the description adds some behavioral context by specifying authorization requirements. However, it does not disclose side effects beyond provisioning (e.g., idempotency behavior, whether existing configurations are overwritten) or mention the optional idempotency_key param, which could affect 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 with no redundant phrasing. It front-loads the core purpose and efficiently lists requirements and membership constraints. Every sentence adds useful 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 there is no output schema and moderate complexity (5 params), the description covers the basic action and requirements but omits optional params, return value expectations, or how to subsequently retrieve the client config (e.g., via vpn_client_get_config). The description is adequate but not fully complete for a provisioning 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 60%, so the description carries moderate responsibility. It reiterates the three required parameters (name, node_id, wg_public_key) but adds little beyond the schema. The optional parameters (idempotency_key, wg_preshared_key) remain undocumented in both schema and description, so the description does not fully compensate for the missing semantics.

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

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

The description clearly states the action ('Provision a VPN client'), the target ('on a node'), and lists the required inputs. This differentiates it from sibling tools like org_vpn_client_create, which likely operates at the organization level, by emphasizing node-level provisioning.

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 context about membership prerequisites ('User needs org membership (public nodes) or node org membership (private)') but does not explicitly differentiate when to use this tool vs. alternatives like org_vpn_client_create or vpn_client_delete. No direct 'use this when...' guidance is 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?

The annotations already indicate destructiveHint=true, and the description adds no extra behavioral context beyond the literal 'Delete'. It does not disclose permanence, side effects, permissions, or any irreversibility, which is expected for a delete 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 fluff. It is concise but lacks valuable context, so it earns points for structure but not content.

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 delete-by-id tool with destructive annotation, the description is minimally viable. However, it omits important contextual details such as scope (user vs org), side effects, and usage prerequisites, leaving the agent to infer too much.

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 provides no parameter description (coverage 0%), and the description only mentions 'by id' without further elaboration. It does not explain where to obtain the client_id, its format, or any constraints beyond the schema's minLength=1.

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 action ('Delete') and resource ('VPN client') with the method ('by id'). It distinguishes from sibling create/list tools, but does not specify whether this targets a user-level or org-level client, which is a potential ambiguity given the sibling org_vpn_client_* 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?

No guidance is provided on when to use this tool versus alternatives, nor any cautionary notes about the destructive nature. The description simply restates the action without contextual instructions.

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 the description's 'Fetch' aligns with that. It adds context by specifying the config type (WireGuard/credentials) and access restriction (owner/admin), which is useful beyond the annotations. It doesn't describe return format, but the read-only nature is clear.

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 with the verb and resource, with no redundant wording. 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?

For a simple read tool with one parameter and no output schema, the description is mostly complete, giving the credential type and access context. It lacks guidance on how to obtain the client_id or what the response contains, but overall it is sufficient for a basic fetch operation.

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 should compensate by explaining the client_id parameter, but it does not. The parameter is named clearly, but the description adds no meaning about its format, source, or relationship to VPN clients, leaving the agent to infer.

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 specific verb 'Fetch' and identifies the resource as 'WireGuard/credentials config for a client,' which clearly distinguishes it from sibling tools like vpn_client_list that simply list clients. The scope restriction (owner/admin) adds further specificity.

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 this tool is for retrieving a specific client's config, but it does not explicitly mention when to use it over related tools like vpn_client_list or org_vpn_client_list. No exclusions or alternatives are named, leaving the agent to infer the appropriate 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 mark this as read-only and open-world, covering safety. The description adds the Bearer session requirement and user scope, which is useful context, but it lacks details on pagination or return format. Given the annotations, this is sufficient but not rich.

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, focused sentence that concisely conveys the purpose and scope without any unnecessary words. It earns 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?

This is a simple list operation with no parameters and no output schema. The description adequately explains what the tool does and the scope, making it complete for an agent to understand its 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?

The tool has no parameters, so the schema fully covers parameter semantics. The description does not need to explain parameters, and the baseline of 4 is appropriate for zero-parameter tools.

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 action ('List'), the resource ('VPN clients'), and the scope ('for the authenticated user'), which distinguishes it from org_vpn_client_list. This is a specific and unambiguous purpose.

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 that this lists the authenticated user's own VPN clients, contrasting with org-level clients. However, it does not explicitly mention when to use an alternative like org_vpn_client_list, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds useful context about token sources (MCP session token or EREBRUS_BEARER_TOKEN) and the unauthenticated response behavior, going beyond the annotations without contradiction.

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

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

The description is concise and front-loaded with the main purpose, followed by token usage and unauthenticated behavior. Every sentence earns its place with no fluff.

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 parameters and no output schema, the description fully covers the tool's behavior: what it returns when authenticated and what happens when unauthenticated. It is complete for the tool's 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?

The tool has zero parameters, so the baseline is 4. The description provides no parameter-specific information, which is fine since the schema is empty and coverage is 100%.

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: returning the authenticated user's profile. It distinguishes itself from sibling auth tools by focusing on the current user's identity, and the mention of unauthenticated behavior adds clarity.

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 this tool (to get the authenticated user's profile) and notes the token sources, but it does not explicitly contrast with alternatives like auth_status. However, the context is clear enough for a simple tool.

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