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

The description adds useful context about the return values and how to interpret remaining_seconds, but beyond that it mainly restates the read-only nature already captured by readOnlyHint=true. No hidden side effects, permissions, or rate limits are disclosed, so it adds limited extra 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 two sentences, front-loaded with the core function and includes only actionable information. It is appropriately sized for 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?

For a single-parameter read tool with readOnlyHint and no output schema, the description adequately covers the return values and provides actionable guidance on using remaining_seconds. It lacks error handling details, but that is not critical for basic 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 input schema already fully describes the name parameter with details on exact, case-sensitive matching. The description reinforces this but does not add new meaning beyond the schema, aligning with the baseline for 100% 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 clearly states 'Get the current TOTP code for a vault login item with TOTP configured,' specifying the verb, resource, and condition. It also lists the return fields, distinguishing it from sibling tools like save_login_item or reveal_secret_via_send.

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 for vault login items with TOTP configured, and advises using remaining_seconds to decide when to use the code. However, it does not explicitly mention alternatives or when-not-to-use, so it falls short of a full 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?

Despite annotations (readOnlyHint=true, openWorldHint=true) already indicating a safe read-only operation, the description adds valuable behavioral context: it enumerates the exact metadata fields returned and explicitly states that sensitive values (password, TOTP seed, api-key) are never included. This is a significant transparency addition beyond the annotations, with no contradictions.

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 sentences, front-loaded with the primary action and return list, followed by a clear exclusion and alternative. Every word earns its place, with zero 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?

With no output schema, the description fully carries the burden of explaining return values and limitations. It comprehensively covers what is returned, what is never returned, and directs to appropriate sibling tools. For the tool's simplicity, this is complete and actionable.

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

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

The schema already provides 100% coverage for the single 'name' parameter, including case-sensitivity and exact match semantics. The description does not add further parameter-level detail beyond referencing a 'named vault item,' so the baseline score of 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 the tool's purpose: 'Get full metadata for a named vault item.' It lists specific returned fields (name, type, username, URIs, custom fields, scope, expiry) and explicitly differentiates itself from sibling tools by noting secrets are not returned. This is a specific verb+resource with strong sibling differentiation.

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

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

The description provides explicit when-to-use guidance by naming alternatives: 'use reveal_secret_via_send or get_totp_code instead' for password, TOTP seed, and api-key values. It also states what the tool does not return, giving clear exclusions. This goes beyond a simple context hint to full usage direction.

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, so the agent knows it is a safe read operation that may access external systems. The description adds behavioral details beyond annotations: it 'Authenticates, syncs, and reports' specific metrics, implying network calls and credential verification. It doesn't describe error behavior or side effects, but for a health check with annotations, this is adequate.

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: the first states what it does and what it reports, the second gives when to use it. Every word earns its place; there is no filler, redundancy, or irrelevant detail. The structure is front-loaded with the core purpose and outputs.

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 with no parameters and no output schema, the description covers the necessary context: what it checks, what it reports, and when to run it. It could be slightly more explicit about interpreting results or potential error states, but it is sufficient for an agent to understand the tool's role and invocation timing. The list of reported metrics adds completeness beyond a generic 'health check'.

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 schema already fully covers them (coverage 100%). Per the baseline for no params, a score of 4 is appropriate; the description doesn't need to document parameters. It does not add any param-specific semantics, but that's not a gap given 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 checks connectivity and configuration of the Bitwarden/Vaultwarden vault, with a specific verb ('Check') and resource. It enumerates concrete outputs (auth status, API version, collection visibility, item counts, latency), which distinguishes it from sibling tools that list, get, reveal, generate, or save items. This is a focused diagnostic tool, easily differentiated from the other operations.

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

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

The description explicitly says 'Run this first after a new install or after rotating credentials,' giving clear when-to-use guidance. Although it doesn't name alternatives, it establishes a recommended ordering (run first) and the context (new install, credential rotation), which is sufficient for an agent to decide when to invoke 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?

Annotations already declare readOnlyHint=true, but the description adds important behavioral context: the tool returns metadata only and never includes secret values. This goes beyond the annotation hint and clarifies the safety boundary, though it does not specify pagination or output shape.

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 concise sentences. The first sentence states the action and scope, and the second provides an essential safety caveat and pointer to the alternative tool. No wasted words.

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

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

For a read-only listing tool with no required parameters and no output schema, the description adequately covers what the tool does, what it returns, and how to get the actual secret values. Additional details would be marginal for this low-complexity tool.

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

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

The schema already covers both parameters fully with descriptions for filter and collection (100% coverage). The description restates the collection names and the filter concept but adds no new parameter-level detail beyond what the schema provides, so the baseline of 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 begins with the specific verb 'List vault items' and clearly specifies the resource scope (mcp-exposed and mcp-agent-created collections). It also distinguishes this tool from the sibling reveal_secret_via_send by stating that metadata only is returned and secret values are never included.

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 states when not to use this tool—when actual secret values are needed—and names the alternative tool, reveal_secret_via_send. It also clarifies the collection scope and that filtering is available, giving context for typical 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?

The description discloses critical behavioral traits beyond annotations: client-side encryption, URL fragment never sent to the server, READ_ONLY blocking, and DRY_RUN logging. This adds substantial value beyond the sparse annotations (readOnlyHint=false, openWorldHint=true) and fully informs the agent of side effects and constraints.

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

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

The description is four sentences, front-loaded with the core purpose, and each sentence delivers meaningful behavioral or operational detail without redundancy. It is concise yet comprehensive.

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 thoroughly covers behavior, restrictions, and encryption details, but it omits any mention of the tool's output or return value (e.g., the Send URL or confirmation). Since there is no output schema, this is a notable gap that prevents full 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 input schema already provides complete parameter descriptions with defaults, ranges, and field options (100% coverage). The description only generically mentions 'configurable TTL and max-views limit' without adding any new semantic detail, so the baseline 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 states a specific verb ('Reveal') and resource ('vault secret through a Bitwarden Send'), clearly distinguishing it from sibling tools like get_totp_code or list_vault_items. The purpose is immediately understandable and unique.

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

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

The description gives clear context for when to use the tool (creating a one-time E2E-encrypted URL to reveal a secret) and even notes edge cases like READ_ONLY and DRY_RUN. However, it does not explicitly mention alternatives or when not to use it, so it lacks full exclusionary guidance.

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

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

The description goes well beyond annotations by disclosing E2E encryption, automatic custom field setting, collision errors, READ_ONLY blocking, and DRY_RUN logging. This gives rich behavioral context that annotations alone do not provide. No contradiction with annotations (readOnlyHint=false matches write 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 well-structured paragraph that front-loads the primary purpose, then efficiently adds constraints and side effects. Every sentence adds value, with no filler or redundancy. It is concise yet comprehensive.

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 most important aspects: purpose, constraints, side effects, and error behavior. It lacks explicit mention of return value or success response, which is notable since no output schema exists. However, for a save tool, the return value may be implicitly understood, so this is a minor 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?

Schema description coverage is 100%, so per rubric baseline is 3. The description adds some context about automatic custom fields (mcp-expires-at, mcp-used-in) but does not significantly enhance parameter understanding beyond the schema. It repeats some schema info but does not compensate for any missing details.

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 saves an agent-generated secret into the mcp-agent-created collection, with specific resource scope. However, it does not explicitly distinguish itself from the sibling tool 'save_login_item', so it lacks explicit sibling differentiation. The verb 'Save' and resource are specific.

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 CREATE-only and cannot overwrite, and it mentions conditions like READ_ONLY=1 and DRY_RUN=1. It does not explicitly name alternatives but implies usage for new secrets only, which is clear enough 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?

The description discloses important behavioral traits: it is CREATE-only and cannot overwrite, it requires at least one of username/password, it sets custom fields automatically, it encrypts all fields E2E, it is blocked under READ_ONLY, and it logs to DRY_RUN without creating a real cipher. The readOnlyHint: false annotation is consistent with the description's CREATE-only nature, and the description adds significant context beyond the annotation.

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

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

The description is dense but well-structured. It front-loads the core purpose, then provides usage guidance, constraints, security context, and environmental behavior in a logical order. It is slightly longer than ideal but every sentence adds value, covering purpose, sibling differentiation, CREATE-only limitations, field requirements, encryption, custom fields, and mode-specific behavior.

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 8 parameters and no output schema, the description covers all essential aspects: what it does, when to use it, what constraints apply, what happens in different modes (READ_ONLY, DRY_RUN), and how it integrates with other tools (get_totp_code). It also explains the custom fields it sets automatically, which is valuable context for the agent. No significant gaps remain.

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%, and the description enriches the parameters further. For example, it explains that 'uri' is the login URL, 'totp' enables get_totp_code support, and 'expires_in_days' sets the mcp-expires-at field. It also clarifies constraints like case-sensitive uniqueness for 'name' and the mutual exclusivity/requirement of username/password. The description also mentions automatic custom fields, which adds meaning to parameters like 'used_in'.

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

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

The description clearly states the tool's purpose: saving login credentials as a Vaultwarden login item. It specifies the resource (Vaultwarden, mcp-agent-created collection), the verb (save), and the exact field types (username, password, URL, TOTP seed). It also explicitly distinguishes itself from the sibling tool save_generated_secret.

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

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

The description provides explicit guidance on when to use this tool: 'Use this instead of save_generated_secret when the credential is a sign-in (username + password), so it surfaces as a real login item with get_totp_code support.' It also mentions constraints such as CREATE-only and name collision behavior, and notes that it is blocked when READ_ONLY=1.

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