EchoRelay

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

Adds behavioral context beyond annotations: immediate publication, cap blocking, and edit access requirement. No contradiction with readOnlyHint or destructiveHint flags.

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, front-loaded with the primary action, then constraints and permission requirements. Every sentence provides essential information with no 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?

Description covers purpose, operational constraint, and permission. Schema documents all parameters. Missing return value or error behavior, but no output schema exists and the tool is simple enough that this isn't critical.

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 descriptions cover all three parameters at 100%, so the description adds no additional parameter semantics. Baseline 3 is appropriate per guidelines.

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

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

Description clearly states the verb 'activate' and resource 'line' with immediate publishing outcome. It distinguishes from siblings like deactivate_line by explaining the tool serves traffic again.

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

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

Provides contextual guidance: blocked at the active-line cap, requiring deactivation first, and requiring edit access. However, it doesn't explicitly name alternative tools for similar operations like schedule_line_publish.

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

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

Despite the destructiveHint annotation, the description adds rich behavioral details: reversibility, persistence of project and slug, credit retention, data plane tenant drop (404), idempotency, and failure conditions. This goes well beyond the annotations.

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

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

Three focused sentences front-loaded with the core purpose, then adding essential caveats. No filler or redundant information.

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

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

Given the single parameter, no output schema, and moderate complexity, the description covers purpose, effects, reversibility, idempotency, failure mode, and authentication requirements. Complete for an agent to decide 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?

The schema fully describes the slug parameter (100% coverage), and the description doesn't add information beyond the schema. Baseline 3 is appropriate since the schema handles the parameter semantics.

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

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

The description clearly states the tool archives a project, with a specific verb and resource. It also distinguishes from siblings like unarchive_project by describing the reversible nature and consequences.

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

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

Provides clear context: requires ACCOUNT-scoped token and config scope, fails if archive protection is enabled. It implies the action is reversible but doesn't explicitly name unarchive_project as the alternative, so it lacks explicit sibling differentiation.

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

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

Annotations already indicate the tool is destructive. The description adds the two-minute lock detail, which is a meaningful behavioral constraint. However, it does not explain the consequences of the lock or what 'cancel' entails beyond the annotation, so transparency is moderate.

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

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

The description is a single, succinct sentence that immediately conveys the core action and timing. There is no redundant language, and it is front-loaded with the verb.

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

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

The description lacks essential details about the required parameters and the meaning of the two-minute lock. While annotations cover the destructive nature, the description does not explain prerequisites, effects, or error conditions, making it insufficient for reliable tool selection and invocation.

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

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

The description does not mention the parameters at all, and the schema has no descriptions for lineKey or draftRevision. With 0% schema coverage, the description fails to clarify what these parameters represent or how to populate them, leaving the agent without guidance.

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 (cancel) and resource (one line schedule), and the 'two-minute lock' condition distinguishes it from publish/draft tools. It could be clearer about what 'line schedule' refers to, but it is sufficiently specific.

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

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

The description implies the tool is for canceling a scheduled publish before a two-minute lock, but it does not explicitly compare to sibling tools like schedule_line_publish or discard_line_draft. No exclusions or after-lock guidance are provided, leaving usage context partially implied.

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

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

Beyond the destructiveHint annotation, the description discloses the scheduled nature of cancellation, the exact return structure, the behavior of add-ons during and after the plan ends, and authentication requirements. This adds significant behavioral context that annotations alone do not provide.

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 yet complete, with three sentences that each serve a distinct purpose: core action and return, add-on behavior with alternative, and auth requirements. It is well-structured and front-loaded with the primary function.

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 scheduled cancellation with add-on interactions and permission constraints, the description covers all essential aspects: what happens to add-ons, when cancellation takes effect, return format, and required token scope. It is fully self-contained and complements the sparse annotations and absent output schema.

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

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

The tool has no parameters, so the schema is trivially complete. The description adds no parameter-specific semantics, but none are needed. The baseline for zero-parameter tools is 4, and the description sufficiently explains the operation's behavior and return 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 specific action: scheduling the project owner's subscription for cancellation at the end of the current billing period. It distinguishes itself from siblings by explicitly mentioning the timing and the alternative 'unsubscribe_addon' for add-ons, making its purpose unmistakable.

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, including owner-only access and billing scope requirements. It also names an alternative (unsubscribe_addon) for stopping add-ons sooner, giving clear when-to-use vs. when-not-to-use guidance.

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

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

The description explains the return format with {kind, newPlan, effectiveAt, applied} and details the behavior of `applied` (immediate charge vs queued). It also discloses that canceling drops to Free at period end. This goes well beyond the annotations (destructiveHint=true) to give a full picture of the action's effects and timing.

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 that are tightly packed with information: action, return value, and usage guidance. No wasted words; every clause serves a 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?

Despite having only one parameter and no output schema, the description covers the action, effect, timing, return semantics, prerequisites, and suggested prior step. It is fully self-contained for an agent to select and invoke the tool correctly.

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

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

The description adds meaningful context to the single 'plan' parameter by mapping values to actions (Pro/Scale switch, free = cancel). Although it doesn't explicitly enumerate the enum values, it explains their practical effect. Since schema coverage is 0%, this compensation is valuable but not exhaustive.

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

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

The description clearly states the tool's function with specific verbs ('Switch', 'cancel') and resources ('project owner between Pro and Scale', 'subscription'). It also distinguishes from sibling tools like preview_plan_change by explicitly positioning this as the actual change action.

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 to use preview_plan_change first to see the dollar impact, and states prerequisites (owner-only, billing scope token). This clearly indicates when to use the tool and what is needed, differentiating it from related 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 establish the read-only and non-destructive nature. The description adds valuable behavioral context by noting that outbound auth secrets are redacted 'the same as get_config' and that it handles both immediate and pending scheduled publishes, providing security and scope details beyond the annotations.

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

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

The description is two sentences, with the first using a colon to clearly list the diff components, and the second adding the redaction caveat. Every phrase provides useful information with no fluff or repetition.

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

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

Given the lack of parameters and output schema, the description adequately covers the tool's scope: what action it previews, what types of changes are reported, and redaction behavior. It does not specify edge cases like an empty diff, but this is a minor gap for a read-only preview 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 no parameters, and the schema is empty. With zero parameters, there is nothing for the description to explain, so the baseline of 4 applies. The description correctly omits parameter information because none exist.

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

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

The description clearly states the tool's function with a specific verb ('Preview') and resource ('what Save & Publish would change'), and lists detailed output categories (added/removed/changed lines, endpoints, targets, project-level settings). It distinguishes itself from sibling tools like get_config by focusing on the diff preview rather than the current config state.

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

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

The usage context is clear: this tool previews changes before a Save & Publish or scheduled publish. However, it does not explicitly name alternatives or provide when-not-to-use guidance, so it falls short of a 5.

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

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

Annotations only mark readOnlyHint false and destructiveHint false, so the description carries the full disclosure burden. It provides rich behavioral detail: secret format (er_live_/er_test_), one-time plaintext return, non-retrievability, permission requirements (Editor+owner), and policy dependency. This aligns with the annotations while adding significant value beyond them.

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

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

Four dense sentences deliver the core purpose, key behaviors, permissions, and policy reference without redundancy. Each sentence contributes distinct information and the structure is front-loaded with the main action.

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

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

The description covers purpose, usage boundaries, return behavior (plaintext exactly once), permissions, and policy linkage. Since there is no output schema, the one-time return note adequately explains what to expect. It also references the related policy tool for additional context, making this comprehensive for the tool's 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?

The schema covers 100% of parameters with descriptions, including the mode enum and null semantics for ttlDays. The description adds contextual background about the secret prefix and permissions, but does not need to repeat parameter details. This matches the baseline of 3 for full 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 opens with the specific verb 'Mint' and resource 'inbound relay (data-plane) API key', clearly identifying the tool's function. It explicitly distinguishes this from management keys by noting the secret cannot call management MCP or REST, separating it from sibling tools like create_project_token.

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 states the use case — 'for callers to send traffic to this project' — and sets boundaries by noting the key cannot call management APIs. It also references get_key_policy for policy constraints, but does not explicitly name an alternative tool for creating management keys. This is clear context with implicit exclusions, though not a fully explicit when-to-use comparison.

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

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

The description goes far beyond the basic readOnly/destructive hints by disclosing critical behaviors: the secret is sealed at write time and never returned, destinationHost is permanent, and the credential is only sent to that host over https. These are essential constraints not apparent from annotations or schema alone.

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

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

The description is dense but every sentence earns its place. It front-loads the main purpose, then methodically covers security, usage pattern, auth type mappings, and destinationHost constraints without redundancy or filler.

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

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

With no output schema, the description covers the most important outcome (the secret is not returned, and the credential is referenced by id), but it does not explicitly state what the response contains (e.g., the credential id or a success indicator). This is a minor gap given the strong behavioral context provided.

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?

Although the schema covers every parameter, the description adds crucial cross-field semantics by mapping each auth.type value to the applicable fields (bearer→token, basic→username+password, etc.). It also explains destinationHost's permanence and wildcard matching, which is not obvious from the schema alone.

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

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

The description opens with 'Save a new reusable credential', which is a specific verb-resource pair and clearly distinguishes this from related tools like create_api_key. It further specifies the credential is sealed with the project's encryption key and references how it is used (by target id), making the purpose unmistakable.

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 usage context by explaining that the secret is never returned and should be referenced from a target via credentialVaultEntryId, pointing to create_endpoint/update_endpoint. It lacks explicit 'when not to use' or alternatives like create_api_key, but the guidance is sufficient for most agents.

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

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

Annotations only provide readOnlyHint/destructiveHint as false. The description adds meaningful behavioral context: immediate publish default, the draftRevison dependency, and scheduledAt's side effect of staging the line draft then scheduling it. The 'Requires edit access' note adds permission context beyond what annotations convey.

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

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

Three sentences, each purposeful: the core action, the default mode, and the scheduling behavior. No filler, front-loaded with the primary verb and resource, and every sentence earns its place.

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

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

For a tool with 5 params and a deeply nested endpoint object, the schema supplies exhaustive detail. The description covers the critical workflow decisions (publish/draft/scheduled) and the permission prerequisite, which is sufficient given the schema's richness, though it doesn't discuss return values or every edge case.

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

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

Schema coverage is 100% with detailed field descriptions, so the baseline is 3. The description's statements about draftRevision and scheduledAt largely echo the schema's own descriptions ('required for draft writes', 'Compatibility alias...') without adding new semantics 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 opens with 'Create an endpoint under a line', a specific verb+resource+scope statement. It clearly distinguishes this create operation from sibling update/delete tools, and clarifies the publish/draft modes, making the purpose unmistakable.

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 states 'Defaults to immediate publish; draft mode requires draftRevision' and 'scheduledAt stages the line draft then schedules it', giving clear context for when to use draft vs publish vs scheduled workflows. It also notes the edit-access requirement, though it doesn't explicitly name alternatives like update_endpoint for modifying existing endpoints.

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=false and destructiveHint=false, so the description supplements this with behavior around versioning, publish default, draft revision condition, and permission requirements. This adds value beyond the structured annotations.

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

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

Three concise sentences front-load the core action and then add key constraints (publish default, draft revision, edit access). Every sentence earns its place with no filler.

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

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

For a 4-parameter create tool with no output schema, the description covers purpose, draft/publish behavior, permission, and an important parameter constraint. It could mention the return value, but it is still adequate for selection and 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%, so baseline is 3. The description adds the specific 'draftRevision 0' requirement and 'immediate publish' default, clarifying semantics beyond the schema's existing field 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 'Create a new versioned line' with a specific verb and resource, distinguishing it from sibling tools like create_project or create_endpoint. The 'versioned' qualifier adds useful specificity.

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

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

The description explains key usage context: defaults to immediate publish, draft mode requires draftRevision, and edit access is needed. It does not explicitly name alternatives or exclusions, but the context is clear enough for a creation tool.

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

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

The annotations only say non-readOnly/non-destructive, but the description adds rich behavioral detail: slug derivation and server-side validation (format, reserved words, uniqueness), plan-based errors, required ACCOUNT-scoped token and config scope, and the exact response fields. No contradiction with annotations.

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

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

The description is dense but each sentence earns its place: purpose, slug derivation/validation, plan limits and alternative, prerequisites, return value and next step. No filler or redundancy.

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

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

The tool has a single parameter and no output schema, but the description fully covers prerequisites, error conditions, return format, and follow-up actions. It is complete for an agent to correctly invoke the tool.

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

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

The schema already describes the name parameter and slug derivation. The description adds meaningful context: server-side validation specifics, plan limits affecting whether the call succeeds, and the relationship to the follow-up create_project_token call. This goes beyond just repeating the schema.

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

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

The description states a specific verb+resource: 'Create a new project on your account'. It distinguishes from sibling create_project_token by explicitly saying to skip create_project and call create_project_token when an existing project can host the integration.

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

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

Provides explicit usage context: bootstrap from a fresh account, plan limits, and the alternative to use create_project_token with an existing project. Also states required token type and scope, making when-to-use 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?

The description discloses numerous non-obvious behaviors beyond the minimal annotations: scopes must be a subset of this token's own grant, `read` is always included, expiry is mandatory (1–90 days, default 30, never 'never'), minted tokens can never mint tokens, `spend` is human-granted only, and the plaintext is returned exactly once with only its hash stored. Annotations only provide readOnly/destructive hints, so this adds substantial behavioral context.

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

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

The description is dense but every sentence adds critical operational detail: purpose, usage timing, scope attenuation rules, authentication requirements, and return behavior. It is front-loaded with the primary action and follows a logical flow 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?

For a token-minting tool with 4 parameters and no output schema, the description covers lifecycle usage, security constraints, authentication prerequisites, and return-value handling. It leaves no major ambiguity for the agent to invoke the tool correctly, including what the token can and cannot do.

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?

Although the input schema already describes all 4 parameters (100% coverage), the description enriches their meaning: scopes must be a subset of the caller's grant, `read` is always granted, `spend` and legacy `billing` are never mintable via this tool, and expiry is mandatory with a default of 30 days. These constraints go well beyond the schema's field-level 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 opens with a specific verb ('Mint') and a clearly defined resource ('PROJECT-scoped management token'), immediately distinguishing it from sibling tools like create_api_key or create_credential. It also specifies the token prefix (`er_mcp_`), its intended use for MCP and REST, and a key functional exclusion (cannot authenticate relay traffic).

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: 'Use it after create_project to configure a fresh project, or for any project you already own.' It also names an alternative path for spend-scoped keys ('mint a spend-scoped key from the project's panel instead') and spells out the required authentication context (ACCOUNT-scoped token and `config` scope).

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

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

Annotations already mark destructiveHint=true and readOnlyHint=false. The description adds valuable behavioral context: immediate 404s, preservation of endpoints/targets/config, reversibility, and the guarantee that live traffic is never auto-disabled. It also discloses a permission requirement. There is no contradiction with annotations.

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

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

Two sentences, with the primary action and immediate consequence in the first clause. Every phrase adds value, including reversibility, preservation, and permission. No filler or repetition.

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

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

For a mutation tool with 3 parameters and no output schema, the description covers essential operational context: what happens to traffic, what is preserved, reversibility, permission required, and that it is deliberate. This is sufficient for an agent to decide when to use 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 description coverage is 100%, so lineKey, commitMode, and draftRevision are fully documented in the schema. The description adds no parameter-specific meaning, which is acceptable given the schema's completeness. 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 uses a specific verb ('take off') and resource ('line'), states the immediate effect (callers get 404), and explicitly distinguishes from deletion by noting configuration is preserved and the line can be reactivated. This clearly separates it from siblings like delete_line and activate_line.

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 contrasts with deletion ('without deleting it — endpoints/targets/config are preserved and it can be reactivated later'), implying it is for temporary removal while preserving state. It also states a prerequisite ('Requires edit access') and notes it is a deliberate action. However, it does not explicitly name alternative tools or provide exclusions beyond deletion.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description reinforces this with 'Read-only' and adds useful behavioral detail: the returned JSON is intended to be POSTed verbatim to create_endpoint and is immediately workable as a mock endpoint. This exceeds what annotations alone provide.

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

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

Two sentences, front-loaded with the core purpose and followed by a concrete usage instruction. Every word earns its place, and there is no redundant repetition of schema or annotations.

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

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

For a tool with one simple parameter and no output schema, the description is nearly complete: it explains what is returned, how to use it (POST to create_endpoint), and that it is read-only. It could be slightly richer by mentioning the exact shape of the returned JSON, but 'canonical minimal-valid endpoint JSON' is reasonably informative without over-specifying.

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 single required parameter lineKey is already fully described in the schema (100% coverage). The description mentions 'fresh line' but does not explicitly explain how lineKey affects the returned template. Since the schema carries the parameter semantics, 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's purpose: it returns a canonical minimal-valid endpoint JSON for a fresh line. It distinguishes itself from sibling tools like create_endpoint (which creates) and get_endpoint (which retrieves) by explicitly framing itself as a template provider.

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

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

The description gives clear usage context: use this to obtain a template, then POST it verbatim to create_endpoint. It does not explicitly name alternatives or when-not-to-use scenarios, but the instruction 'for a fresh line' and the POST-to-create flow imply the intended workflow.

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?

While the destructiveHint annotation already flags this as a destructive operation, the description adds valuable context about the error type (validation error vs. permission/not-found) and the dependency on target references. This exceeds the annotation's simple flag.

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, each serving a distinct purpose: state the action and state a key constraint. No fluff, front-loaded with the main verb.

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

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

For a one-parameter delete operation with no output schema, the description adequately covers the main function and an important edge case. It could mention irreversibility explicitly, but destructiveHint already implies it, so the description 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 coverage is 100%, so the schema already documents the only parameter. The description adds no extra parameter-level detail beyond referencing 'a saved credential,' so the baseline score of 3 applies.

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

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

The description leads with 'Delete a saved credential,' a specific verb+resource statement that clearly differentiates from sibling tools like create_credential and update_credential. The additional detail about being blocked when referenced adds further purpose clarity.

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

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

The description provides an explicit precondition: deletion is blocked while targets still reference the credential, with advice to repoint or remove those targets first. This acts as clear when-not guidance, though it does not name alternative tools for repointing/removal, preventing 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the baseline is covered. The description adds valuable context: it mentions the destructive scope ('its targets'), the timing ('publishing the removal immediately'), and auth requirement ('Requires edit access'). However, it overstates immediacy without qualifying that commitMode=draft would defer publication, which is a minor omission given the schema clarifies this.

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

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

The description is two sentences, front-loaded with the action, and contains no filler or redundant information. Every clause adds value: the operation, scope, immediacy, and access requirement. This is a model of concise, efficient writing.

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 nature of a delete operation, the combination of annotations (destructive hint), full schema documentation, and the description (scope, timing, auth) provides a complete picture. The only nuance about draft mode is visible in the schema, so the description is sufficient for an agent to select and invoke the tool 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 description coverage is 100%, so all four parameters (lineKey, endpointId, commitMode, draftRevision) are already fully documented in the input schema. The description does not add any parameter-specific details beyond what the schema provides. Baseline 3 is appropriate as the schema carries the full 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 action ('Delete'), the resource ('an endpoint'), and the scope ('and its targets'). It also specifies the immediate effect ('publishing the removal immediately'), which helps distinguish it from sibling tools like discard_draft_endpoint or update_endpoint. The verb and resource are specific and unambiguous.

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

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

The description provides clear context by mentioning the prerequisite 'Requires edit access' and the immediate publishing behavior. However, it does not explicitly mention when to use this tool instead of alternatives like discard_draft_endpoint or draft commit mode. It lacks explicit exclusions or alternative tool references, but the core context is adequate.

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 flag this as destructive (destructiveHint: true), and the description adds valuable context: the cascade to all endpoints, immediate publication of the removal, and the need for edit access. This goes beyond the structured annotations and clarifies real-world effects.

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

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

The description is two sentences, with the primary action front-loaded and the permission requirement as a brief second sentence. No wasted words; every element contributes to understanding the tool's behavior and requirements.

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 destructive tool with no output schema, the description covers the essential context: what is affected (line and endpoints), when the effect is visible (immediately published), and the required permission. It relies on destructiveHint for irreversibility, which is acceptable given annotations. Slight gap: it doesn't explicitly warn that deletion is permanent, but the destructive hint and 'delete' wording suffice.

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

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

Schema description coverage is 100%, with all three parameters documented in the schema itself. The description adds minor context for lineKey ('every endpoint under it') but does not introduce meaning for commitMode or draftRevision beyond what the schema already provides. 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 specifies the action ('Delete'), the resource ('a line'), and the scope ('every endpoint under it'), distinguishing it from sibling tools like deactivate_line or archive_project. It also notes the immediate publishing of the removal, which adds precision.

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 (permanent deletion of a line and its endpoints) but does not explicitly contrast with alternatives such as deactivate_line or archive_project. It provides a prerequisite ('Requires edit access') but no when-to-use/when-not-to-use guidance beyond the inherent meaning of 'delete'.

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

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

Annotations already mark destructiveHint=true, and the description reinforces this with 'Permanently delete' and 'without retrying', adding context about irreversibility and the non-retry behavior. It does not contradict annotations and provides useful behavioral details beyond the structured metadata.

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

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

The description is a single, direct sentence that conveys purpose, key behavior, and access requirement without any filler. It is front-loaded and every word earns its place.

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

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

This is a simple one-parameter destructive tool with strong annotations and relevant sibling context (retry_dlq_entry, get_dlq_entry, list_dlq). The description covers the essential behavior and access requirement adequately. A more explicit warning about irreversibility could improve it slightly, but it is not necessary for basic 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 schema already describes the sole parameter 'id' as 'Redis stream id from list_dlq', and the description adds no additional parameter-level detail. With 100% schema coverage, baseline of 3 is appropriate; the description does not need to compensate.

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

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

The description uses the specific verb 'delete' with the resource 'DLQ entry' and adds 'Permanently' and 'without retrying', which clearly distinguishes it from sibling tools like retry_dlq_entry. It unambiguously states what the tool does.

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

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

The phrase 'without retrying' implies the intended use case versus retry_dlq_entry, and 'Requires edit access' provides a clear prerequisite. However, it does not explicitly state when not to use this tool or describe alternatives, leaving some room for interpretation.

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 destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive operation. The description adds minimal behavioral context beyond 'discard,' such as whether the change is permanently lost or how the draft is affected, but it does not contradict the annotations.

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

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

The description is a single, front-loaded sentence that directly states the tool's purpose with no wasted words. It earns its place.

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

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

For a destructive tool with three required parameters and no output schema, this description is too minimal. It does not explain what 'draftRevision' is, whether the action is irreversible, or what the outcome/return value looks like. It lacks the depth needed for an agent to invoke the tool with confidence.

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

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

Schema description coverage is 0%, so the description must compensate by explaining the parameters. It only hints that 'endpointId' relates to an endpoint change and 'lineKey' to a line draft, but it does not clarify the role of 'draftRevision' or provide any explicit parameter semantics. This falls short of compensating for the missing 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 uses a specific verb ('discard') with a specific resource ('one endpoint change from a line draft'), clearly distinguishing it from siblings like discard_line_draft (whole draft) and delete_endpoint (endpoint deletion). It conveys exactly what action is performed.

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

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

The phrase 'from a line draft' implies the tool is used while editing a line draft to revert a single endpoint change, providing some contextual guidance. However, it does not explicitly state when to use this tool over alternatives like discard_line_draft, nor does it mention prerequisites or exclusions.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description is not required to state that it produces a destructive side effect. It adds some context by mentioning that both 'unpublished change' and 'schedule' are discarded, but it does not disclose whether the action is reversible, what happens to the draft revision, or whether any confirmation is needed. No contradiction with annotations.

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

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

The description is a single sentence, which is concise and front-loaded with the action. However, the phrasing 'every unpublished change and schedule' is grammatically awkward and could be clearer. It earns a 4 because there is no wasted prose, though minor structural improvements would help.

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 destructive tool with no output schema, the description leaves gaps: it does not explain the role of draftRevision, what 'schedule' refers to, or the distinction from similar tools like discard_draft_endpoint. The overall context is thin, especially given the tool's destructive nature and the need to understand the revision parameter.

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

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

Schema description coverage is 0%, so the description must explain parameter meanings. It implicitly covers lineKey via 'one line,' but draftRevision is completely unexplained—what it represents, how it controls the discard, and why it is required. The description does not compensate for the lack of schema documentation.

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

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

The description uses the verb 'discard' and specifies the resource as 'every unpublished change and schedule for one line.' It distinguishes from siblings like publish_line_draft and get_line_draft. However, the phrasing is slightly awkward ('change and schedule' could be misread as two separate objects) and does not explicitly mention the line's draft revision.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not state that this should be used to revert unpublished changes, nor does it mention when not to use it (e.g., if you want to keep the schedule). The description implies a use case but offers no explicit context or exclusions.

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

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

Discloses important behaviors beyond annotations: the current tier stays active until nextRenewalAt, the lower tier activates after that, no mid-cycle charge, and requires owner role with billing scope. This enriches the destructiveHint=true annotation with timing and auth details.

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?

Four concise sentences cover purpose, timing, key discovery, return value, and auth. Every sentence is informative and no content is redundant.

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

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

For a tool with no output schema, the description adequately explains the return value ({addonKey, targetAddonKey, project, effectiveAt}). It also covers scheduling behavior, prerequisites, and authorization, making it complete for an AI agent to invoke correctly.

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

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

The input schema already provides complete descriptions for both parameters (100% coverage). The description adds no significant parameter-level detail beyond what the schema states, so 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 states a specific verb and resource: 'Schedule a tier downgrade for a non-stackable add-on (RPM tier).' This clearly distinguishes it from sibling tools like subscribe_addon or change_plan by specifying the action and 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?

It provides clear context: scheduling happens at next renewal, with no mid-cycle charge, and points to list_addons for finding keys. It does not explicitly mention when not to use it or alternatives, but the context is sufficient.

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

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

Beyond the readOnlyHint/destructiveHint annotations, the description enumerates exactly what won't happen: 'No DB write, no queue entry, no billing, and the payload is never sent anywhere.' It also discloses the detailed evaluation behavior for sample/answerSample, including field provenance and failed rules — exactly the kind of side-effect and behavior context agents need.

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 purpose and all five sentences carry useful information without fluff. It's slightly longer than the minimal ideal, but for a tool with 5 parameters and rich behavior, the density is appropriate. It earns a 4 rather than a 5 because it could be more scannable with light structuring.

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?

There's no output schema, so the description's return shapes ({ok:true,...} / {ok:false,...}) cover the main contract. It explains both invocation modes and optional payload evaluation. It doesn't elaborate on the 'resolved' config slice or the errors object structure, but given the schema's thorough parameter docs, this is adequate — a 4 with minor gaps.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds value by explaining endpointId's role in create-vs-PATCH and by detailing what sample and answerSample trigger (mapping evaluation, field provenance, failure reporting). It doesn't need to restate schema docs for lineKey/endpoint, so a 4 is warranted for the extra semantics.

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

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

The description opens with 'Validate an endpoint document without writing it' — a specific verb, resource, and explicit contrast with write operations. It then distinguishes the two modes (create vs PATCH via endpointId) and names the exact return shape for both success and failure, clearly separating it from sibling create/update tools.

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

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

It gives clear, actionable guidance: pass endpointId to dry-run a PATCH, omit it for a create. However, it doesn't explicitly name alternatives (e.g., create_endpoint for real writes) or state when not to use the tool, so it stops short of the 'when-not/alternatives' bar for a 5.

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

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

The description discloses important behavioral traits beyond the annotations: the copy is 'saved inactive' and 'remains off the data plane', requiring explicit activation, and 'Requires edit access' which is an authorization requirement. This adds significant context to the readOnlyHint=false and destructiveHint=false annotations, giving a clear picture of post-conditions and permissions.

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

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

The description is two sentences long, front-loaded with the primary action, and every clause earns its place. It conveys purpose, key side effects, and a workflow hint without any waste.

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 (5 params, no output schema), the description covers the essential context: what is duplicated, the inactive state, the required edit access, and the next step via activate_line. It does not cover edge cases like existing newLineKey conflicts or commit modes, but the schema addresses those, so this 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 description coverage is 100%, so the baseline is 3. The description does not add much parameter-specific information beyond what the schema already provides; it mentions 'build v2 from v1' which nods to newLineKey, but does not elaborate on commitMode or draftRevision. The schema already does the heavy lifting.

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

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

The description uses the specific verb 'Copy' and clearly identifies the resource ('a line and all its endpoints/targets/rules') and the outcome ('into a new line key — build v2 from v1'). This distinguishes it from sibling tools like create_line by emphasizing duplication of an existing line with full dependencies.

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

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

The description provides clear usage context by framing it as 'build v2 from v1' and instructing to 'edit it, then activate_line when ready', which tells the agent the typical workflow. It does not explicitly state when not to use this tool or name alternatives, but the context is sufficient.

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 read-only and non-destructive. The description adds substantial behavioral context: invoiceable accounts show zero credit fields by design, live traffic is never refused for empty balance, free-tier is exempt, and only the testing pool can refuse with a specific 402 error. This deepens the agent's understanding of edge cases.

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 sentence one, followed by valuable interpretive guidance. It is longer than necessary but every sentence adds context; a slightly tighter version might 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 no output schema, the description covers the key interpretation nuances well. It does not enumerate the exact response fields (e.g., paid_credits, testing_credits) beyond mentioning balances and billingModel, but it provides enough for an agent to understand the tool's role.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific semantics, but none are needed.

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

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

The description opens with a specific verb+resource: 'Get the project's credit balances (paid + testing) and which ledger it settles on.' It clearly distinguishes this from siblings like list_credit_packs by focusing on the project-level balances and settlement ledger.

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 explicitly positions the tool as a prerequisite check: 'Read this before concluding from any other field that a project cannot send.' It provides context on interpreting billingModel and zero balances. However, it does not name alternative tools for billing-related queries, though the context is 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?

Beyond the readOnlyHint/destructiveHint annotations, the description adds that the result includes 'pendingPublish with its frozen, redacted config when one is scheduled,' which is a behavioral nuance about coverage and redaction. It also clarifies the config is 'published,' indicating it is the live runtime config.

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, no filler. The first sentence states the core purpose, the second adds important inclusion detail. 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?

The description conveys the return value's nature (exact JSON, includes pendingPublish when scheduled) and safety profile via annotations. It lacks explicit mention of behavior when no configuration exists or when pendingPublish is not scheduled, but for a parameterless getter this 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?

The input schema has zero parameters, so the description has nothing to add; the baseline of 4 applies. The description does not mention parameters, which is consistent.

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

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

The description uses a specific verb 'Get' with a specific resource 'the project's published relay configuration' and adds distinguishing detail: 'the exact JSON the EchoRelay Framework consumes' and 'Includes pendingPublish...' which differentiates it from sibling config tools like config_diff and list_config_revisions.

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 via 'exact JSON consumed' but does not explicitly state when to use this instead of config_diff or list_config_revisions. No explicit when/when-not guidance is given, leaving the agent to infer from the specific wording.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds substantial behavioral context: the durable vs. changing nature of identifiers, fan-out cardinality, the inclusion of configVersion with meaning, and the error condition when no entry matches. This exceeds the baseline expectation for a read-only 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 somewhat long but every sentence earns its place. It front-loads the core purpose, then explains the nuanced differences between parameters and error behavior. No fluff or redundancy; the density is appropriate for the tool's complexity.

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?

There is no output schema, so the description compensates by explaining what entries include (configVersion). It covers both lookup modes, error conditions, and edge cases like purged/retried entries. Given the tool's complexity, the description is fully complete for an agent to select and invoke it correctly.

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

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

The input schema already provides detailed descriptions for both parameters with 100% coverage. The description adds extra value by explaining the format of id, the stability of requestId, and the return behavior for fan-out scenarios, going beyond just restating 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 states the tool's purpose: fetching DLQ entries, with two distinct lookup keys explained. It differentiates from siblings by explicitly covering both id and requestId semantics and the fan-out behavior, making it unambiguous what this tool does.

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

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

The description provides strong usage context by explaining when to use requestId vs id and noting the relationship to list_dlq. It does not explicitly name alternatives like discard_dlq_entry or retry_dlq_entry, but the read-only nature and the distinction from mutating siblings is evident.

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 the tool as read-only and non-destructive. The description adds useful behavioral context by revealing that the response includes auth keys and attributes, which are sensitive and potentially large fields, going beyond the annotation information.

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

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

The description is a single sentence that immediately states the action and outcome, with no unnecessary words or repetition. It is concise, front-loaded, and every phrase adds value.

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

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

This is a simple read-only endpoint retrieval with two well-described parameters. The description explains what the response contains (full JSON with targets, auth keys, attributes), and the annotations cover safety, so no output schema is needed. The description is complete for this purpose.

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

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

The schema fully documents both parameters with descriptions and examples (lineKey as 'v1', endpointId as UUID). The description does not add further parameter semantics, so the baseline 3 applies.

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

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

The description uses a specific verb 'Get' and clear resource 'endpoint', and further clarifies that it returns the full JSON including targets, auth keys, and attributes. It explicitly states 'one endpoint', distinguishing it from list_endpoints and mutation tools like create_endpoint or update_endpoint.

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

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

The description clearly indicates this is for retrieving a single endpoint's full JSON, providing clear context for when to use it. It does not explicitly mention alternatives like list_endpoints, but the singular scope and specific fields imply the appropriate use case.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the exact return fields, which is helpful behavioral context in the absence of an output schema. No contradictions with annotations.

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

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

A single, front-loaded sentence states the action and immediately lists the returned fields. There is no redundant information, and every word earns its place.

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

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

Given the simplicity (no parameters, read-only, no output schema), the description fully covers what the tool does and what it returns. The three listed fields provide complete context for the tool's output.

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

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

The tool has zero parameters, so the baseline is 4. The description appropriately focuses on the return value rather than parameter details, and the empty input schema needs no additional explanation.

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

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

The description uses the specific verb 'Returns' with a clear resource ('the project's key policy') and enumerates the exact fields returned (defaultKeyTtlDays, maxKeyTtlDays, editorsMayCreateNonExpiringKeys). This fully distinguishes it from sibling tools like set_key_policy or get_config.

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 you need to read the key policy) but does not explicitly mention when not to use it or mention alternatives. There is no direct comparison to get_config or set_key_policy, so guidance is only implicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds the specific scope of what is read (optimistic revision, preview, schedule) which is useful, but it does not disclose response format or any additional behavioral traits like auth requirements or potential errors. Given annotations handle the risk profile, this is adequate but not exceptional.

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

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

The description is a single concise sentence, front-loaded with the action 'Read' and resource, with no wasted words. It efficiently conveys the tool's purpose and scope.

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

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

For a simple read operation with one parameter and annotations providing safety info, the description is fairly complete. It names the key data returned (draft, revision, preview, schedule) even without an output schema. However, it does not explain what 'optimistic revision' or 'preview' entail, leaving minor ambiguity for an agent.

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

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

Schema coverage is 100% and the only parameter 'lineKey' is already described with an example ('v1'). The description adds no additional parameter semantics, so it meets the baseline for schema-covered parameters.

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

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

The description uses the specific verb 'Read' followed by the resource 'one line draft' and its components, distinguishing it from creation, deletion, and publishing tools. It clearly identifies the tool's scope as read-only retrieval of draft data, making it unambiguous among siblings like preview_line_draft and publish_line_draft.

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 needing to inspect a line draft and related revision/preview/schedule data, but it does not explicitly state when to use this tool versus alternatives, nor does it list exclusions. There is no mention of alternatives, but the read-only framing gives some context.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context: silent downgrade of week/month to day on free plans with planGated=true, dense zero-filled buckets, and scope-dependent latency series keys (relayP50 vs targetP50 vs p50) without blending. This goes well beyond the safety hints and fully discloses edge-case 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?

Though lengthy, the description is front-loaded with the core purpose and each subsequent sentence earns its place: scoping rules, plan restrictions, response shape, and dense-series detail are all meaningful. The structure uses semicolons and clear delimiter ('By default...', 'pass...', 'Returns...') to keep it organized 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?

With no output schema, the description takes full responsibility for explaining return values and does so thoroughly: lists the response keys, explains latency series variants by scope, notes planGated semantics, and clarifies that arrays are dense. Combined with the parameter and safety details, the description is complete for a 3-parameter, no-output-schema tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description enriches this by clarifying the mutual exclusivity of targetId/endpointId, default scope, and the plan-gating behavior of window. It also ties each parameter to a diagnostic question ('which target is degraded?'), adding practical semantics beyond the schema's field-level explanations.

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

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

The description opens with a specific verb and resource: 'Aggregate request metrics for this project over a time window' and lists the exact metrics (volume, error rate, p50/p95/p99 latency) and purpose (bucketed for charting). It clearly distinguishes itself from sibling tools like list_requests by focusing on aggregation and time-window bucketing.

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 each parameter: default behavior covers inbound requests, targetId slices outbound target degradation, endpointId slices inbound endpoint health, and 'Pass at most one of targetId / endpointId' is an explicit constraint. However, it does not name alternative tools for comparison (e.g., when to use list_requests instead), so it falls short of the explicit when-not/alternatives bar.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by specifying the response fields (id, slug, name, API base URL, edit access, retention window), which provides useful context about what the tool exposes.

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

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

The description is a single sentence that front-loads the purpose ('Get the EchoRelay project this token is scoped to') and then enumerates the key fields. There is no filler or redundancy.

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

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

For a simple, read-only, zero-parameter tool with no output schema, the description fully specifies what the tool returns. It is complete and leaves no ambiguity about the tool's behavior or output.

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

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

There are zero parameters, so the schema imposes no burden. The description confirms no inputs are required and instead lists outputs, which is appropriate for a zero-input tool. Baseline 4 is warranted.

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 the resource 'EchoRelay project' with a specific scope ('this token is scoped to'). It also lists the exact fields returned, distinguishing it from sibling get_* tools like get_endpoint or get_billing.

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

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

The context is clear: use this tool when you need the project associated with the current token. It does not explicitly mention alternatives or exclusions, but the unique token-scoping phrase makes the intended usage unambiguous.

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

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

Beyond the readOnlyHint annotation, the description explains nuanced internal behavior: queued/retrying deliveries read from a live copy while terminal ones read from durable storage, yet response shape remains identical. It also details what each field means (status, attempt, timestamps, terminalError, callbackState) and the meaning of unavailable reasons, giving agents deep insight into what to expect when invoking the tool.

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

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

The description is front-loaded with the main purpose in the first sentence, then expands into behavioral detail. It is dense but each clause adds meaningful information about response fields, statuses, or alternatives. A slightly more structured format (e.g., bullets for field lists) could enhance skimmability, but the prose is efficient and well-ordered.

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

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

Given there is no output schema, the description carries the full burden of explaining return values, and it does so exhaustively: it covers both terminal and non-terminal delivery states, the exact field names and their types, the conditions for unavailable reasons, and even mentions the callbackState field. This is complete enough for an agent to correctly parse and act on the response without further documentation.

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

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

The input schema already fully describes requestId with source (202 responses, list_requests rows) and required status. The description's reference to 'the same requestId a 202 response returned' adds no new parameter-level semantics beyond reinforcing the polling pattern. Schema coverage is 100%, so baseline 3 applies.

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

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

The description opens with a clear, specific verb+resource statement: 'Get every target this request fanned out to, each with its delivery receipt or the reason it has none.' This distinguishes it from siblings like get_request and list_requests, clarifying its unique scope as a receipt/log inspection tool rather than a general request fetcher.

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

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

The description explicitly says 'poll this on an interval with the same requestId a 202 response returned,' providing concrete guidance on when to use it (polling after a 202). It also names an alternative for sync_or_stream_delivery targets: 'see the response body from that call instead.' This gives both when and when-not 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 mark this as read-only and non-destructive. The description adds significant behavioral context: the null return when no matching row in the hot tier, the configVersion stamping semantics (0 = unstamped), and the inclusion of all per-target attempts. This goes beyond what annotations provide and is highly 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 three sentences, each carrying distinct, valuable information: the core function, the configVersion field meaning, and null/retention behavior. It is front-loaded with the main purpose and contains no redundant or irrelevant content.

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

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

For a single-parameter read tool with no output schema, the description thoroughly explains what is returned (envelope + attempts with statuses), scoping, null behavior, and the configVersion field. It also references get_project for the retention window, giving the caller all necessary 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 input schema fully documents the sole parameter 'requestId' with a clear description (UUID from 202 responses or list_requests rows). The description adds no additional parameter-level details, so the baseline of 3 is appropriate given the 100% schema coverage.

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

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

The description clearly specifies the action ('Get') and the resource ('one inbound request envelope'), and further details the included per-target attempts with their statuses. This distinguishes it from siblings like list_requests or get_dlq_entry by describing a unique, more comprehensive return payload.

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 useful context: it is scoped to the project and returns null if the request is outside the hot tier retention window, pointing to get_project for details. However, it does not explicitly name alternatives or say when not to use this tool, so it lacks explicit when/when-not 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?

Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description adds meaningful context: it enumerates the returned fields, specifies the ownership restriction, and notes the required billing scope. This gives the agent a richer operational picture than the annotations alone.

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 compact two-sentence structure with no unnecessary words. It front-loads the core purpose and then adds essential access constraints, making it highly efficient and scannable.

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

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

Given the tool has no parameters, no output schema, and minimal annotations, the description fully covers the agent's needs: exactly what data is returned and the prerequisites for invocation. There is no ambiguity about the action or its outcomes.

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

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

The tool has zero parameters, so the schema provides no parameter semantics. Per the baseline rule for zero-parameter tools, the description need not add parameter details. The description appropriately explains the fixed output, so a baseline of 4 is fitting.

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

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

The description clearly identifies the operation ('Get the project owner's current subscription') and lists the exact data returned (plan, active flag, period start/end, cancel-at-period flag, Paddle subscription ID, payment method status). This distinguishes it from sibling tools like get_billing by focusing specifically on subscription details.

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 access constraints: 'Owner-only' and 'requires a token minted with the billing scope.' This tells the agent who can use it and what credentials are needed. However, it does not explicitly name alternatives or provide when-not-to-use guidance beyond the ownership restriction.

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

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

Annotations only indicate non-read-only and non-destructive. The description adds meaningful behavior: the returned invitation record, the email with accept link, seat cap enforcement, and owner-only restriction. This is substantial context beyond the annotations, though it doesn't cover error cases.

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: first states purpose, second describes return and side effect, third lists constraints. Every sentence adds value with no repetition 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?

With no output schema, the description correctly explains the return value ('Returns the new invitation record') and covers side effects and constraints. It could mention duplicate emails or seat cap errors, but these are not critical for a typical use case.

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

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

Schema description coverage is 100% for both role and email. The description does not add any extra meaning to the parameters beyond what the schema already provides, so 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 action ('Invite a person by email'), the resource ('this project'), and the outcome ('collaborate'). This distinguishes it from sibling tools like remove_member, resend_invite, and set_member_role.

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

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

It provides key context by noting 'Owner only' and 'Enforces the seat cap', which implies when it should or shouldn't be used. However, it doesn't explicitly name alternative tools for related actions (e.g., resend_invite), so it's not a perfect 5.

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

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

Beyond the readOnlyHint annotation, the description discloses the exact return format, explains that 'project' is null for account-wide add-ons, and notes the permission requirement (billing scope). This provides substantial behavioral context not available from annotations alone.

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 only two sentences, front-loads the core purpose, and includes minimal yet essential details about the return structure and constraints. Every phrase contributes 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?

With no parameters and no output schema, the description fully covers the return values, project semantics, and authentication requirements. It is complete for the tool's simplicity and leaves no obvious gaps.

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

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

The tool has zero parameters, so the rubric sets a baseline of 4. Since no parameters exist, the description does not need to add parameter-level meaning; it appropriately focuses on output and usage details.

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

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

The description explicitly says 'List the project owner`s currently-active add-ons', giving a specific verb and resource. It also clarifies the 'project' field meaning, distinguishing it from list_addons by focusing on active add-ons and ownership scope.

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

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

The description clearly states when the tool is usable: 'Owner-only' and 'requires a token minted with the billing scope'. However, it does not explicitly mention alternatives (e.g., list_addons) or when not to use it, so it lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context: each entry is monthly, renews every 30 days until cancelled, and carries a scope field (per_account or per_project). It also explicitly says 'Read-only,' consistent with the annotations. This goes beyond the basic safety profile.

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

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

The description is two sentences. The first sentence front-loads the purpose with a clear verb ('List') and resource ('optional add-on subscriptions') plus illustrative examples. The second sentence adds billing and scope details. No filler or unnecessary repetition; even 'Read-only' serves as a quick safety cue that mirrors annotations.

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 list tool with no output schema, the description covers the key aspects: what is listed, examples, billing cycle, renewal, and scope. However, it does not clarify the difference from the sibling 'list_active_addons' (e.g., whether inactive or cancelled add-ons are included), which is a minor gap in contextual 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 has no parameters, so schema coverage is effectively 100%. With zero parameters, the description has no parameter details to provide, and the baseline of 4 applies. The description does not need to compensate for missing 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 tool lists optional add-on subscriptions, with concrete examples (RPM upgrades, extra team seats, extended log retention, extra file-delivery storage), and specifies the billing model (monthly, 30-day renewal). This distinguishes it from sibling tools like list_subscription_plans or list_active_addons by focusing on 'add-on subscriptions' and their recurring nature.

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 viewing add-on subscriptions and provides context about their monthly renewal and scope field, but it does not mention alternatives or explicitly state when to use this tool versus list_active_addons or other add-on/subscription tools. No exclusionary guidance is given.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds a crucial behavioral detail: 'the secret plaintext is never returned.' This goes beyond the annotation by explicitly stating a security-relevant limitation, which is exactly the kind of context agents need. With no output schema, this disclosure is especially valuable.

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

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

A single, front-loaded sentence delivers the core purpose and the key caveat without any filler. Every word earns its place, making it exceptionally concise and easy to parse.

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

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

For a tool with no parameters and no output schema, the description sufficiently covers what it does (list inbound API keys) and the critical limitation (no plaintext secrets). The context is complete for an agent to correctly select and invoke this 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 input schema has zero parameters, and schema description coverage is trivially 100%. Baseline for 0 parameters is 4. The description does not need to add parameter meaning since none exist.

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 starts with a specific verb 'List' and clearly identifies the resource as 'the project's inbound API keys.' It also adds the scope 'metadata only' which distinguishes it from related key-management siblings like create_api_key, revoke_api_key, and rotate_api_key. The purpose is unambiguous and well-differentiated.

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

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

The description clearly establishes when to use this tool: whenever you need a project's inbound API key metadata. It also implicitly signals when not to use it (when you want the secret plaintext, as that is explicitly never returned). However, it does not name alternative tools or provide explicit when-not guidance, so it falls short of a 5.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses key behaviors: newest-first ordering, redaction of outbound-target auth fields, retention policy (auditRetentionDays from get_project, default 365 days, purged by cleanup), and the exact return shape. This is substantial behavioral context.

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

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

The description is concise and well-structured: four sentences each add distinct information (purpose, scope, redaction, retention, response shape). It's front-loaded with the primary action and contains no fluff.

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

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

With no output schema, the description fully describes the return object ({total, limit, offset, retentionDays, rows[]}) and row fields. It also covers ordering, redaction, and retention, making it complete for a read-only list tool with 7 optional parameters.

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?

All 7 parameters have descriptions in the input schema (100% coverage). The tool description adds minimal additional parameter meaning—it echoes limit/offset in the return shape but doesn't explain parameter syntax or format beyond the schema. 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 function: 'List project audit-log entries, newest first.' It names a specific resource (audit-log entries) and provides scope ('Captures who changed what — lines, endpoints, targets, API keys'), distinguishing it from sibling list tools like list_api_keys or list_endpoints.

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

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

The description implies the tool's use case (inspecting project audit history) and gives context about ordering and content. It doesn't explicitly exclude alternatives or mention when not to use, but no sibling tool covers audit logs, so the context is sufficient.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds valuable context beyond this: it specifies that revisions are 'retained' (not all revisions) and scoped to 'one line', which clarifies the tool's scope and nuance.

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

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

The description is a single sentence that is concise, front-loaded, and contains no wasted words. It efficiently conveys the action, scope, and 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 simple one-parameter interface, presence of readOnly/destructive annotations, and no output schema, the description is complete. It tells the agent what the tool does, why it is used, and the scope, without needing to over-explain return values.

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

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

Schema coverage is 100% and the lineKey parameter is clearly described in the schema. The tool description adds minimal additional meaning beyond echoing 'one line', so the baseline score of 3 is appropriate given that the schema does the heavy lifting.

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 'retained revisions for one line', with a specific purpose: enabling selection of a prior revision for rollback. This distinguishes it from sibling tools like config_diff (which diffs) and rollback_config (which rolls back).

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

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

The description implies when to use this tool ('so a prior revision can be selected for rollback'), which provides clear context. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a full 5.

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

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

Beyond the readOnlyHint annotation, the description discloses that 'auth is redacted (secret fields never returned, even encrypted)' and points to create_credential for the rationale. This is a valuable behavioral detail about output and security that annotations do not provide.

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

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

The description is two sentences with the main action front-loaded. The first sentence names the operation and adds context about what credentials are; the second discloses the redaction behavior. Every sentence serves a purpose, and the structure is easy to parse.

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

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

For a simple list tool with no parameters and no output schema, the description is complete: it states what is listed (saved credentials), explains their purpose in the broader system, and warns about redacted fields. It also references create_credential for deeper context, which 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?

The tool has zero parameters, so there is nothing for the description to explain about parameter semantics. Per the baseline for zero-parameter tools, a score of 4 is appropriate; the description adds value by explaining the concept of credentials rather than parameter usage.

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

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

The description opens with 'List the project's saved credentials', a specific verb+resource that clearly states the tool's function. It distinguishes from siblings like create_credential, update_credential, and delete_credential by framing credentials as reusable target-auth secrets, and even differentiates from inline auth usage.

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

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

The description implies this tool is for viewing saved credentials that can be reused across targets, contrasting with inline auth per target. It does not explicitly say 'use this when you need to list credentials' or name alternatives, but the context is clear enough for an agent to infer the appropriate use case.

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?

It explicitly says 'Read-only,' which duplicates the annotation, but adds that packs are available to 'the project owner' and that eurCents is the identifying field. These details provide scoping and usage context beyond the basic readOnlyHint.

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

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

The description is two short sentences, front-loaded with the verb 'List,' and contains no redundancy or filler. Every clause 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?

For a parameterless list tool with clear purpose and a referenced follow-up action, the description is fully sufficient. No output schema exists, but the simple nature of the tool means the description covers what is needed.

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

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

The tool has zero parameters, so the parameter semantics are trivially satisfied. The description mentions eurCents as an output identifier, which is a useful hint without any formal parameter docs needed.

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

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

The description clearly states it 'List the prepaid credit packs the project owner can purchase,' which is a specific verb+resource. It distinguishes from sibling list tools by focusing on credit packs and referencing start_topup as the follow-up action.

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

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

The description gives practical guidance by saying 'Identify a pack to start_topup by its eurCents,' implying this tool is used to select a pack for purchase. It does not explicitly list alternatives or when-not-to-use, but the context is clear enough.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description goes far beyond that by disclosing return shape, eviction behavior, 30-day retention, non-persistence to DB, and the durable requestId relationship across replays. This adds critical behavioral context not available in annotations.

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

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

The description is front-loaded with the core purpose, then efficiently packs essential details about fan-out, return structure, retention, and related tools. Every sentence adds valuable information, and the structure flows logically from listing to behavioral nuances.

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, the description fully documents the return object and each field. It also covers edge cases like eviction, purging, and the relationship to get_request, making it complete for an agent to understand the tool's behavior without additional 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 the baseline is 3. The description doesn't add parameter-specific details beyond the schema, but the schema already documents limit and offset adequately. The description's mention of 'newest first' and 'evictedCount' indirectly relates to pagination and capacity but doesn't add parameter syntax.

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

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

The description opens with a specific verb and resource: 'List entries currently in this project's dead-letter queue, newest first.' It clearly distinguishes from sibling tools like get_dlq_entry (single entry retrieval) and discard_dlq_entry/retry_dlq_entry (mutations).

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

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

The description provides context on when to use this listing tool by explaining fan-out behavior and how it relates to get_request for purged entries. It also mentions get_dlq_entry accepts requestId lookup, implying the distinction between listing and single-entry retrieval, though it doesn't explicitly state 'use this instead of X'.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read. The description adds the line-scoping constraint but provides no extra behavioral context such as pagination, ordering, or return format. It adds minimal value beyond the annotations.

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

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

A single sentence with a clear verb and direct object. No filler or redundancy. The information is front-loaded and every word earns its place.

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

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

For a one-parameter, read-only list operation with strong annotations, the description is nearly complete. It clearly states what is listed and under what scope. It could mention that it returns all matching endpoints, but the simplicity and annotation coverage make this omission acceptable.

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 lineKey fully described (type string, example 'v1'). The description's mention of 'under one line' merely restates the parameter's purpose, adding no new semantics beyond what the schema already provides. Baseline of 3 is appropriate.

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

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

The description uses a specific verb 'List' with a clear resource 'endpoints' and scope 'under one line of the project'. It distinguishes from sibling tools like list_lines (which lists lines) and get_endpoint (which fetches a single endpoint). The purpose is immediately understandable.

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 you need endpoints for a specific line, reinforced by the required lineKey parameter. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select this tool over others given the 'line' scoping.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so no side effect concerns. The description adds that each line includes its endpoint count, providing useful output information. However, it does not address pagination, ordering, or whether draft lines are included, so some behavioral traits remain undisclosed.

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

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

The description is a single, focused sentence. It front-loads the action and resource, then adds a clarifying example and output detail. No filler or redundant information.

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

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

For a simple list tool with no parameters and no output schema, the description adequately indicates the return content (lines with endpoint counts). It could mention additional details like whether ordering or filtering applies, but given the simplicity, it is sufficiently 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 takes zero parameters, and the schema is empty with 100% coverage, so the baseline score is 4. The description adds no parameter-specific details because there are none to explain.

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

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

The description states 'List the project's versioned API lines' with a specific verb and resource, and adds the example 'v1, v2' to clarify what lines means. This distinguishes it from siblings like list_endpoints or list_projects.

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

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

The description clearly indicates its purpose: to list API lines. It gives context that these are versioned (v1, v2) and includes endpoint counts. However, it does not explicitly exclude alternatives or mention when not to use it, so the guidance is implicit rather than explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context beyond annotations: it identifies the tool as owner-only and details exactly what information is returned (name/email, role, invite acceptance). This goes beyond the minimal safety hints.

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

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

The description is two sentences, front-loaded with the core purpose, and contains no filler. Every sentence adds value: the first states the action and scope, the second details output fields and access control.

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

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

For a simple parameterless list tool with no output schema, the description covers the essential aspects: what is listed, what fields are shown, and who can call it. It is complete enough for an agent to understand what to expect and any constraints, though it could theoretically mention ordering or pagination, these are not critical for this simple 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 takes zero parameters, and the schema is empty with 100% coverage. Per the rubric, 0 params earns a baseline score of 4. The description adds no parameter specifics because none exist, which 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 action ('List') and the resource ('accepted and pending members of this project'), and specifies the displayed fields (name/email, role, invite status). It distinguishes itself from sibling member-management tools like invite_member or remove_member by focusing on listing membership.

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

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

Provides clear context: use to list project members, both accepted and pending. It includes an access restriction ('Owner only') but does not explicitly mention alternatives or when not to use it. The guidance is sufficient for an AI agent to select this tool for membership queries.

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

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

Beyond the readOnlyHint, the description adds critical behavioral context: the token type requirement, the scope needed, and that archived projects are included. It also discloses a failure mode (project-scoped tokens cannot call this). No annotation 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 two sentences that front-load the main purpose, then provide necessary conditions and exclusions. Every word earns its place—no redundancy or filler.

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

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

For a zero-parameter, read-only list tool, the description covers purpose, scope, token requirements, included data, and contrasts with project-scoped alternatives. No output schema exists, but the field list suffices. This is complete for the tool's 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?

The tool has zero parameters, so the baseline is 4. The description adds no parameter semantics, but none are needed. It does add context about return fields, which is useful but not parameter-related.

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

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

The description clearly states the tool's function: 'List the projects on your account (archived included)' and enumerates the exact fields returned. This specific verb+resource pairing distinguishes it from siblings like get_project, create_project, and archive_project.

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 usage conditions: requires an ACCOUNT-scoped token with 'read' scope, and explicitly states a project-scoped token 'cannot call this' and should use its own project's tools instead. This is direct when-to-use vs. when-not-to-use guidance naming 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 indicate read-only and non-destructive behavior. The description adds meaningful context by specifying the exact fields returned and stating that the secret is never exposed (only its hash is stored), which is important security-relevant behavior.

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

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

The description is two sentences, front-loaded with the core purpose, and efficiently packs essential details (fields, security, auth) without redundancy. Every sentence earns its place.

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

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

With no output schema, the description compensates by listing the return fields. It covers required auth scope, security behavior, and scope semantics. Minor gaps like pagination or whether revoked tokens are included exist, but the description is comprehensive for a simple list tool.

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

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

The schema already provides 100% coverage for the single parameter, describing it as 'The slug of a project you own.' The description reinforces ownership but adds no significant new meaning beyond the schema, 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 identifies the action ('List') and the resource ('API tokens scoped to a project you own'), with explicit scope ('any holder'). It also enumerates the returned fields, distinguishing it from general token-listing tools like list_api_keys.

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 states the prerequisite of an ACCOUNT-scoped token with the `read` scope, and clarifies that this is for project-scoped tokens. It does not explicitly name an alternative tool (e.g., list_api_keys) for account-level tokens, but the context is 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?

Beyond the readOnlyHint=true annotation, the description discloses ordering ('newest first'), a retention constraint (hot-tier window), and the full return shape including field-level semantics for configVersion, closeReason, and targets. This is substantial behavioral detail not derivable from annotations.

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

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

The description is well-structured and front-loaded: first sentence states the core action and ordering, then retention, then filters, then the return shape. Every sentence earns its place, and the detailed field list is necessary because there is no output schema.

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

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

The tool has 8 parameters and no output schema, yet the description covers all essential context: what it lists, ordering, retention window, filter behavior, and a complete enumeration of return fields including edge cases like '0 means unstamped' and closeReason values. This is fully adequate for an agent to invoke the tool 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%, with each parameter already having a description. The description adds only a general statement that filters narrow the result, and ties the hot-tier window to the project setting. It does not add meaningful new parameter semantics beyond the schema, so baseline 3 applies.

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

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

The description states a specific verb and resource: 'List inbound API requests the relay has processed for this project'. It also differentiates from siblings by indicating 'newest first' and the plural 'requests', making it clear this is a batch listing tool distinct from get_request.

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: 'Hot-tier window is the project's requestLogRetentionDays' and 'Optional filters narrow the result', implying when the tool is appropriate. However, it does not explicitly name alternatives or state when not to use it, so it lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description repeats 'Read-only' for reinforcement. The description adds details about the returned attributes but does not disclose additional behavioral traits like pagination, ordering, or auth needs. With annotations covering the main safety profile, this is adequate but not exceptional.

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

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

A single sentence efficiently front-loads the action and lists all relevant details (plan names, price in EUR, credit allowance, RPM cap, active projects) without any redundant or vague wording.

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

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

With zero parameters and no output schema, the description fully carries the burden of explaining the tool's return content. It enumerates the included fields and plan names, providing sufficient context for an agent to understand what the tool returns and that it is a read-only operation.

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

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

The tool has zero parameters, so the input schema is empty. The description appropriately does not attempt to explain parameters, and the baseline for no-parameter tools is 4.

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

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

The description clearly identifies the action ('List') and the resource ('subscription plans'), naming the specific plans (Free, Pro, Scale) and the attributes returned. It is distinct from sibling tools like get_subscription (current plan) and list_addons (add-ons), which serve different purposes.

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

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

The description implies when to use this tool (when you need plan details such as pricing and limits) but does not explicitly mention alternatives or exclusion criteria. For a simple listing tool, this is adequate though not explicit.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds 'without publishing it,' which reinforces non-mutating behavior but adds no further behavioral context such as return format, error handling, or visibility of the preview. It is consistent with annotations, with no 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 a single, tightly worded sentence that front-loads the verb and resource. Every word contributes meaning, with no fluff 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?

While the tool is simple with one parameter and no output schema, the description does not clarify what a 'preview' returns nor how it differs from get_line_draft. Since there is no output schema to fill this gap, the description carries the burden and falls short of fully contextualizing the behavior.

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

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

The input schema provides 100% coverage for the single parameter lineKey, including an example ('"v1"'), so the schema already fully documents the meaning. The description adds no extra parameter detail, landing at the baseline score of 3.

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

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

The description uses the specific verb 'Preview' with the resource 'one line draft' and adds the clarifying phrase 'without publishing it,' which clearly distinguishes this tool from siblings like publish_line_draft. It unambiguously states the action and scope.

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

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

The description implies the tool is used to inspect a draft without publishing, but it does not explicitly state when to use it versus alternative tools like get_line_draft or publish_line_draft. No exclusions or alternative recommendations are provided, leaving the usage context somewhat implicit.

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

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

Annotations already mark readOnlyHint=true and destructiveHint=false, so the read-only nature is known. The description adds value by disclosing the exact output fields, the meaning of the 'kind' values (applied vs. scheduled), and the auth/scope requirement. No hidden behaviors are left uncovered.

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, densely informative with zero filler. The first sentence front-loads the action and output, the second covers auth. Every clause adds value, and the parentheticals clarify the 'kind' enum without bloating the text.

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

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

Given the simple single-param schema and no output schema, the description fully compensates by listing all return fields and their semantics. It also includes prerequisite auth details, making it complete for an agent to invoke and interpret results 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 description coverage is 100%: the only parameter 'plan' has an enum and a description ('Target plan to preview a switch to.'). The tool description merely refers to 'this plan' without adding extra format or semantics beyond the schema. 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 begins with a specific verb-resource pair ('Preview what would happen if change_plan were called'), clearly distinguishing this from the actual sibling tool change_plan. It also enumerates the exact output fields (immediate-charge amount, next-invoice amount, effective date, kind), fully specifying its purpose.

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

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

The phrase 'if change_plan were called' establishes the tool as a preview companion to change_plan, implying usage before making a change. It also states prerequisites (Owner-only, billing scope token). It does not explicitly name alternatives or exclusion cases, but the context and sibling list make the intended use 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?

The description goes well beyond the annotations by disclosing idempotency, permanence, and the lack of any programmatic way to reverse the action (only contacting support). It also specifies the required token type and scope, which the annotations do not mention. This is exactly the kind of additional behavioral context that helps an agent understand the consequences and caveats of the tool.

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

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

The description is compact yet information-dense. It front-loads the main action, then immediately provides critical caveats (idempotent, permanent, auth requirements) in three sentences. Every sentence contributes meaningful guidance, and there is no redundant or filler content.

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

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

Given the tool's simplicity (one parameter, no output schema) and the presence of annotations, the description is fully complete. It covers the purpose, the effect on the sibling archive_project, the irrevocable nature, and the required credentials. There are no obvious gaps that would leave an agent uncertain about how to invoke the tool or what to expect.

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% coverage of the single parameter 'slug', which is described as 'The slug of a project you own.' The description does not add any new parameter-level detail beyond what the schema already provides, so the baseline score of 3 applies. It does reinforce the ownership requirement, but that is already present in the schema.

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

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

The description opens with a specific verb and resource: 'Turn on archive protection for a project you own.' It clearly distinguishes itself from the sibling tool archive_project by explaining that this tool prevents archiving, while archive_project performs the archiving action. The title 'Protect project from archiving' reinforces the purpose without ambiguity.

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

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

The description provides clear context on when to use this tool: to guard a project against archiving, and explicitly notes that archive_project will refuse until protection is lifted. It also states a prerequisite (ACCOUNT-scoped token and config scope), which helps agents decide if they are authorized. However, it does not explicitly name alternative tools or spell out 'use this instead of X', so it falls short of a full 5.

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

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

The description adds behavioral context beyond the annotations by specifying that only the schedule is cleared, not other settings. This aligns with the destructiveHint annotation and clarifies that the operation does not have broader side effects on the line itself. However, it does not disclose permissions required or the effect on the live line after publishing.

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

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

The description is a single concise sentence that front-loads the action and object, and it includes a precise qualifier ('clear only its schedule') that adds valuable nuance without unnecessary words. It is appropriately sized for the tool's simplicity.

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

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

The tool is relatively simple with two parameters and no output schema, but the description lacks parameter details and does not mention success/failure behavior or the outcome of publishing (e.g., whether the draft becomes live immediately). It provides a good overview but leaves some gaps that could affect correct 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?

The schema has two parameters (lineKey and draftRevision) with no descriptions, and the tool description does not mention either parameter. With 0% schema description coverage, the description should compensate by explaining what these parameters represent, but it entirely omits them, leaving their meaning unclear.

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 ('Publish'), the target ('line draft'), and the specific scope ('clear only its schedule'). This distinguishes it from related tools like schedule_line_publish and cancel_line_publish, making the purpose unambiguous.

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

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

The description implies an immediate publish action and mentions clearing the schedule, which differentiates it from scheduling tools. However, it does not explicitly state when to use this tool over alternatives like cancel_line_publish, nor does it mention prerequisites or conditions for use.

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

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

Annotations already indicate destructive behavior (destructiveHint=true). The description adds value by disclosing that pending members can be removed, the owner-only restriction, and the ability to identify members by ID or email. These behavioral traits go beyond the annotations without contradicting them.

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

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

A single, front-loaded sentence conveys the action, scope, and permission requirement. No filler or redundant phrasing. Every word 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?

For a simple tool with fully described parameters and annotations indicating destructiveness, the description is reasonably complete. It covers purpose, target scope, identification method, and permission. The lack of an output schema and the absence of edge-case details (e.g., no matching member) are acceptable given the schema's 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 baseline is 3. The description simply restates the two identifier options ('member ID or email') without adding new meaning beyond the schema's descriptions. It does not, for example, clarify the 'first matching member' behavior for email, which is present in the schema.

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

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

The description clearly states the action ('Remove'), the resource ('member'), the project context ('from this project'), and the identification methods ('member ID or email'). It also specifies member statuses ('accepted or pending'), distinguishing it from sibling tools like set_member_role or invite_member.

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 a member needs to be removed and adds an 'Owner only' permission constraint, but it does not explicitly state when not to use the tool or mention alternatives (e.g., use set_member_role to change a role instead). Thus, usage context is clear but alternative guidance is absent.

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

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

Beyond the destructiveHint annotation, the description explains that the slug never changes, which is critical behavioral context. It also discloses authentication requirements and the ownership error case, adding significant 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 two sentences and densely packed with essential information: purpose, constraints, auth, and error behavior. There is zero redundancy or filler.

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

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

Given the simple two-parameter schema and no output schema, the description fully covers the tool's purpose, authentication, parameter semantics, and failure mode. It is complete 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?

The schema already fully documents both parameters, but the description adds semantic value by clarifying that `name` is the display name and `slug` is the immutable identity used in URLs/Redis. This goes beyond the basic 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 renames a project, specifying that only the display name changes while the slug remains immutable. It distinguishes the operation from other project-related tools and adds crucial identity semantics.

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: you must own the project, need an ACCOUNT-scoped token with the `config` scope, and will get a 404-equivalent error if you don't own the slug. It doesn't explicitly discuss alternatives, but no other rename tool exists among siblings.

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

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

Beyond the annotations (readOnlyHint false, destructiveHint false), the description discloses important behaviors: the original accept link is reused, already-accepted members are rejected, and only the owner can perform the action. It also implies the side effect of sending an email. No contradictions with annotations.

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

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

The description is two sentences, front-loaded with the main action, and each clause adds meaningful information without repetition or fluff. It is a model of concise yet complete writing.

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

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

For a simple tool with two optional parameters and no output schema, the description covers the purpose, constraints, side effects, error condition, and permission. It does not specify the response format, but given the absence of an output schema, this is not a critical gap. Overall, it is sufficiently complete for an agent to use effectively.

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

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

The input schema already provides detailed descriptions for both parameters (email as alternative to memberId, targeting first matching pending invite; memberId as UUID from list_members). The tool description adds little beyond what the schema states, so with 100% coverage the baseline of 3 is appropriate.

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

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

The description clearly states the action ('Re-send the invitation email'), the target ('still-pending invite'), and the means ('by member ID or email (from list_members)'). It also adds distinctive details like reusing the original accept link and rejecting already-accepted members, which differentiates it from sibling tools like invite_member.

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 on when to use: 'for a still-pending invite' and specifies the exclusion 'Already-accepted members are rejected'. It also notes the permission requirement 'Owner only'. However, it does not explicitly name alternative tools for different scenarios, so it stops short of full comparative guidance.

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

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

The description discloses important behavioral details beyond annotations: it 'clears the cancellation', 'renews normally at the next cycle boundary', and notes 'No new charge — the cycle was already paid'. It also reveals the return shape and auth requirement ('Owner-only; requires a token minted with the billing scope'), giving the agent a full picture of side effects and prerequisites.

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?

Every sentence earns its place: purpose, condition, effect, no-charge clarification, exception, return payload, and auth requirement. It is front-loaded with the core action and remains readable despite covering multiple facets.

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

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

With only one parameter, no output schema, and minimal annotations, this description fully compensates by covering behavior, exceptions, return value, and access constraints. The agent has enough context to invoke it correctly and anticipate outcomes.

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 a clear description and example for addonKey, so the schema already carries the parameter meaning. The description adds no further parameter-specific semantics, which is acceptable given the baseline of 3 for well-covered schemas.

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

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

The description opens with a specific verb+resource: 'Resume (un-cancel) a pending-cancel add-on', clearly distinguishing it from sibling tools like subscribe_addon or cancel_line_publish. It also adds the precise condition 'whose paid-through cycle has not yet ended', making the tool's scope unambiguous.

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

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

The description states exactly when to use the tool: for pending-cancel add-ons whose paid-through cycle has not ended. It also gives a clear exclusion: 'Stackable add-ons cannot be resumed; buy a new unit instead', providing an actionable alternative.

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

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

The description states the tool will 'delete it from the DLQ', which is a destructive action, yet the annotations declare 'destructiveHint': false. This is a direct contradiction between the description and structured metadata, warranting a score of 1 and an annotation contradiction flag. While the description adds rich context about billing and insufficient-credits behavior, the contradiction undermines trust.

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 long, front-loaded with the primary action, and every sentence adds meaningful information: billing costs, failure behavior, and access requirements. It could be slightly more concise, but it is well-structured and free of fluff.

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

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

For a mutating tool with billing side effects and no output schema, the description covers most key aspects: the replay being billed, insufficient-credits handling, success/error semantics, and required edit access. It does not describe the success response format, but this is a minor gap given the tool's simplicity.

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

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

The schema has 100% coverage for the single parameter 'id', which is described as 'Redis stream id from list_dlq'. The description does not add further parameter-level detail, so it provides no extra value beyond the schema. Baseline 3 is appropriate when schema covers parameters adequately.

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

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

The description uses the specific verb 'Re-enqueue' and identifies the resource as a 'DLQ entry', clearly stating the main action and the side effect of deletion from the DLQ. This distinguishes it from sibling tools like 'discard_dlq_entry' and 'get_dlq_entry' by explaining the re-queueing behavior and billing implications.

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

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

The context implies use when retrying a DLQ entry, and it mentions success/error conditions ('Succeeds if the entry exists, errors if it's already gone'), but it does not explicitly contrast with alternatives such as 'discard_dlq_entry'. There is no direct 'when to use vs. when not to use' guidance beyond the name and error note.

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?

Annotation Contradiction: The description states that the tool 'returns it once, then destroys it; a second call errors,' which indicates a destructive, state-changing operation. However, annotations declare readOnlyHint=true and destructiveHint=false, directly contradicting the described behavior. Per rubric, a contradiction merits a score of 1 regardless of descriptive richness.

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

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

Three dense sentences communicate purpose, exclusions, one-shot behavior, destruction, error on second call, and availability precondition. No filler or repetition; every clause 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?

Description covers all critical context: one-shot retrieval, return value (plaintext), destruction semantics, second-call error, availability condition, and differentiation from rotate_api_key. Even with no output schema, the return type is clear from the description.

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

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

Schema coverage is 100%, with the parameter description 'UUID of the predecessor key whose successor to reveal' already providing clear semantics. The description adds minimal extra meaning beyond clarifying that the successor comes from auto-rotation. Baseline 3 is appropriate when schema fully covers parameters.

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

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

Description specifies a specific verb and resource: 'One-shot retrieval of the plaintext for a successor minted by the auto-rotation scheduler.' It explicitly distinguishes itself from rotate_api_key, which returns plaintext directly. This makes the tool's purpose unambiguous and differentiates it from siblings.

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

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

Explicitly states when not to use this tool ('not by rotate_api_key') and gives an availability condition ('Only available while the predecessor still has an unrevealed successor'). This provides clear guidance on when to invoke the tool versus 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 indicate destructiveHint=true, and the description adds valuable context: the key stops authenticating immediately on the next request, and permission scoping is specified. This goes beyond the annotations without contradicting them, though it does not mention whether the action can be undone or any side effects.

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

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

The description is extremely concise: two sentences with no redundant wording. It front-loads the core action and then adds essential details about timing and permissions. Every sentence earns its place.

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

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

For a simple one-parameter tool with annotations, the description covers purpose, effect, and permission context. It lacks an explicit comparison to rotate_api_key but is otherwise sufficient for an agent to understand the tool's role. The absence of an output schema is acceptable 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?

The schema fully documents the sole parameter keyId as a UUID, providing 100% coverage. The description adds no additional parameter format information, but the permission note ('Owner anywhere, editor on own keys') gives some context about authorization. Baseline 3 is appropriate since the schema already handles semantics.

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

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

The description clearly states the action ('Manual hard revoke') and resource ('API key'), and explains the immediate effect ('stops authenticating on the next request'). It distinguishes from sibling tools like rotate_api_key by emphasizing 'hard revoke' and 'manual', making the intent unambiguous.

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

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

The usage is implied: use when you need to permanently revoke an API key. Permission rules ('Owner anywhere, editor on own keys') provide context, but there is no explicit guidance on when to use this tool versus alternatives like rotate_api_key or revoke_project_token, nor any conditions for 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?

Beyond the annotations (destructiveHint=true), the description discloses soft-revoke semantics ('the row stays for traceability and the token is rejected immediately'), idempotency, and the permission requirement. This adds deep behavioral context that helps the agent predict side effects and access needs.

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

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

The description packs a lot of information into two compact sentences: scope, ownership, holder scope, use case, soft-revoke behavior, idempotency, and permission requirements. Every clause adds value with no 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 moderate complexity (2 params, no output schema), the description fully covers prerequisites, behavior, and use case. It even addresses edge cases like holder scope and soft-revoke, making it self-sufficient for correct 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?

The schema description coverage is 100%, so both slug and tokenId are already documented. The tool description does not add new parameter-level meaning beyond the schema, so the baseline of 3 applies.

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

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

The description begins with 'Revoke a PROJECT-scoped API token on a project you own' which is a specific verb+resource+scope statement. It also distinguishes from sibling tools by clarifying 'any holder's, not just your own' and framing it as an 'account-owner kill switch', clearly setting it apart from tools like revoke_api_key.

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 indicates the tool is for revoking project tokens on projects you own and frames it as a kill switch for leaked or retired tokens. It also states a hard prerequisite: 'Requires an ACCOUNT-scoped token and the `config` scope.' It does not explicitly contrast with alternatives, but the context is clear enough.

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

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

The description adds context beyond annotations by specifying the immediate publish and clearing of pending schedule, which are behavioral traits not implied by the destructiveHint. However, it does not disclose additional side effects, reversibility, or prerequisites, so the added value is moderate.