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?

The description adds substantial behavioral detail beyond the annotations: it states the operation is reversible (project+slug persist, data plane drops tenant with 404), idempotent, fails on archive protection, and requires an ACCOUNT-scoped token and config scope. These details are not in the annotations and give the agent a precise mental model of 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 front-loaded with the core action, then adds essential caveats (reversible, idempotent, protection error, token/scope) in a compact sequence. Every sentence carries information, and there is 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?

For a single-parameter tool with no output schema, the description covers prerequisites, error conditions, idempotency, and the effect on the data plane. It omits only the success response format, which is not critical 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?

The schema already fully documents the single slug parameter with 'The slug of a project you own,' and the description adds no additional semantic meaning beyond restating the ownership requirement. With 100% schema coverage, 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 opens with the specific verb 'Archive' and the precise resource 'a project you own,' clearly distinguishing it from siblings like unarchive_project. It further clarifies the scope by stating the project must be owned, and the reversible nature confirms it is the archiving action rather than a deletion.

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

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

The description gives clear context: you must own the project and have the required token and scope, and it fails if archive protection is enabled. However, it does not explicitly name alternatives or say 'use unarchive_project to reverse,' leaving some inference to the agent despite the sibling list being available.

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 cover read-only/non-destructive behavior. The description adds useful behavior beyond that: it checks the pending scheduled publish if one exists, and it redacts outbound auth secrets identically to get_config, warning the agent about sensitive output.

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, both purposeful: the first front-loads the operation and its diff scope, and the second adds the security-relevant redaction behavior. 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?

For a parameterless, annotated read-only tool, the description is complete: it states what will be diffed, the scheduled-publish exception, the scope of changes, and the redaction behavior. Nothing else is needed to call 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 tool takes zero parameters and the schema coverage is complete, so there are no parameter semantics the description needs to explain. Per the rubric, a no-parameter tool gets a baseline 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 names the specific action 'Preview' and the resource (the config diff against Save & Publish or the pending scheduled publish), then enumerates exactly what is included: changed lines, endpoints, targets, and project-level settings. This makes its function distinct from get_config/rollback_config even without naming them.

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 intended use—inspect changes before Save & Publish or when a scheduled publish is pending—but it never explicitly tells an agent when to choose this over alternatives such as rollback_config, get_config, or list_config_revisions, nor does it name any 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 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 say readOnlyHint=false and destructiveHint=false. The description adds the important extras: edit access is required, publish is the default side effect, and scheduledAt reaches beyond the endpoint to stage and schedule the parent line draft — a non-obvious cross-resource effect.

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 short clauses, zero filler, and the most decision-relevant fact (default publish) is front-loaded right after the purpose statement.

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 deeply nested create tool the description covers the mode/auth semantics an agent needs before invoking, and the endpoint payload itself is exhaustively documented in the schema. It omits nothing critical, though the interplay with scheduling siblings could be spelled out further.

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

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

Schema description coverage is 100%, so the schema already documents all five params including commitMode and draftRevision. The description largely restates those schema descriptions and adds no new syntax or format detail, 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?

States a specific verb and resource plus its scope: 'Create an endpoint under a line.' That is unambiguous and distinguishable from update_endpoint/delete_endpoint by plain meaning, but the description never names a sibling tool, so it stops short of 5.

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

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

Gives real context on which mode applies: publish is the default, draft requires draftRevision, and scheduledAt stages the line draft before scheduling. It does not point to alternatives (update_endpoint for existing endpoints, default_endpoint_template, discard_draft_endpoint), so no explicit 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 convey this is a non-read-only and non-destructive operation. The description adds meaningful behavioral detail: a newly created line has zero endpoints, publishes nothing, serves no traffic, and draft mode requires draftRevision 0. This goes beyond what the annotations and schema alone state.

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 tight sentences, front-loaded with the core purpose, then behavioral significance, then mode/access constraints. No filler or repetition of schema details.

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

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

Given no output schema and moderate complexity, the description covers the key operational implications: no traffic until an endpoint is added, draft mode needs draftRevision 0, and edit access is required. It could mention success/error behavior, but nothing essential for calling the tool correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents name, lineKey, commitMode, and draftRevision. The description adds value by explaining draft-mode behavior and the specific requirement that draftRevision be 0 for creation, which the schema alone does not convey.

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: 'Create a new versioned line.' It further clarifies what creating a line does (no endpoints yet), which distinguishes it clearly from sibling tools like create_endpoint and duplicate_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?

It explains the core usage context: creating a line alone has no traffic, and adding an endpoint publishes it. It also notes prerequisites like edit access and draft mode requirements. It does not explicitly name sibling alternatives, but the guidance is implied clearly 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), this description discloses server-side slug validation, plan-based active-project limits with error behavior, ACCOUNT-scoped token and config scope requirements, and the exact return shape. This is rich 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 longer than a simple one-liner, but every sentence carries decision-relevant information: purpose, validation behavior, plan limits, alternative routing, auth requirements, return value, and next step. It is front-loaded with the core purpose and remains appropriately sized 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?

Given a single required parameter, no output schema, and annotations that only indicate mutability, the description covers everything needed to call the tool correctly: what it does, when to avoid it, required permissions, failure modes, return shape, and the follow-up action. Nothing essential is missing.

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% and the only parameter, name, is already described in the schema with length constraints and slug derivation. The description's mention of slug derivation and validation adds marginal behavioral context but does not significantly enhance parameter 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 names a specific verb (create) and resource (project), explains the purpose of bootstrapping from a fresh account, and clearly differentiates create_project from create_project_token and the project-listing siblings. An agent can immediately understand what this tool does and what it is not for.

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 states when to skip this tool ('If an existing project can host this integration') and directs the agent to the appropriate alternative (create_project_token). It also discloses plan limits, required token scope, and the recommended next step, giving clear decision-making 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 only indicate non-read, non-destructive behavior. The description adds critical behavioral detail beyond that: minted tokens are attenuated, scopes must be a subset, expiry is mandatory, minted project-scoped tokens can never mint management tokens, and the plaintext is returned exactly once with only a hash stored. This goes well beyond what the 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?

The description is dense but well-structured: purpose first, then usage guidance, then constraints, then credential-handling behavior. Every sentence carries operational weight, and the security-relevant details justify the length.

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 discloses the critical return behavior ('Returns the plaintext exactly once; only its hash is stored'). It also covers prerequisites, scoping constraints, alternatives, and when-not-to-use, making it complete for correct 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 schema already documents all four parameters with 100% coverage, so the baseline is 3. The description adds meaningful semantic context: scopes are always subsetted, read is always included, spend is human-granted only, and 'never never' expiry is disallowed. This adds value 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 states a specific verb ('Mint') and resource ('PROJECT-scoped management token') with a clear scope boundary: it works for MCP and REST but cannot authenticate relay traffic. This distinguishes it from siblings like create_api_key, list_project_tokens, and revoke_project_token without needing to open their schemas.

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 says when to use the tool ('after create_project to configure a fresh project, or for any project you already own') and gives a when-not instruction with an alternative ('Mint a spend-scoped token from the project's panel instead'). It also states the required calling context: an ACCOUNT-scoped management token with the 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?

Beyond the readOnlyHint annotation, it discloses the key behavioral quirk: the response has mock: true, uses a canned body, and never dials the target. It also explains that a 200 only proves reachability, not delivery, which is essential for correct interpretation.

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 focused sentences and each one earns its place: what it returns, how to use it, and what its mock behavior implies. The most important caveat is spelled out rather than implied.

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-only template generator with no output schema, the description fully covers the essential context: what the output is, how it should be consumed, and what not to assume about its 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 only parameter, lineKey, is already fully described in the schema with an example, so schema coverage is 100 percent. The description does not add extra meaning about the parameter, which is acceptable but also not a differentiator.

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 action and resource: 'Return a canonical minimal-valid endpoint JSON for a fresh line.' This clearly identifies the tool as a template generator and distinguishes it from endpoint CRUD tools like create_endpoint or get_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?

It gives an explicit workflow: POST the result verbatim to create_endpoint, then customise. It also tells the agent when the result should not be trusted as delivered: set mock to false and provide a real target URL first.

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 mark destructiveHint=true, but the description goes far beyond that: it discloses the staged deletion path, the return payloads for both modes, the rollback possibility via list_config_revisions and rollback_config, error conditions, and the edit-access requirement. This rich behavioral context fully complements the annotations and contradicts none of them.

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

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

The description is a single dense paragraph but each sentence adds value: modes, returns, rollback, errors, access. It is front-loaded with the primary action and then details. Slightly long but no filler; it earns its length given the complexity of the two-mode behavior.

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

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

For a mutation tool with no output schema, the description explains return values for both modes, error scenarios, and prerequisites (edit access). It covers the necessary information for an agent to call it correctly. Minor omissions: it doesn't specify what 'targets' includes or what happens if the endpoint is already deleted, but error handling covers the latter. Overall, fairly complete.

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

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

Schema description coverage is 100%, so the schema already documents each parameter. The description reinforces that commitMode defaults to publish and draft writes require draftRevision, but this is already stated in the schema. It does add the semantic that deletion affects 'targets', but that is not parameter-specific. No additional parameter meaning beyond the schema is provided, so a baseline 3 is appropriate.

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

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

The description states a specific verb ('delete') and resource ('endpoint and its targets'), and distinguishes between immediate and staged deletion via commitMode. It clearly separates this from siblings like update_endpoint and discard_draft_endpoint by explaining the two modes and the draft behavior.

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

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

It provides explicit guidance on when to use immediate vs staged deletion (draft mode with commitMode and draftRevision). It does not explicitly name alternative tools or state when not to use this tool, but the mode distinction is a clear usage guideline. Missing exclusionary guidance for siblings like discard_draft_endpoint is a minor gap.

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

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

Beyond the annotations (destructiveHint: true, readOnlyHint: false), the description discloses that the operation cascades to endpoints, permanently removes revision history (making rollback impossible), returns a draft object when staged, and lists specific error triggers. It also notes that edit access is required. This goes well beyond the annotation hint and gives the agent a full picture of 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 dense but every sentence serves a purpose: the first sentence defines the action and modes, the second explains consequences, the third lists errors, and the fourth states the access requirement. It is front-loaded with the core action and does not waste words. Structure is clear and efficient.

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

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

Given the complexity of the tool (cascading deletes, two modes, revision history impact, error conditions), the description covers all essential aspects. It explains the draft return value, mentions the inability to roll back, lists errors, and states prerequisites. No critical information is missing for an agent to invoke it correctly, and the lack of an output schema is compensated by describing the draft return.

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 documents all three parameters with descriptions, so the baseline is 3. The description adds meaningful context by explaining how commitMode and draftRevision interact (draft mode requires draftRevision and returns a draft object), and clarifies that lineKey errors occur when missing or unmatched. This adds value beyond the schema, earning a 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 states a specific verb ('delete'), a specific resource ('a line'), and the scope ('every endpoint under it'). It clearly differentiates from siblings like delete_endpoint by scoping to the line level, and it also distinguishes the draft staging mode. The purpose is unambiguous and distinct from similar tools.

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

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

The description explicitly explains when to use draft mode vs. immediate publish mode, and references discard_line_draft as an alternative for undoing a staged delete. It also states the error conditions and access requirement. However, it does not explicitly name delete_endpoint as the alternative for deleting a single endpoint, though the scope makes that clear. Overall, usage guidance is strong but not exhaustive.

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

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

Annotations already mark destructiveHint=true, but the description goes beyond that by adding nuances: the entry cannot be restored, errors if already gone, the inbound request remains answerable through get_request for a retention window, and requires edit access. These behaviors are not inferable from annotations alone and provide critical operational context.

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

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

The description is compact but information-dense. It front-loads the core action, explains the side effect, provides the alternative, and notes error and permission conditions—all in two sentences without redundancy. 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 destructive single-parameter operation, the description covers all necessary aspects: what it does, what it does not do, consequences on related data, error scenarios, permissions, and the alternative tool. No output schema exists, but the description adequately sets expectations for the side effects, making it complete for an agent to invoke correctly.

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

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

Schema coverage is 100% with the single 'id' parameter described as 'Dead-letter entry id from list_dlq.' The description adds no additional parameter-specific information, but since the schema already fully documents the parameter, 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 states a specific verb ('Permanently delete'), a specific resource ('DLQ entry'), and defines the behavior clearly: 'the delivery is never re-sent and the entry cannot be restored.' It explicitly distinguishes itself from its sibling retry_dlq_entry, making it unambiguous which operation is meant.

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 usage guidance: 'Use retry_dlq_entry instead when the delivery should still reach its target.' It also states error conditions (entry already gone) and permission requirement (edit access), which clarifies when to use and when not to.

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?

Annotations already establish readOnlyHint=true and destructiveHint=false, so safety is partly covered. The description adds concrete value beyond that: no DB write, no queue entry, no billing, payload never sent, plus the exact success/failure return shape ({ok:true, resolved} / {ok:false, errors}). Side-effect disclosure is the key addition here.

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?

Front-loaded with the core action and return shape, then the mode switch, then the optional sampling behavior, and finally the no-side-effects guarantee. Every sentence carries distinct information with no padding.

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 complex tool with no output schema, the description compensates by stating both return envelopes and what the evaluation output contains (field provenance, failing rules, offending values). Combined with the fully documented schema, an agent has everything needed to call it correctly in either mode.

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, but the description adds real semantic value: endpointId selects PATCH-vs-create mode, and sample/answerSample are explained as driving outgoingMapping/answerMapping evaluation and as traveling in opposite directions so answerSample cannot be inferred from sample.

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?

Uses a specific verb (validate/dry-run) on a specific resource (an endpoint document) and immediately signals the non-writing nature, which is exactly what separates it from create_endpoint and update_endpoint. An agent can distinguish it from all siblings without opening a schema.

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 branches on the endpointId parameter: pass it to dry-run a PATCH against an existing endpoint, omit it to dry-run a create, and pass sample/answerSample to exercise target mappings. It does not explicitly name the create_endpoint/update_endpoint alternatives it pairs with, but the when-to-use conditions for each mode are 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 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 only declare readOnlyHint=false and destructiveHint=false; the description carries substantial behavioral weight beyond that. It discloses the non-guessing policy ('Nothing is guessed'), the unmapped list for unmatched target fields, the 'inferred': true flag on each mapped field in the stored mapping tree, the draft-never-publish guarantee, and the 'Requires edit access' permission. There is no contradiction with the annotations — a draft write is consistent with readOnlyHint=false.

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 core verb and resource are front-loaded in the first sentence, with supporting behavioral detail (non-guessing, unmapped list, draft-not-publish) following. It is a single dense paragraph of roughly 150 words, which is justified given 9 parameters, mutually exclusive modes and nested objects, but it could be tightened or structured slightly.

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 — 9 parameters, nested objects (sample, targetSample), mutually exclusive input modes, an enum, and no output schema — the description covers the operational essentials well: both input paths, mapping semantics, the unmapped list, the inferred flag, the draft pipeline, and the access requirement. It does not spell out the exact return shape, but it describes the stored mapping tree and unmapped output, which fills most of what an output schema would convey.

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 every parameter described, so the baseline is 3. The description adds workflow-level meaning on top: it consolidates the two mutually exclusive input modes (targetDocument vs targetSample+targetUrl), references the servers[]-wins precedence over targetUrl, and ties targetFilename's YAML/JSON role to targetDocument. This relational gloss exceeds what the individual schema descriptions provide.

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?

States a specific verb+resource ('Generate a draft endpoint under a line') and describes a concrete mechanism: infer the inbound body schema from a sample, read the target's method/URL/fields from an OpenAPI document or bare sample + targetUrl, and propose a same-named outgoingMapping. It explicitly contrasts itself with filtering/publishing siblings by declaring it 'always writes a draft (never publishes)', with downstream flow through preview_line_draft, dry_run_endpoint, config_diff and publish_line_draft, so an agent can separate it from the similar-named draft/publish tool family.

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?

Gives clear context on what inputs drive the tool (targetDocument XOR targetSample+targetUrl, deliveryMode, draftRevision) and states the exclusion 'never publishes', which routes agents to publish_line_draft for the publish step. It names the downstream pipeline tools. It does not explicitly spell out when this should be used instead of create_endpoint, but the draft-vs-live distinction is strongly implied.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description goes far beyond that by disclosing subtle behaviors: zero balance does not block live traffic, free-tier projects are exempt, only the testing pool refuses with a specific 402 error, and overage fields appear only on Pro/Scale plans. It also clarifies that invoiceable accounts show empty credits by design. This is exemplary transparency 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 lengthy but every sentence adds value: it covers the core function, billing model semantics, edge cases, overage fields, and throttling. It is front-loaded with the main purpose and then logically expands into details. The structure is organized by concepts (billing model, zero balance, overage) rather than rambling. Given the complexity of the returned data, this level of detail is justified and concise in its own right.

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 is the only source of return semantics. It thoroughly documents the fields (billingModel, credit balances, overage object with usedCredits, overageCredits, amount, currency, windowEndsAt, throttled, throttledUntil) and their conditional presence. It also explains interpretation pitfalls (invoiceable empty credits, zero balance not blocking). An agent can fully understand the response without further documentation. This is complete for a 0-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?

The input schema has zero parameters, so schema description coverage is trivially 100%. Per the rubric, a 0-parameter tool gets a baseline of 4. The description appropriately does not discuss parameters since there are none, and it focuses on the output instead. No additional parameter semantics 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 precise verb and resource: 'Get the project's credit balances (paid + testing) and which ledger it settles on.' It clearly distinguishes this tool from siblings like get_receipts or get_subscription by focusing on credit balance and billing model. The detailed explanation of billingModel further sharpens the 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?

It provides explicit guidance on when to consult this tool ('Read this before concluding from any other field that a project cannot send'), which is a strong usage directive. It also contrasts with the sibling set_overage_billing for modifying overage settings, and explains edge cases (free-tier exemption, invoiceable accounts) that inform correct usage. This is more than most tools offer.

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?

The text adds meaningful behavioral nuance beyond the provided readOnlyHint: id is ephemeral, requestId is durable across retries, fan-out may produce multiple entries, and each entry includes configVersion with 0 meaning unstamped. It also discloses error and aging semantics. Some gaps remain on authentication or explicit response shape, but the annotations already cover the read-only 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 dense but well-organized: it leads with the action, then explained an important ambiguity (id vs requestId), and ends with error semantics. There is no filler; every clause earns its place, though a minor simplification could improve readability.

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 does what is needed: it introduces the return entry contents (configVersion), clarifies fan-cut multiplicity, and states not-found behavior. It does not enumerate all entry fields, but for a read-one tool with rich annotations and schema coverage, the provided context 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 100% description coverage, already explaining id and requestId formats, mutuality, retry stability, and fan-out behavior. The description adds value via the `{ms}-{seq}` pattern and the configVersion mention, but it mostly restates what the schema and oneOf constraint already clarify.

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 by clearly defining a specific action ('Get DLQ entries') and names its two distinct access modes (entry id or requestId). It grounds id in list_dlq's output, which distinguishes this tool from the list and other DLQ siblings without opening schemas.

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

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

The description gives explicit, actionable guidance: use requestId for stable tracking across replays, and use id when you have the exact entry id from list_dlq. It notes that id changes on every replay and that requestId captures every fanned-out target, which directly informs tool selection.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses critical behavior: target secrets are redacted, and a targets array sent back through update_endpoint must carry each target's secret again. It also states error conditions for missing arguments or nonexistent lines/endpoints. This is valuable, non-obvious context that annotations alone would 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 focused and front-loaded: core purpose in the first sentence, a crucial redaction warning in the second, and error behavior in the third. The field list is long but necessary since there is no output schema; no words are wasted.

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?

Because there is no output schema, the description compensates by naming the returned fields and explicitly noting redaction behavior. It also covers error cases. It does not describe the full JSON nesting or provide examples, but for a simple getter with two well-documented parameters, 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 input schema already provides 100% coverage with descriptions for lineKey and endpointId, including an example and type. The description repeats the parameter names but adds no new parameter-level semantics beyond the overall document scope; 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 and resource: 'Get one endpoint's full document by `lineKey` and `endpointId`.' It clearly distinguishes this from sibling list tools by emphasizing a single endpoint, and it enumerates the exact returned fields, leaving no ambiguity about 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 usage through required arguments and singular scope: use this when you need one endpoint's full document. It also mentions the round-trip caveat with update_endpointunci. However, it does not explicitly state when to prefer this over list_endpoints or other sibling tools, nor does it give explicit 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile needs no repetition. The description adds genuine context beyond that: the meaning of each returned field and how create_api_key enforces them when minting a key (default when ttlDays is omitted, enforced limits). This tells the agent what the values signify and how they behave downstream. It omits error behavior, but the read-only, zero-param nature makes that a minor gap.

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

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

Two sentences, zero filler. The primary purpose is front-loaded ('Return the project's key policy'), followed by precise field semantics and a routing note. Each clause earns its place — the create_api_key references explain why the returned fields matter without bloating the description.

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 tool with no output schema, the description is complete: it enumerates the return fields, explains their semantics, and names the mutation sibling. The annotations carry the safety profile, so nothing an agent needs to invoke this tool correctly is missing.

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

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

The tool has zero parameters and the schema confirms this with an empty properties object, so there is nothing to document. The description correctly focuses on the return values instead, which is the relevant semantic content. Per the baseline for zero-param tools, a 4 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 opens with a specific verb and resource pair — 'Return the project's key policy' — then enumerates the exact fields returned (defaultKeyTtlDays, maxKeyTtlDays, editorsMayCreateNonExpiringKeys). It differentiates from its sibling set_key_policy by framing get as the read counterpart and clarifying that these values are what create_api_key consumes.

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 routes the agent: 'use set_key_policy to change these values' names the alternative tool and the condition that selects it (mutation vs. read). It also clarifies the relationship to create_api_key, telling the agent that this policy governs key minting defaults and limits, which helps decide when fetching it is relevant.

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 declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context: the return of null after log retention, the meaning of configVersion (0 = unstamped), and the inclusion of per-target attempts with specific statuses. This enriches the agent's understanding 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 zero redundant text. The core function (getting the envelope and attempts) is front-loaded, and the edge case about retention is placed second. Every sentence adds value.

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

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

Given a single parameter and no output schema, the description covers the return payload structure (envelope + attempts with statuses), the configVersion semantics, project scoping, and the aging-out null case. It also points to get_project for the retention setting, making it complete for an agent to call 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 fully describes the sole parameter (requestId) with its source and format at 100% coverage. The description adds no additional parameter-specific meaning, but it does not need to because the schema is already complete. 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 ('Get') and resource ('one inbound request envelope + every per-target delivery attempt'), and lists the four statuses covered (success / permanent_failure / retry_scheduled / dlq). It clearly differentiates from list_requests (which lists rows) by focusing on a single request with full delivery attempt detail.

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 of returning null after the retention window and being scoped to the project provides clear usage context, and it references get_project for retention config. However, it does not explicitly name alternative tools or state when not to use it, 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 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?

The description adds meaningful behavioral detail beyond the readOnlyHint annotation: the secret plaintext is never returned, only a specific set of metadata fields is included, and the response shape is `{keys: []}` with no paging. This gives the agent a clear picture of what will happen and what to expect.

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 are used efficiently: the first states the operation and the key non-behavior (no secret plaintext), and the second gives the response shape and paging behavior. The field enumeration is necessary because no output schema exists.

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 no-parameter read-only list tool, the description fully covers the operation, the response format, and the lack of paging. An agent can invoke it without further clarification, and annotations already confirm it is non-destructive.

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

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

There are zero parameters and the schema coverage is 100%, so there is no parameter gap to compensate for. The description adds value by enumerating the exact response fields, which is more than the empty schema 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 uses a specific verb and resource ('List the project's inbound API keys') and immediately clarifies it returns metadata only, never the plaintext secret. This clearly distinguishes it from siblings like create_api_key, revoke_api_key, and rotate_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 implies the tool is used to retrieve all API key metadata in one call, and explicitly notes there is no paging. However, it gives no explicit when-not-to-use guidance or mention of alternatives such as create_api_key for obtaining plaintext secret values.

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 description rightly focuses on adding context beyond them: returns `{revisions: []}` with no paging, the four fields per entry, and error conditions for missing or unmatched lineKey. This meaningfully enriches the contract without repeating annotation data. It doesn't 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?

Three sentences, zero filler: purpose with ordering, return shape with fields and paging behavior, and error conditions. The most decision-relevant fact (what it lists and why) is front-loaded, 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 single-parameter read-only tool with no output schema, the description covers everything needed to call it correctly: purpose, ordering, return shape, fields, paging, and error conditions. The description compensates fully for the missing output schema, and nothing an agent needs is left ambiguous.

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 the single required lineKey parameter, so the baseline of 3 applies. The description adds marginal value by explaining in the error clause that lineKey must match a line in the project, reinforcing validity semantics, but it doesn't add syntax or format details beyond the schema.

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

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

The description uses a specific verb-resource pair ('List every retained revision of one line') with ordering ('newest first') and ties the purpose to a concrete downstream action ('so a target revision can be picked for rollback_config'). This clearly distinguishes it from siblings like get_config, config_diff, and rollback_config without needing to open schemas.

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

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

The description gives clear context by positioning the tool as the precursor to rollback_config, telling an agent when this tool is the right call. It stops short of a 5 because it does not explicitly name alternatives or state when NOT to use it (e.g., get_config for the current config), but the implied workflow is 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 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?

Beyond the readOnlyHint and destructiveHint annotations, the description adds valuable behavioral detail: the response is a bare array, not paginated, returns the entire catalog every time, and is not wrapped in an envelope. This is exactly the kind of non-obvious behavior an agent needs to know before invoking.

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 core purpose, then efficiently packs the essential behavioral caveats (bare array, no pagination, whole catalog, read-only) and a routing hint to start_topup. Every clause 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 zero-parameter, read-only listing tool with no output schema, the description covers everything needed: what it returns, the exact item shape, the non-envelope/non-pagination behavior, and how to use the result with a sibling 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?

There are zero parameters, and the schema is fully covered with no properties. The description still adds meaning by documenting the exact object fields returned, which is helpful since there is no output schema. Baseline 4 for a parameterless tool 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: 'List the prepaid credit packs available to purchase.' It also distinguishes the tool's scope by describing the exact return shape and referencing start_topup as the follow-up action, making its purpose unambiguous among many sibling list tools.

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

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

The description provides clear context: this is a read-only catalog listing used to identify a pack before calling start_topup. It names the relevant sibling action but does not explicitly enumerate when not to use this tool or compare it to other list alternatives, so it falls just 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 declare readOnlyHint=true and destructiveHint=false, but the description goes far beyond this by explaining fan-out per-target, 30-day retention, automatic purging, capacity-cap eviction, non-persistence to a database, and the id-versus-requestId semantics on replay. This is rich behavioral disclosure 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 front-loaded with the core purpose and then provides dense, non-redundant detail about return fields, retention, eviction, and id behavior. It is a long single paragraph rather than a structured layout, but every sentence earns its place given 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?

For a complex tool with no output schema, the description is remarkably complete: it specifies the response shape, field-by-field semantics, retention and eviction behavior, and how this tool relates to get_request and get_dlq_entry. An agent has enough to call it correctly and interpret results.

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?

Both parameters, limit and offset, are fully documented in the input schema with ranges and defaults (100% schema coverage). The description adds no additional parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'List entries currently in this project's dead-letter queue, newest first.' It clearly distinguishes this listing operation from related siblings like get_dlq_entry, discard_dlq_entry, and retry_dlq_entry, so an agent can tell what it is for without opening schemas.

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 contextual pointers, such as get_request still answering for purged/evicted entries and get_dlq_entry accepting requestId as well as id, which implies when a more targeted lookup is useful. However, it never explicitly states when to use list_dlq versus get_dlq_entry, nor does it give exclusions or alternative-selection rules.

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 mark this as read-only and non-destructive, and the description goes well beyond them by disclosing the exact return shape, the absence of paging, the specific fields returned, and the error cases. This provides rich behavioral context without repeating the annotation data.

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

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

The description is three sentences with no filler: purpose and return shape in the first sentence, field detail and the get_endpoint contrast in the second, and error conditions in the third. Every sentence earns its place and the most important information is front-loaded.

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

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

There is no output schema, so the description carries the responsibility for explaining the result. It fully covers the return envelope, the endpoint entry fields, the lack of pagination, and error behavior, which is sufficient for an agent to call and interpret 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 input schema already fully describes lineKey with type and example, so the baseline is 3. The description adds value by clarifying that lineKey identifies the line and by specifying error behavior for missing or unmatched lineKey values, going beyond just 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: 'List the endpoints under one line, identified by `lineKey`.' It also distinguishes itself from the sibling get_endpoint by stating that it returns summary fields, not the full endpoint body, leaving no ambiguity about 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?

It explicitly names get_endpoint as the alternative for full endpoint bodies, telling the agent when not to use this tool. It also provides concrete failure conditions ('Errors when lineKey is missing or doesn't match a line'), which gives practical guidance on prerequisites and expected usage.

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 useful behavior: it returns a `{lines: []}` envelope in one call, includes specific fields per entry, and has special handling for empty projects. No contradiction exists, and no destructive or side-effect behavior needs disclosure.

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

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

The description is compact and front-loaded: it states the action and scope first, then the return format, then the per-entry fields, and finally the edge case. Every sentence adds useful information and nothing 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?

Given the tool has no parameters and no output schema, the description fully covers what an agent needs: the response envelope, the fields included, no-paging behavior, and the empty-array edge case. There are no meaningful gaps for correct 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 tool has zero parameters, so the baseline of 4 applies and the description does not need to explain parameter meaning. It appropriately focuses on the output shape and behavior rather than adding unnecessary parameter 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 states a specific verb and resource ('List every line'), specifies the scope ('in the project'), and gives the exact return envelope. This distinguishes it from the many line-related siblings like activate_line, create_line, and delete_line 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?

It clearly conveys when to use the tool: to retrieve the complete line list in one call with no paging, and it reassures that an empty project returns an empty array rather than an error. It doesn't name an alternative or exclude use cases, but no sibling tool appears to duplicate this exact listing operation.

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 read-only and non-destructive, and the description adds valuable behavioral details: no paging, exact return fields (members, count, seatCap, seatsUsed), and auth/error 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 dense sentences, each earning its place: the first defines scope and fields, the second explains return structure and paging, the third covers errors and ownership. 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?

With no output schema or parameters, the description fully specifies the return shape, field semantics, paging behavior, and error conditions. An agent has everything needed 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?

The tool has no parametersage, and schema description coverage is 100%, so there is nothing for the description to add. Baseline 4 is appropriate because parameter semantics are trivially covered.

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

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

The description clearly identifies the tool as listing project members, including the owner, with specific fields. This distinguishes it from sibling member-related tools like invite_member, remove_member, 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 explicitly states 'Owner only' and specifies error conditions for non-owners or missing config scope, providing clear when-not guidance. It doesn't name an alternative tool, but no sibling provides the same roster-listing functionality.

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 the operation as read-only and non-destructive, and the description adds meaningful context: the required token scope, the included `accountEmail` detail, and the archived-inclusion behavior. It doesn't discuss pagination or rate limits, but those are minor for a parameterless list operation.

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

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

Two focused sentences. The first sentence delivers the core purpose and return fields; the second provides authentication requirements and redirects mis-scoped tokens. No filler or redundant restatement.

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 listing tool, the description covers what it returns, what authentication is required, and what cannot be done. Given no output schema exists, the return-field specification is sufficient for an agent to invoke and interpret 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 tool has zero parameters, so the description has no parameter meaning to add. It instead clarifies the return payload fields)Skip the `accountEmail` field, which is useful given the absence of an output schema. This meets the baseline for a parameterless tool.

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

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

The description states a specific verb ('List') and resource ('projects on your account'), explicitly notes archived projects are included, and enumerates the exact fields returned. This clearly differentiates it from related tools like get_project or list_project_tokens.

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

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

The description gives explicit prerequisites: ACCOUNT-scoped management token with `read` scopemen. It also states a clear exclusion—PROJECT-scoped tokens cannot call this—and directs to use the project's own tools instead. This is precise when-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?

Beyond the readOnlyHint annotation, the description adds important behavioral details: the secret is never returned (only its hash is stored) and the fields that will be present. This is valuable context for an agent deciding whether to call this tool.

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

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

The description is a single sentence that front-loads the purpose and then adds key details. It is efficient, though slightly dense with the field list and auth requirement.

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 tool with an output schema absent, the description covers what is returned, what is not returned, and the authentication requirement. Missing pagination/limit info is a minor gap given the 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 input schema already describes 'slug' as 'The slug of a project you own' with 100% coverage. The description reinforces ownership but does not add new parameter-level semantics beyond the schema.

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

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

States a specific verb ('List') and resource ('management tokens scoped to a project you own'), and enumerates the returned fields. This clearly differentiates from siblings like create_project_token and revoke_project_token, and from 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?

Provides clear context: the tool is for listing management tokens for a project, and it specifies the required token type and scope. It does not explicitly name alternatives or when not to use it, but the description makes the use case 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=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?

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses idempotency, irreversibility (permanent, only support can reverse), and the behavioral side effect on archive_project. It also specifies authentication requirements. This is substantial additional context that helps the agent predict consequences.

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 sentences, each earning its place: purpose and effect, idempotency, permanence, and auth requirements. The core purpose is front-loaded. No filler or redundant explanation.

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 tool with no output schema, the description fully covers what the tool does, its behavioral impact, reversibility, idempotency, and prerequisites. An agent has everything needed to decide whether and how to 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?

Schema description coverage is 100% and already states 'The slug of a project you own.' The main description repeats the ownership condition but adds no new parameter-level details (format, constraints, or edge cases). 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 action ('Turn on archive protection') on a specific resource ('a project you own') and distinguishes it from related tools by explaining the effect on archive_project. The annotation title reinforces the purpose. It clearly separates this from archival/unarchival actions.

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

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

The description gives clear context: it is used for projects you own, affects archive_project's behavior, and requires a specific token and scope. It also warns of permanence, which informs the decision to use it. It does not explicitly name alternative tools or state when not to use it, but the conditions are well 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?

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 declare destructiveHint=true, but the description goes further by specifying the exact nature of destruction: 'deletes the membership record outright with no undo,' and clarifies the matching behavior ('matching the first record found'). It also discloses the return format ({message, email}) and the full set of failure conditions, including permission and scope requirements. This adds substantial context 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 sentences carry a high density of information with no filler. The purpose is front-loaded in the first clause, followed by the destructive nature and return format, then error conditions and owner restriction. Every sentence earns its place, and the structure is logical 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?

For a tool with two parameters, no output schema, and annotations already marking destructiveness, the description covers everything an agent needs: the exact operation, the two accepted identifiers, the matching rule, the return shape, the irreversibility, the error triggers, and the permission requirement. It even provides the recovery path via invite_member. There is no missing information that would impair correct 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% and each parameter already has a clear description, so the baseline is 3. The description adds value by explicitly stating that the two parameters are alternatives ('by memberId or email') and that the removal targets the first matching record, which clarifies the semantics of both parameters beyond their individual schema entries. This extra nuance justifies a score above baseline.

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 ('Remove') and resource ('member') with precise scope ('from this project'), and distinguishes itself from siblings like invite_member and list_members by focusing on removal. It clearly identifies the two alternative identifiers (memberId or email) and notes it matches the first record, so an agent can differentiate it without opening other tool definitions.

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

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

The description gives explicit error conditions that double as preconditions: it fails if neither identifier is provided, no match, caller isn't owner, or token lacks config scope, and it explicitly states 'Owner only.' It also hints at the alternative by noting that getting the person back requires a fresh invite_member call, which tells the agent when to choose that tool instead. However, it does not explicitly contrast with set_member_role or other membership tools, so it stops short of full 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 destructive and not read-only. The description adds valuable context: it clarifies that only the display name is affected, the slug remains unchanged, and an ownership check yields a 404-equivalent error. This adds behavioral nuance beyond the annotations without contradiction.

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

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

Three focused sentences, each earning its place: the core action and scope, the auth requirement, and an error condition. No filler or redundant 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?

For a simple two-parameter tool with no output schema, the description covers all essential aspects: what it does, what doesn't change, required credentials, and an error scenario. Nothing critical is missing for an agent to call 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?

Schema coverage is 100% with clear descriptions for both parameters. The description enriches this by explaining that the slug is the identifier that never changes and that the name is the display name, reinforcing the tool's purpose beyond the raw parameter definitions.

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 verb (rename), resource (project), and the precise scope: only the display name changes while the slug stays the same. This distinguishes it from sibling operations like create_project or archive_project 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?

It gives clear context on when to use the tool (to change a project's display name) and explicitly states the prerequisites: an ACCOUNT-scoped management token with the config scope. It doesn't explicitly exclude alternative tools, but no sibling performs this exact action, so the guidance 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 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?

Annotations only provide readOnlyHint=false and destructiveHint=false, leaving the description to carry behavioral detail. It discloses billing behavior (charges original credit cost), failure mode for insufficient balance (entry stays in DLQ, returns error), and error condition when entry is missing (already retried or discarded). It also states the access requirement. This goes well beyond the annotations and gives an agent full expectation of 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 three sentences, each dense with information: the core action, the billing/error semantics, and the success/error conditions. It is front-loaded with the main purpose and every sentence adds value. 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 single-parameter tool with no output schema, the description covers the action, the billing side effect, both failure modes (insufficient credits and missing entry), and the required permission. An agent has everything needed to decide and call correctly, including how to recover from failure (top up and retry).

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 id parameter as 'Dead-letter entry id from list_dlq' with 100% coverage. The description does not add new semantic detail about the parameter itself, only about tool behavior under certain id states. Per the rubric, with high schema coverage the baseline is 3, and the description does not elevate it further.

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

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

The description opens with a precise verb+resource statement: 'Re-enqueue a DLQ entry to the main relay stream and delete it from the DLQ.' This clearly distinguishes it from the sibling discard_dlq_entry (which discards without re-enqueueing) and get_dlq_entry (which only reads). The action is 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 implies when to use it (retrying a DLQ entry) and states a prerequisite ('Requires edit access'). It also notes failure conditions (insufficient credits, entry already gone). However, it does not explicitly name the alternative discard_dlq_entry or say 'use this when you want to retry, discard when you want permanent removal.' The guidance is clear but not explicit about 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?

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?

Beyond the destructiveHint annotation, the description reveals key behavioral traits: immediate effect with no overlap window, callers start failing, successor revocations block predecessor rotation, and permission scoping. This adds substantial 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.