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

Discloses key behaviors: owner-only deletion, uses account key, server verifies ownership, frees quota slot, returns removed name and summary. Notes it's not a governed production action. No annotations provided, so description fully covers behavioral traits.

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

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

Description is relatively long but every sentence adds value: action, purpose, usage guidance, ownership constraint, governance note, and return values. Could be slightly trimmed but not wasteful.

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 (single param, no output schema, many siblings) and lack of annotations, the description covers when, why, how, and constraints. It even references sibling tools (openpouch_list) and explains the return format. No gaps in context for an AI agent to correctly select and invoke 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?

Only one parameter 'slug' with schema description identical to tool description: 'The app name (slug / subdomain) to delete — exactly as shown by openpouch_list'. Schema coverage is 100%, so description adds no extra meaning beyond schema. 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?

Clearly states it deletes one of your own instant-lane apps by name (slug) to free a quota slot. Verb 'delete' plus specific resource 'own app' with explicit context. Distinguishes from siblings by emphasizing self-service and owner-only 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?

Explicitly describes when to use: as a self-service fix for 'limit reached' deploy errors after listing and identifying unused apps. Also states when not to use: cannot delete another account's app, and notes no approval needed because it's not a governed action.

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 fully covers behavioral traits: it uploads, builds, probes health, returns specific fields, redacts claim link, saves locally, treats env vars as secrets, and explains health check behavior. This is comprehensive and transparent.

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 dense paragraph covering many details. While every sentence adds value, it could be better structured with bullet points or clearer separation of concerns. The length is justified but could be more 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 complexity (5 parameters, nested object, no output schema), the description is remarkably complete. It explains the return fields, behavior on deployment, secrets handling, and health checks. One minor gap: it does not explicitly describe error cases or failure messages, but overall it is sufficient.

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%, but the description adds significant context beyond the schema: e.g., env values are secrets and never surfaced, healthPath is an extra health check, redactSecrets defaults to TRUE. This adds meaningful value for an agent.

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 'Zero-config INSTANT preview' and explains the tool's purpose. However, with sibling tools like 'openpouch_deploy_preview' and 'openpouch_deploy_production', the description does not explicitly differentiate this tool from those, which could confuse an agent about which deploy variant to use.

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 (zero-config, no account needed, for instant preview) and mentions that an API key lifts into a tier. It implies this is for quick previews but does not explicitly contrast with alternative deploy tools or give when-not-to-use scenarios.

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 must fully disclose behavior. It outlines the pipeline steps (policy check → deploy → poll → smoke → evidence) and states the return value includes a live URL and summary. It also notes the default policy allows autonomous previews. However, it lacks details on potential side effects, reversibility, or error handling beyond success. The information 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 concise, consisting of three sentences that each serve a distinct purpose: stating the tool's function and process, differentiating from a sibling, and detailing return values. No unnecessary 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?

Given the low complexity (single optional parameter, no output schema), the description covers the essential aspects: purpose, usage boundaries, and return format. It provides sufficient context for an AI agent to understand when and how to use the tool, though it could mention authentication or error behavior for 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 describes the single optional parameter 'cwd' as the project directory containing deploy.manifest.json, with 100% coverage. The description does not add additional meaning to this parameter beyond what the schema provides, 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 deploys a preview environment through a governed pipeline, with a specific verb 'Deploy' and resource 'preview environment'. It distinguishes itself from the sibling tool openpouch_deploy by noting that tool is for zero-config instant previews, leaving no ambiguity about what this tool does versus similar ones.

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 (for governed pipeline previews) and when to use an alternative (openpouch_deploy for zero-config instant previews). It mentions the default policy allows autonomous previews, but does not cover when to use production deployment or deletion tools. The guideline is clear and helpful, though not exhaustive.

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 explains the approval flow, return format (approvalRequest with isError, summary, url for live deploy). However, it does not detail all side effects beyond deployment, but the description is sufficient for an agent to understand the core 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 a single, well-structured paragraph that front-loads the main purpose, then details the approval flow and result structure. Every sentence adds value with no redundant 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?

Given the single optional parameter, no output schema, and no annotations, the description provides complete guidance on usage, approval handling, and result interpretation. It covers all necessary context for correct agent 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 coverage is 100% with one parameter (cwd) already described. The description does not add additional semantic information about the parameter, so a 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 deploys production through a governed pipeline. It differentiates from siblings like openpouch_deploy and openpouch_deploy_preview by specifying the production pipeline and the approval process.

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 (production deployments), how to handle approval (ask human to run approve and retry), and clarifies that agents cannot approve. It also mentions that every result has a summary to relay to the human.

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 any annotations, the description fully discloses behavior: detects environment, writes two files with default policies, auto-matches provider, and notes idempotency. It covers side effects and expected outcomes thoroughly.

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 efficient, front-loading the core purpose in the first sentence. It conveys necessary details without excessive length. Minor improvement could be made by separating the policy mention for clarity, but overall it is 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 (initialization, file writing, environment detection) and lack of output schema, the description provides a solid overview of behavior and results. It could mention error cases (e.g., provider not found) or specific detected variables for full completeness, but covers the essentials.

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 descriptions for both parameters ('cwd' and 'force'). The description does not add new parameter-level details beyond schema, but it contextualizes the tool's function. Baseline 3 is appropriate as schema carries the parameter burden.

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 initializes a project for openpouch, detailing actions like detecting framework/build/env vars, writing specific files, setting default policies, and auto-matching a provider. It effectively distinguishes from sibling tools by focusing on initialization rather than deployment, deletion, or inspection.

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

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

The description implies usage for initial setup but lacks explicit guidance on when to use this tool versus alternatives like deploy or plan. No when-to-use or when-not-to-use conditions are mentioned, leaving the agent to infer context from the tool's 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?

Annotations already provide readOnlyHint=true, and description reinforces with 'Read-only'. Adds context about deployProvided names only, and that the API never exposes env var values. Lacks detail on output structure beyond summary, which slightly limits 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?

Extremely concise yet informative. Front loads the core purpose, adds behavioral notes in subsequent sentences. Every sentence adds value 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?

Given the tool's simplicity (1 parameter, no output schema, annotations present), the description covers key aspects: purpose, behavioral constraints, and output summary. Minor omission is lack of explicit output format details, but sufficient for agent to understand usage.

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?

Only one parameter (cwd) with schema description covering its purpose and default. Description adds no additional semantics beyond what the schema provides. Baseline 3 is appropriate as schema 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 with specific verb 'inspect' and enumerates exactly what it answers: deployment details, commit, missing env vars (names only), and drift. This effectively distinguishes it from sibling tools like openpouch_deploy or openpouch_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?

Implied usage is clear: use when you need to inspect deployment state. Mentions that env vars are not exposed via API and that a human-readable summary is returned. However, does not explicitly differentiate from similar inspection tools like openpouch_plan or openpouch_verify, so slightly lacking in exclusion 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?

Annotations already declare readOnlyHint=true; description adds context about account key necessity, empty list scenario, and inclusion of a plain-language summary for the agent to relay.

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 concise sentences, each serving a purpose: listing action, clarifying prerequisites and edge case, and suggesting sibling usage. 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 list tool with no parameters and no output schema, the description is fully complete: covers purpose, behavior, usage conditions, and integration with sibling tools.

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?

Input schema has zero parameters (100% coverage by default), so description need not add parameter info. Baseline of 4 is appropriate as no additional value required.

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?

Clearly states the tool lists instant-lane apps by account key, specifies returned fields (name, kind, status, URL, expiry), and distinguishes from siblings like openpouch_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?

Explicitly notes read-only nature, requirement for an account key, behavior for anonymous previews (empty list with signup pointer), and pairs with openpouch_delete for quota management.

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 readOnlyHint=true. The description reinforces this and adds important context that the approval action is not available to agents, which is a key behavioral constraint beyond what annotations capture.

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 no extraneous information. Front-loaded with the primary function, then clarifies the boundary. 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?

Given the simple tool (one optional param, no output schema, annotations cover read-hint), the description is complete. It covers the purpose, usage boundaries, and is consistent with sibling tool set.

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% for the single parameter cwd, so baseline is 3. The description adds no additional meaning about the parameter beyond what the schema already provides.

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 'List' and the resource 'pending approval requests', with the read-only nature explicitly mentioned. It distinguishes from the sibling approving action, which is deliberately unavailable to agents.

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 (list pending approvals) and when not to use (approving is human-only). Provides an alternative command for the forbidden action, giving clear guidance on tool boundaries.

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 'Read-only' is redundant but confirms safety. Adds the log format and contextual role, but no additional behavioral traits like rate limits.

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 efficient sentences: format, read-only, usage context. Each sentence adds value with no waste. Front-loaded with key 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 3 parameters well-documented in schema, no output schema, and annotations present, the description explains its role in a broader workflow and expected output format. Minor lack of details on pagination or exact return structure beyond {timestamp, message}.

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 descriptions for all 3 parameters. The high coverage sets a baseline of 3; the description adds overall context but does not enhance parameter-specific meaning beyond the schema.

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

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

The description clearly identifies it as a log retrieval tool for a mapped service, specifying the output format and labeling it as read-only. It distinguishes from sibling tools that are write/action oriented.

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?

Describes the tool as the first step in a self-repair loop when a deploy is unhealthy, providing explicit context for use. Does not explicitly state when not to use, but the sibling list implies alternatives.

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 readOnlyHint=true. The description reinforces this with 'Read-only — reports, never acts', but does not add beyond that, such as error behavior or rate limits.

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 sentences, front-loaded with the primary purpose, and no unnecessary words. Every sentence 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?

Given one optional parameter, no output schema, and annotations covering read-only, the description is fairly complete. It could elaborate on output format or specific next steps, but it is adequate.

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% for the single parameter 'cwd'. The description does not add additional meaning or constraints beyond what the schema already provides, so baseline score 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 tool reports policy decisions, blockers, readiness, and next steps per environment. It distinguishes itself from sibling tools by emphasizing it is read-only and does not act.

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 checking plan before deployment with 'Per environment' and 'human-approval path', but does not explicitly state when to use or not use compared to siblings like openpouch_deploy or openpouch_inspect.

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

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

With no annotations, the description reveals it is a write action and approval-gated. However, it does not disclose potential side effects, error conditions (e.g., no anchor commit), or whether the action is reversible.

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, each adding value: first defines the action, second explains the approval mechanism. 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?

Given the simple tool (2 optional params, no output schema), the description adequately explains the action and return value possibility. Could mention environment role, but schema already covers 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 covers 100% of parameters. The description adds no parameter-specific meaning beyond what the schema provides, so baseline score 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 ('redeploy the recorded rollback anchor commit') and the resource (previous deploy). It distinguishes itself from sibling deploy tools by specifically targeting rollback.

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 rollback and mentions approval gating, but lacks explicit guidance on when to use versus alternatives like openpouch_deploy or when not to 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?

With no annotations provided, the description carries the full burden. It discloses side effects (appending to deploy.evidence.json and DEPLOYMENT.md), the fact that both / and healthPath are checked, and the output summary. It does not mention rate limits or auth needs, but these are less critical for a read/check 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 a single paragraph of three sentences, front-loaded with the main purpose, and includes essential guidance and output info. 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?

Given no output schema and no annotations, the description is complete. It explains what the tool does, how to use it (including optional parameters), what it produces (summary), and the side effects (appending to files). It is sufficient for an agent to select and 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?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining defaulting behavior (cwd defaults to server cwd, environment defaults to deploy's environment) and clarifying that healthPath is checked in addition to /. This goes beyond 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 tool runs a healthcheck/smoke test on a live URL and appends results to evidence files. It distinguishes itself from sibling tools like deploy, delete, logs, etc., by focusing on verification and 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 explains when to use it (as a healthcheck) and provides guidance on passing healthPath for full-stack apps. It lacks explicit when-not-to-use or comparison to alternatives, but the sibling tools are distinctly different, making usage clear.

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 mark it as readOnlyHint=true. The description adds key behavioral traits: read-only, key source file and environment variable, that the key is never echoed, output includes a plain-language summary, and signup/activation are excluded. This provides context beyond 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, with 4 sentences each serving a distinct purpose: purpose, read-only nature and key handling, output format, and usage boundary. 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?

Despite having no output schema, the description covers the key output elements (tier, usage, anonymous status, summary) and clarifies authentication and scope. For a simple whoami tool, this is 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?

The tool has zero parameters, and schema coverage is 100%. The description adds no parameter-specific info, but that is acceptable per guidelines (baseline 4 for 0 params).

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 'Report the openpouch account behind the current API key: tier (plan) and current usage...', using a specific verb ('report') and resource ('account'). It distinguishes itself from sibling tools by focusing on identity and usage info, not actions like deploy or 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?

The description explicitly notes it is read-only and provides details on key sourcing and output (plain-language summary). It warns that signup/activation are not possible through this tool, implying when not to use it. However, it does not explicitly compare to alternatives, but no sibling tool serves the same purpose.

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