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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: locking the session, cleaning up secrets from disk, and displaying a goodbye message. However, it doesn't mention potential side effects like irreversible session termination or whether user confirmation is required.

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 perfectly concise and well-structured in two sentences. The first sentence explains what the tool does, and the second provides usage guidance. Every word earns its place with no redundancy or unnecessary 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 zero-parameter tool with no annotations and no output schema, the description provides sufficient context about what the tool does and when to use it. However, it doesn't specify what happens after execution (e.g., whether the session can be restored or if this triggers a complete shutdown), leaving some behavioral questions unanswered.

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 0 parameters with 100% schema description coverage. The description appropriately doesn't discuss parameters since none exist, maintaining focus on the tool's action. A baseline of 4 is applied for zero-parameter tools when the description adequately explains the tool's function.

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 specific verbs ('End', 'Locks', 'cleans up', 'says goodbye') and identifies the resource ('work session'). It distinguishes itself from sibling tools like 'sleep-session' or 'wake-session' by indicating a permanent termination rather than temporary suspension.

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 to use this tool: 'Use this when you finish working for the day.' This provides clear context for usage and implicitly distinguishes it from alternatives like 'sleep-session' (for temporary breaks) or 'session-status' (for checking state).

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

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

With no annotations provided, the description carries full burden but lacks critical behavioral details. It mentions name/tag coexistence but doesn't disclose permissions needed, whether creation is idempotent, rate limits, encryption methods, or what happens on success/failure. For a secret-creation tool with zero annotation coverage, this leaves significant gaps.

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—a single sentence that directly states the tool's purpose and a key behavioral nuance. It's front-loaded with the main action and wastes no words, making it easy to parse quickly.

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 secret-creation tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what a 'secret' is in this context, how values are stored/encrypted, what the response looks like, or error conditions. The single behavioral note about name/tags doesn't compensate for the missing 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?

Schema description coverage is 100%, so parameters are well-documented in the schema itself. The description adds minimal value beyond the schema—it only hints at the 'tags' parameter's purpose with 'env tags' but doesn't explain other parameters or provide additional context like format examples beyond what's in schema descriptions.

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 a new secret') and specifies the resource ('secret'), making the purpose immediately understandable. It distinguishes from siblings by mentioning uniqueness rules (same name with different env tags), though it doesn't explicitly contrast with tools like 'update-secret' or 'renew-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 implies usage when creating secrets, particularly with the note about name/env tag coexistence, but doesn't provide explicit guidance on when to use this versus alternatives like 'update-secret' or 'import-env'. No prerequisites, exclusions, or clear context for tool selection are mentioned.

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

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

With no annotations provided, the description carries full burden and adds valuable behavioral context beyond the basic 'delete' operation. The 'soft delete, can be recovered' disclosure is crucial information about the tool's behavior that isn't evident from the name or schema alone. However, it doesn't mention permissions needed, rate limits, or what happens to associated resources.

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?

Extremely concise single sentence that front-loads the core action ('Delete a secret') followed immediately by crucial behavioral context ('soft delete, can be recovered'). Every word earns its place with zero wasted text 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 deletion tool with no annotations and no output schema, the description provides essential context about the soft-delete behavior. However, it doesn't mention what the tool returns (success confirmation, error conditions) or provide guidance on recovery procedures, which would be helpful given the tool's destructive nature.

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 schema already fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter 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 specific action ('delete') and resource ('a secret'), and distinguishes it from siblings like 'get-secret' or 'update-secret' by specifying the deletion operation. It also adds important nuance with 'soft delete, can be recovered' which differentiates it from a permanent deletion tool.

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

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

The description implies usage context through 'soft delete, can be recovered' suggesting this should be used when reversible deletion is needed, but doesn't explicitly state when to use this vs alternatives like permanent deletion tools or when not to use it. No specific prerequisites or comparisons to sibling tools are 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?

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions that values are 'decrypted' (implying a security-sensitive operation) and returns 'full content', but doesn't address critical aspects like required permissions, rate limits, whether this exposes sensitive data, or if the export is downloadable vs. displayed. For a tool handling secrets, this is a significant gap.

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 core purpose. However, it could be slightly more structured by separating format options from the decryption note, and it lacks any preamble about security implications.

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

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

Given the tool's complexity (handling secrets with decryption, multiple formats, filtering), no annotations, and no output schema, the description is minimally adequate. It covers what the tool does and the output format, but misses important context like security warnings, permission requirements, and how the output is delivered (e.g., file vs. text).

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 schema already fully documents both parameters (format with enum values, tags as object). The description adds no additional parameter semantics beyond what's in the schema, such as explaining tag filtering logic or format differences. Baseline 3 is appropriate when schema does all the work.

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 exports secrets in specific formats (.env or CSV) with decrypted values, providing a specific verb ('Export') and resource ('secrets'). However, it doesn't explicitly differentiate from sibling tools like 'list-secrets' or 'get-secret', which might offer different views of the same data.

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 'list-secrets' (which might show metadata without decrypted values) or 'import-env' (the inverse operation). The description mentions filtering by tags, but doesn't explain when this filtering is appropriate or what happens without 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?

Without annotations, the description carries full burden and provides good behavioral context: declares it's 'Read-only' (safety profile), explains that rules can only be modified elsewhere (important constraint), and states the practical use case for understanding blocked access. It doesn't mention rate limits or pagination behavior, but covers the essential operational context.

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

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

Two sentences with zero waste - first sentence states purpose and constraints, second provides usage guidance. Every word earns its place, and the information is front-loaded with the core functionality.

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 tool without annotations or output schema, the description provides excellent context: purpose, behavioral constraints (read-only, dashboard-only modification), and practical use case. It could mention what the output looks like (list format, rule structure) but covers the essential information well 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?

With 0 parameters and 100% schema coverage, the baseline is 4. The description appropriately doesn't discuss parameters since there are none, and instead focuses on the tool's purpose and usage context, which is the right approach for a parameterless tool.

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

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

The description clearly states the tool's purpose with specific verb ('List') and resource ('active MCP access rules'), and distinguishes it from siblings by focusing on access rules rather than secrets or sessions. It explains what the tool does in concrete terms.

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

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

Explicitly states when to use this tool ('to understand why access to a secret was blocked') and provides important context about when NOT to use it ('rules can only be created or modified from the dashboard'), clearly differentiating it from rule-creation tools that don't exist in the sibling list.

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

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

With no annotations provided, the description carries full burden and effectively discloses key behaviors: default injection into local files (hiding values from conversation), audit logging for reveal actions, and cleanup functionality. It doesn't mention error handling, permissions, or rate limits, but covers the main operational traits.

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

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

Three sentences with zero waste: the first states the purpose, the second explains the default and reveal option, and the third covers cleanup. Each sentence adds critical information, making it efficiently 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?

Given no annotations and no output schema, the description does well by explaining the tool's behavior (injection, auditing, cleanup). However, it lacks details on return values or error cases, which could be important for a secret-management tool, leaving minor gaps in 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?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds context for reveal and cleanup (e.g., 'audited as conscious action'), but doesn't provide significant additional meaning beyond the schema's details, meeting the baseline for high coverage.

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

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

The description clearly states the verb ('Get') and resource ('a secret by name'), distinguishing it from siblings like list-secrets (which lists) or create-secret (which creates). It specifies the core action of retrieving a secret, 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?

It provides explicit guidance on when to use reveal:true (to see raw values) versus the default (inject mode), and includes cleanup:true for removing injected files. This covers both usage scenarios and alternatives within the tool, though it doesn't compare to other tools like list-secrets.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that this is a read-only operation that returns account metadata, and implies it's a diagnostic/status-checking tool. However, it doesn't disclose potential rate limits, authentication requirements, or whether this operation has any side effects, leaving some behavioral aspects unclear.

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 perfectly concise with two sentences that each earn their place. The first sentence states the purpose and enumerates the returned data. The second sentence provides valuable usage context. There's zero wasted verbiage or repetition.

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

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

For a zero-parameter diagnostic tool with no annotations and no output schema, the description does an excellent job explaining what the tool returns and when to use it. However, without an output schema, the description could more explicitly detail the structure of the returned status information (e.g., whether it's a JSON object with specific fields). This minor gap prevents a perfect score.

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 description coverage is 100%. The description appropriately doesn't waste space discussing nonexistent parameters. A baseline of 4 is appropriate for a zero-parameter tool where the schema fully documents the empty input structure.

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 specific action ('Get') and resource ('SecureCodeHQ account status'), listing the exact information returned (plan, usage limits, secrets count, MCP server version). It distinguishes this tool from siblings like 'get-secret' or 'session-status' by focusing on account-level metadata rather than specific resources or session states.

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 context for when to use this tool ('Useful to check remaining capacity and verify the server is up to date'), giving clear practical applications. However, it doesn't explicitly state when NOT to use it or name specific alternative tools for related purposes, which prevents a perfect 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?

No annotations are provided, so the description carries full burden for behavioral disclosure. While it states what the tool does, it doesn't describe important behavioral aspects like whether this is a read-only operation, what format the documentation is returned in, whether there are rate limits, or if authentication is required. For a documentation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.

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 appropriately concise with two sentences that each serve a clear purpose: the first states what the tool does, the second provides usage guidance. There's no wasted language, and the key information is front-loaded. It could potentially be slightly more structured by explicitly listing the parameter's purpose.

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

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

Given the tool's simple nature (single optional parameter, no output schema, no annotations), the description is reasonably complete for basic understanding. However, it doesn't address what the output looks like (documentation format), whether there are any constraints or limitations, or how this differs from other informational tools in the sibling set. For a help/documentation tool, users would benefit from knowing what form the help takes.

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 schema already fully documents the single parameter with its enum values and default. The description mentions 'available tools, usage patterns, SDK setup, and common workflows' which loosely maps to some enum values but doesn't add meaningful semantic context beyond what the schema provides. With high schema coverage, 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 the tool's purpose: 'Get SecureCode documentation' with specific content areas listed (tools, usage patterns, SDK setup, workflows). It uses a clear verb 'Get' and identifies the resource 'SecureCode documentation'. However, it doesn't explicitly distinguish this from sibling tools like 'get-status' or 'get-active-rules' which might also provide information.

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 understand how to help the user with SecureCode'. This gives practical guidance about the tool's intended use case. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the sibling tools for different information needs.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively explains key behavioral traits: the tool provides a link to an import page (not performing the import itself), and for security reasons, the AI agent never sees secret values during import. This covers the tool's operational constraints and security implications adequately.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by security context and tool behavior. Every sentence earns its place by providing essential information without redundancy, making it highly efficient 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?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is mostly complete. It explains what the tool does, why it's designed this way for security, and how it differs from direct secret-handling tools. A minor gap is the lack of detail on what the link output looks like, but this is acceptable given the 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 tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description adds value by explaining the context: it provides a link to an import page, implying no input parameters are needed because the user interacts via the web interface. This clarifies why the schema is empty.

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: 'Import secrets from .env files into SecureCode.' It specifies both the action (import) and the resource (.env files), and distinguishes itself from siblings like 'export-env' by focusing on import functionality rather than export.

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 to use this tool: 'For security, .env import must be done through the web interface.' It provides clear context that this tool is for obtaining a link to the import page, not for performing the import directly, which helps differentiate it from tools like 'create-secret' or 'update-secret' that might handle secrets directly.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns metadata (names, tags, expiration status) but never values, which is a key behavioral trait. However, it lacks details on permissions, rate limits, pagination, or error handling, leaving gaps for a tool that likely accesses sensitive 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 description is a single, efficient sentence that front-loads the purpose and key constraints ('never values'). Every word earns its place, with no redundancy or unnecessary elaboration, 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?

Given the tool's moderate complexity (listing secrets with filtering), no annotations, and no output schema, the description does well by specifying what is returned (metadata) and what isn't (values). However, it could be more complete by addressing authentication, data scope (e.g., all secrets vs. user-specific), or response format, which are relevant for an agent's understanding.

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

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

The input schema has 100% description coverage, with the 'tags' parameter well-documented in the schema itself. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating value.

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 all available secrets') and the resource ('secrets'), specifying what information is included ('with their tags and expiration status') and excluded ('never values'). It distinguishes from siblings like 'get-secret' (which retrieves values) and 'create-secret'/'update-secret' (which modify secrets).

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 retrieving metadata about secrets, not their actual values, which helps differentiate from 'get-secret'. However, it doesn't explicitly state when to use this tool versus alternatives like 'export-env' or 'security-check', nor does it mention prerequisites or exclusions (e.g., authentication needs).

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

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

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it's a multi-step workflow tool ('guides the user through...'), supports incremental progression ('call multiple times'), and operates within Claude Code context. It could improve by mentioning authentication requirements or rate limits, but covers core behavior adequately.

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?

Perfectly front-loaded with core purpose in first sentence, followed by scope details and usage instruction. Every sentence earns its place: first establishes purpose, second defines scope, third provides critical usage guidance. No wasted words 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 4-parameter workflow tool with no annotations and no output schema, the description provides good context about the multi-step nature and progression logic. It could be more complete by mentioning expected outputs or error conditions, but covers the workflow purpose and usage pattern adequately given the 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 100%, so baseline is 3. The description adds meaningful context about the multi-step nature and progression logic that informs parameter usage, particularly the action parameter's role in workflow navigation. However, it doesn't provide specific examples or edge cases for parameter combinations.

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: 'Start or continue the SecureCode onboarding' with specific verbs ('guides', 'call') and resources (signup, .env import, API key creation, MCP configuration, SDK setup). It distinguishes from siblings by focusing on onboarding workflow rather than secret management or status 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?

Explicit guidance is provided: 'Call this tool multiple times to progress through the steps' and the action parameter enum defines specific usage scenarios (start, configure-auto, configure-manual, etc.). The description clearly indicates this is for onboarding workflow progression versus other tools that handle discrete operations.

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

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

With no annotations provided, the description carries the full burden and adequately discloses key behaviors: it indicates mutation (renewing/changing TTL) and clarifies that omitting 'ttlHours' makes the secret permanent. However, it lacks details on permissions, rate limits, or error handling, which are important for a mutation tool.

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

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

The description is front-loaded and concise with two sentences that directly address the tool's purpose and usage, with no wasted words or redundant information, making it efficient and easy to understand.

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 mutation tool with no annotations and no output schema, the description covers the basic purpose and usage but lacks completeness in areas like behavioral details (e.g., permissions, side effects) and output expectations, which are important given the tool's complexity and lack of structured support.

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 schema already documents all parameters well. The description adds marginal value by explaining the purpose of TTL changes and the effect of omitting 'ttlHours', but does not provide additional syntax or format details beyond what the schema offers.

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 specific action ('renew' or 'change TTL') and resource ('secret'), distinguishing it from siblings like 'create-secret', 'update-secret', and 'delete-secret' by focusing on expiration management rather than creation, general updates, or deletion.

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 for when to use the tool ('to reactivate expired secrets or extend expiration'), but does not explicitly mention when not to use it or name specific alternatives like 'update-secret' for non-expiration changes, leaving some room for ambiguity.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns 'a list of actions the agent MUST execute to protect secrets,' which adds behavioral context beyond a simple analysis. However, it doesn't cover other traits like error handling, performance, or side effects, leaving gaps for a tool with no annotation support.

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: it starts with the core purpose, then adds return value and usage instructions in two sentences. Every sentence earns its place by providing essential information without redundancy or 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?

Given no annotations, no output schema, and 0 parameters, the description is moderately complete. It explains the purpose, return value, and usage timing, but lacks details on output format, error cases, or prerequisites. For a tool that returns actionable lists, more context on the output structure would be helpful, though it's adequate as a minimum viable 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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, but it could have mentioned if any implicit inputs are required (e.g., project context). Baseline is 4 for zero parameters, as it doesn't need to compensate for schema gaps.

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: 'Analyze the project for security issues after SecureCode setup.' It specifies the verb ('Analyze') and resource ('project for security issues'), and mentions the context ('after SecureCode setup'). However, it doesn't explicitly differentiate from sibling tools like 'get-active-rules' or 'get-status', which might also relate to security analysis.

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: 'Call this after SDK installation' and 'after SecureCode setup,' which helps determine when to use it. It doesn't explicitly state when not to use it or name alternatives, but the context is sufficient to guide usage without being misleading.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what information is returned (session state, restrictions, time remaining), which is useful, but does not cover other behavioral aspects such as authentication requirements, rate limits, error conditions, or whether this is a read-only operation (implied but not stated). The description adds value but is not comprehensive.

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 efficiently conveys the tool's purpose and key outputs. It is front-loaded with the main action ('Check the current session status') and lists specific details without unnecessary elaboration, making it zero-waste and highly concise.

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

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

Given the tool's complexity (simple status check with no parameters) and lack of annotations/output schema, the description is adequate but not fully complete. It explains what information is returned, which is helpful, but does not cover behavioral aspects like error handling or session management implications. For a tool with no structured metadata, more context on usage and behavior 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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description does not need to add parameter semantics, and it appropriately focuses on the tool's purpose without redundant parameter information, meeting the baseline for a parameterless tool.

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

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

The description clearly states the tool's purpose with a specific verb ('Check') and resource ('current session status'), and it distinguishes from siblings by focusing on session status rather than secrets, environment, or rules management. It explicitly lists what information is retrieved: active/sleeping state, scope restrictions, and time remaining before auto-sleep.

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 context (checking session status) but does not explicitly state when to use this tool versus alternatives like 'get-status' or 'sleep-session/wake-session'. It provides no guidance on prerequisites, exclusions, or specific scenarios where this tool is preferred over others, leaving usage somewhat ambiguous.

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

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

With no annotations provided, the description carries the full burden. It discloses the immediate locking behavior and blocking of secret access, which are key behavioral traits. However, it lacks details on permissions needed, error conditions, or confirmation of success, leaving some gaps in 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 front-loaded with the core action ('Lock the session immediately'), followed by consequences and usage guidance in two concise sentences. Every sentence adds value without redundancy, making it efficient 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?

Given the tool's complexity (simple action with no parameters) and lack of annotations or output schema, the description is largely complete—it explains what the tool does, when to use it, and the immediate effect. A minor gap is the absence of information on return values or error handling, but this is acceptable for such a straightforward 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 tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description appropriately focuses on the tool's action without unnecessary parameter details, meeting the baseline 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 specific action ('Lock the session immediately') and resource ('session'), distinguishing it from siblings like 'wake-session' or 'session-status'. It precisely communicates the tool's function without being tautological.

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 provides when to use this tool ('when you finish working') and mentions the effect ('All secret access will be blocked until you wake it again'), which implicitly contrasts with alternatives like 'wake-session' for restoring access. This gives clear contextual guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that 'Only provided fields are changed,' which is useful for understanding partial updates. However, it doesn't cover critical aspects like required permissions, whether changes are reversible, error handling, or rate limits, leaving significant gaps for a mutation tool.

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

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

The description is extremely concise and front-loaded, consisting of two short sentences that directly convey the tool's purpose and key behavior. Every word earns its place, with no redundancy or unnecessary elaboration.

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

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

Given the complexity of a mutation tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., permissions, side effects), output format, and comprehensive usage context, making it inadequate for safe and effective tool 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?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by implying partial updates ('Only provided fields are changed') but doesn't provide additional semantics beyond what the schema specifies. This meets 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 clearly states the tool's purpose: 'Update an existing secret's value, description, tags, or domain.' It specifies the verb ('update') and resource ('secret'), and lists the updatable fields. However, it doesn't explicitly differentiate from sibling tools like 'create-secret' or 'renew-secret', which would require a 5.

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 minimal usage guidance with 'Only provided fields are changed,' which implies partial updates are allowed. However, it lacks explicit when-to-use guidance, such as prerequisites (e.g., secret must exist), alternatives (e.g., vs. create-secret for new secrets), or exclusions (e.g., when not 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?

With no annotations provided, the description carries full burden. It discloses that the tool enables secret access and mentions optional restrictions (scope) and auto-sleep behavior. However, it doesn't cover important behavioral aspects like authentication requirements, error conditions, what happens if called multiple times, or whether this affects other users/sessions.

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 appropriately concise with two sentences that efficiently convey the core purpose and key optional features. The first sentence states the primary action, and the second covers the two parameters. No wasted words, though it could be slightly more front-loaded by mentioning parameters in the first sentence.

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 session management tool with 2 parameters, 100% schema coverage, and no output schema, the description is minimally adequate. It covers the basic purpose and mentions parameters but lacks details about side effects, prerequisites, or what 'waking' actually entails operationally. Given no annotations, more behavioral context would be helpful.

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 schema already fully documents both parameters. The description adds minimal value by mentioning the parameters exist ('restrict access to specific tag scope and set auto-sleep timer') but doesn't provide additional semantic context beyond what's in the schema descriptions.

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 ('wake/unlock') and resource ('session') with the purpose 'to start accessing secrets'. It distinguishes from sibling 'sleep-session' by being the opposite operation. However, it doesn't explicitly differentiate from other session-related tools like 'session-status' or 'onboard'.

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 should be used before accessing secrets ('to start accessing secrets'), suggesting a prerequisite relationship with secret-access tools. However, it doesn't explicitly state when NOT to use it (e.g., if session is already awake) or mention alternatives like 'session-status' to check current state first.

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