PassFast

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

The description adds meaningful behavior beyond annotations, especially that the `raw_key` is shown only once and cannot be retrieved again. It also discloses the required scope, rate-limit context, and that the tool maps to a specific HTTP endpoint, which helps the agent anticipate side effects and constraints.

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

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

The description is reasonably concise and front-loads the core purpose and critical one-time-key warning. Minor redundancy exists between the title 'Create an API key' and the first sentence, but the additional endpoint and scope details earn their place.

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

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

With no output schema, the description compensates by listing the response fields and explaining the unrecoverable raw key. It also covers scope, endpoint mapping, and operational constraints, so an agent has enough context to invoke the tool correctly without inventing details.

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 input schema already fully documents both `name` and `key_type`, including the enum values. The description adds no additional parameter-level meaning, matching the baseline expectation when the schema carries the full burden.

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

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

The description clearly states the specific action ('Creates a new API key') and resource, distinguishing it from sibling create tools like createApp and createTemplate. It also anchors the tool to a concrete OpenAPI operationId and endpoint, leaving no ambiguity about what it does.

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

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

The usage context is implied by the action itself and reinforced by the scope (`org:manage`) and endpoint mapping. However, it does not explicitly explain when to choose this over related alternatives like listApiKeys, revokeApiKey, or deleteApiKey, and there are no exclusions or sibling comparisons.

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 the required scope (org:manage), the exact HTTP mapping (POST /manage-org/app), and that the same PassFast billing and rate limits apply. It does not contradict the readOnly, destructive, or idempotent hints, and it credibly explains the operation's access and API characteristics.

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 well-structured with bold labels and a clear endpoint mapping. The opening line 'Create a new app' is somewhat redundant with the following sentence, but the rest of the content is focused and front-loaded with essential scope and path information.

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

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

For a simple one-parameter creation tool with no required parameters, the description covers the essential scope, path, and API constraints. It does not describe the response shape or error behavior, but the absence of an output schema and the low complexity make the provided context reasonably complete 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 description coverage is 100%, and the single 'name' parameter is already documented as 'App display name' with a default. The tool description does not add any additional parameter semantics, so the baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Create' and the resource 'a new app within the organization,' so an agent can tell this is for creating an app resource. It is specific and accurate, but it does not explicitly distinguish itself from sibling create* tools, so it stops short of the highest clarity score.

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 useful operational context: the org scope, the OpenAPI operationId, and the POST path. It implies that this tool is used when creating an app, but it does not explicitly state when to prefer this over alternatives or when not to use it, so the usage guidance is more implied than explicit.

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

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

Annotations already declare idempotentHint and non-read-only behavior, and the description adds meaningful detail beyond them: 200 vs 201 status codes, automatic application to sibling passes, the required scope, and the OpenAPI endpoint mapping. 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 front-loaded with the core purpose and every section adds value: idempotency, dual-wallet behavior, scope, endpoint mapping, and rate-limit context. There is minor redundancy with the opening phrase repeating the tool name, but nothing is 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?

The description covers use case, idempotency, dual-wallet behavior, scope, endpoint, and operational constraints. With no output schema, it does not specify the exact response payload shape, but it clearly states that a token is returned and that the share URL points to a public wallet-add page, which is sufficient 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?

Schema description coverage is 100%, so the schema fully documents pass_id and x_app_id. The description adds context about pass behavior (dual-wallet sibling passes) but does not elaborate on x_app_id override semantics; the schema already carries that weight.

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: 'Creates a public share token for a pass,' and explains the purpose (distribution via URL, QR code, or messaging). It clearly distinguishes itself from sibling read/metadata tools like getSharePassMetadata and downloadSharedPass by being the creation operation.

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

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

The description gives clear context for when to use the tool: when a pass needs a public share token for wallet distribution. It also covers relevant edge behavior such as idempotency and dual-wallet propagation, though it does not explicitly name when-not-to-use or alternative tools.

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 a non-read-only, non-idempotent mutation. The description adds useful context beyond annotations: required scope `templates:manage`, the exact POST /manage-templates mapping, and that the same HTTP API billing and rate limits apply. The draft-status disclosure also sets expectations about the created object's 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?

The description is short and front-loads the core purpose, with the first line immediately stating what the tool creates. It is slightly redundant ('Create a template' then 'Creates a new pass template') and the 'Do not invent other paths' sentence is defensive, but overall every major fact fits in a few lines.

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 15-parameter tool with a massive nested structure and no output schema, the description gives the endpoint, scope, draft status, and billing context, which is useful but incomplete. It does not clarify the returned template representation, post-create workflow (e.g., publishing), or how the dual-wallet structure is intended to be populated beyond what the schema already says.

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

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

With 47% schema description coverage (below 50%) the description should compensate for undocumented parameters, but it contains no parameter guidance at all. The heavy lifting is left to the input schema properties, and the description does not even mention required inputs like pass_style or structure.

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

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

The description states a specific verb and resource: 'Creates a new pass template in draft status.' This distinguishes createTemplate from sibling create* tools (createApiKey, createApp) and from updateTemplate/publishTemplate by clarifying the lifecycle stage (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?

There is no explicit when/when-not guidance or named alternative; use is implied by 'Creates a new pass template'. The draft-status mention signals it is not for publishing, but the description does not say to use updateTemplate for edits or publishTemplate to take it live.

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 destructive and non-idempotent. The description adds valuable context beyond annotations: the exact DELETE path, the required certs:manage scope, and that the same PassFast HTTP API/billing/rate limits apply. The instruction 'Do not invent other paths' is especially useful for an open-world 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 concise and well organized, with a one-line summary followed by scope, endpoint, and operational constraints. The first line 'Deactivate Google credential' is slightly redundant with the next sentence, but the overall structure is efficient and readable.

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 provides the essential invocation context: method, path, required scope, and API constraints. It does not explain side effects or prerequisites beyond deactivation, but annotations cover destructiveness and the schema covers parameters, so the description is sufficiently 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?

Schema coverage is 100%, so the baseline is 3. The description adds extra semantic value by showing that the id appears as a path parameter in DELETE /manage-certs/google/{id}, which the schema alone does not explicitly state. The x_app_id parameter is already well described in the schema as a header override.

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: 'Deactivates a Google Wallet credential.' It also maps the operation to an exact OpenAPI endpoint, which removes ambiguity. However, it does not explicitly contrast itself with siblings such as deleteCertificate or uploadGoogleCredentials, so it falls short of full sibling differentiation.

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

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

The description does not explain when to choose this tool over alternatives or mention exclusions. It implies usage through the verb 'deactivates,' but provides no practical selection guidance or relationship to related tools like listGoogleCredentials, uploadGoogleCredentials, or deleteCertificate.

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

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

Annotations already mark destructiveHint=true, and the description adds meaningful behavioral detail: permanent deletion, the revoke-first prerequisite, the 400 error for active keys, the org:manage scope, and the exact endpoint. 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?

The description is front-loaded with the core action, then compactly covers preconditions, scope, endpoint mapping, and guardrails. Each sentence earns its place, and bold/paragraph structure makes it scannable 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?

For a one-parameter destructive action with annotations already present, this is complete: the agent knows the effect, the prerequisite, the failure mode, the required scope, and the exact HTTP path. No output schema is necessary for a simple delete 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 schema fully documents id as a UUID API key ID, and the description adds extra meaning by explaining the id must reference a revoked key and that it appears as {id} in the DELETE path. This goes beyond the schema's bare field description.

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 ('Delete an API key' / 'Permanently deletes an API key') and distinguishes itself from revokeApiKey by requiring the key to be revoked first. The explicit DELETE /manage-keys/{id} mapping removes any ambiguity about which operation this is.

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: only a revoked key can be deleted, and attempting to delete an active key returns 400. This implies the revoke-then-delete workflow, though it does not explicitly name the sibling revokeApiKey as the alternative or state when not to use the tool.

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

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

Annotations already signal destructiveHint=true, but the description adds valuable context: the operation only deactivates and does not permanently delete data, requires org:manage scope, and maps to a specific HTTP endpoint. This goes beyond what annotations alone communicate.

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 with the core action. The operationId and endpoint mapping add useful grounding, though 'Do not invent other paths' is slightly redundant after the explicit path is already provided.

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 tool with strong annotations and full schema coverage, the description is sufficiently complete: it explains the action, scope, non-permanence, and API mapping. There is no output schema, but the tool is simple enough that this is not a major gap.

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

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

Schema coverage is 100%, and the single optional parameter x_app_id has a clear description in the schema. The tool description adds no extra parameter 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?

The description opens with a specific verb and resource: 'Deactivate an app' and clarifies it acts on 'the current app.' It also distinguishes itself by noting this is not permanent deletion, which clearly separates it from other delete-family tools.

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

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

It states the app scope ('the current app') and provides API context, but it never explicitly names sibling alternatives or conditions for when to choose this over deleteTemplate, deleteApiKey, etc. Usage context is implied rather than stated.

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 carry destructiveHint=true and readOnlyHint=false, and the description reinforces deletion. It also discloses the required certs:manage scope and warns that billing/rate limits apply, which goes beyond the annotations. It does not elaborate on irreversibility or cascading effects, but that burden is largely covered by 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 opening sentence repeats the title almost verbatim ('Delete a certificate' / 'Deletes a certificate.'), which wastes a sentence. The remaining bullets are compact and relevant, but the redundancy keeps it from being a top-tier concise 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 low-complexity delete operation, the description supplies the endpoint, required scope, and API behavior, while the schema explains the parameters and annotations cover destructiveness. A minor gap is lack of any mention of the response or prerequisites, but this is not critical here.

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 adds that id is placed in the /manage-certs/{id} path, but it does not explain the x_app_id override behavior; the schema already covers both parameters adequately.

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

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

The description states a specific action and resource ('Delete a certificate') and pins it to a concrete OpenAPI operation and path (DELETE /manage-certs/{id}). Among sibling delete tools, the resource name cleanly separates this from deleteApiKey, deleteApp, deleteTemplate, etc.

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 intended use is implied: use it when a certificate must be removed, and the API mapping and scope indicate this is the real hosted endpoint. However, it never explicitly states when not to use it or compares it with related certificate tools such as listCertificates, uploadCertificate, or testAppleCertificates.

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 side effects on dependent data (template columns and pass overrides are silently cleared/nullified), notes that deletion always succeeds when the image exists, and specifies the exact HTTP mapping and scope. This adds significant 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 well-structured, starting with the core action, then side effects, usage guidance, scope, and API mapping. Every sentence adds value; no filler or redundancy. It is concise yet comprehensive.

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

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

The description covers deletion behavior, side effects, prerequisites, scope, and API mapping. For a delete operation with no output schema, this provides all necessary information 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 description coverage is 100% for both parameters (id and x_app_id), so the schema already documents them fully. The description does not add parameter-specific semantics beyond the schema, 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 ('Deletes an image') and the exact scope ('storage file + DB row'), distinguishing it from sibling delete tools for other resources (deleteApp, deleteTemplate, etc.). The purpose is unambiguous.

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

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

It explicitly instructs to use GET /manage-images/{id}/usage first to understand blast radius, providing a clear prerequisite. It doesn't explicitly contrast with other delete tools, but the resource distinction is inherent and the guidance is actionable.

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 substantially enriches this by explaining the soft-delete mechanism, the irreversible nature of permanent deletion, and that it removes associated data. It also adds scope, OpenAPI mapping, and shared billing/rate limits. 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?

Five sentences, front-loaded with the core operation and soft-delete behavior, followed by scope, API mapping, and a caution not to invent paths. Each sentence carries distinct information with no meaningful filler. The 'Same PassFast HTTP API, billing, and rate limits' line is slightly generic but still useful context.

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 deletion modes, side effects, required scope, and API mapping. It does not describe return values or error behavior, but with no output schema and destructive annotations already present, this is a minor gap for a three-parameter delete endpoint. Overall adequate for safe 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 all three parameters have descriptions. The description adds the behavioral nuance of 'marking it as archived' and the `permanent=true` toggle, but this largely mirrors the schema's parameter descriptions. It does not add meaning for `id` or `x_app_id` beyond what the schema already explains.

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 ('Delete') and resource ('template') and explains the two modes: soft-delete by default and permanent delete with `permanent=true`. This clearly distinguishes it from sibling delete tools for other resources (deleteApiKey, deleteApp, deleteCertificate) and from template management tools like updateTemplate.

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 conditional usage: default soft-delete, use `permanent=true` for permanent deletion. It also specifies the required permission scope and the exact OpenAPI path, which helps route correctly. It does not explicitly name alternatives or when-not-to-use, but the resource-specific name and behavior make the target use obvious.

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 the safety profile (read-only, idempotent, non-destructive). The description adds useful behavioral context beyond that: exact GET endpoint, required scope `passes:download`, the expectation of active-pass state, billing/rate-limit equivalence, and an explicit warning not to invent other paths.

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 with the primary purpose. Minor redundancy exists between 'Download a .pkpass file' and 'Downloads the .pkpass binary...', but overall the content is focused and free of filler.

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

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

For a simple download operation with only two well-documented parameters, the description is largely complete: it states the return artifact, the active-pass constraint, the required scope, and the exact endpoint. It does not cover error cases or behavior when the pass is inactive, but those are not critical for calling the tool successfully.

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 for both parameters, so the schema already explains `id` and `x_app_id`. The description adds only a minor semantic cue that the pass must be active, but does not materially expand parameter meaning beyond the schema.

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

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

The description clearly states a specific action and resource: downloading the `.pkpass` binary for an active pass. It includes the exact operationId and endpoint, but it does not explicitly contrast itself with sibling tools like downloadPassBySerial or downloadSharedPass.

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 the tool: when downloading an active pass's `.pkpass` file by ID. It does not explicitly state when not to use it or name alternative sibling tools, though the scope and endpoint mapping provide some operational 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 already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral details: it operates on an 'active pass', explains wallet_type selection for Apple/Google, and clarifies that it shares the same HTTP API, billing, and rate limits as the underlying PassFast API. This supplements the annotations meaningfully.

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: the first line states the core purpose, followed by a brief qualifier on wallet selection, then scope, API mapping, and a caution. Each sentence adds value with no redundant filler.

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

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

For a download tool with no output schema, the description sufficiently covers the purpose, wallet_type disambiguation, scope, and API context. It omits explicit error handling or authentication details, but the annotations and simple parameter set make those gaps minor. The added billing/rate-limit note improves completeness.

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

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

Schema description coverage is 100%, and the schema already documents all parameters, including wallet_type's role and default. The description repeats the wallet_type behavior without adding new meaning; it does not further elaborate on formats or constraints beyond what the schema provides. Baseline 3 is appropriate when the schema carries the parameter semantics.

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

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

The description states a specific verb (Download) and a specific resource (`.pkpass` by serial number), and distinguishes from siblings like downloadPass or downloadSharedPass by keying on serial number. It also maps to a specific OpenAPI operation, leaving no ambiguity about intent.

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 for the wallet_type parameter and its default, but it does not explicitly instruct when to use this tool instead of alternatives such as downloadPass or downloadSharedPass. The usage is implied by the serial-number-based purpose, but no exclusions or alternative routing are provided.

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

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

Annotations already mark it read-only, idempotent, and non-destructive; the description adds the exact endpoint mapping (GET /share-pass/{token}/download), the public/no-auth behavior, the active-pass prerequisite, and a warning not to invent other paths. This is substantive behavioral context beyond the hints.

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

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

The description is compact and front-loaded, but it has minor redundancy: the opening line repeats the first sentence, and 'no authentication required' appears twice. This is a small efficiency issue rather than a structural problem.

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 public download with no output schema, the description covers the endpoint, auth profile, prerequisite, and rate-limit context. It does not spell out failure modes for expired or inactive tokens, but that is a minor gap given the tool's simplicity.

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

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

The schema already fully documents the single required token parameter, including its format as 32 hex characters. The description only repeats token in the path template and adds no new semantic meaning, so the 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?

Opens with a specific verb and resource ('Download shared Apple .pkpass') and the body confirms it downloads the .pkpass file for a shared pass. It also signals the distinguishing dimension—public, no-auth endpoint—so an agent can separate it from sibling download 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?

Provides clear context: use for shared passes with a share token, only when the pass is active, and without authentication or an API key. It does not explicitly name sibling alternatives or state when not to use it, so it stops short of full alternative routing.

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, it discloses response type changes by wallet_type, partial-success behavior, X-Pass-Id header, webhook call ordering, and fail-closed 403/502 behavior. This is substantial 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 well organized and front-loaded, covering core behavior before edge cases and scoping. It is slightly repetitive at the start and includes some operational details like billing and rate limits that could be trimmed, but each part adds useful context.

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 12 parameters and no output schema, the description explains all important return shapes (pkpass, save_url, combined JSON), headers, status codes, webhook behavior, and scoping. An agent has enough information to call the tool and interpret the response correctly.

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

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

Schema coverage is 100%, so parameters are already documented in the input schema. The prose description reinforces wallet_type behaviors and get_or_create status outcomes, but mostly describes response behavior rather than adding new parameter-level meaning.

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 'Generate a wallet pass' and immediately specifies 'Generates a wallet pass from a published template,' giving a specific verb, resource, and source. It also distinguishes the operation from siblings like downloadPass and updatePass by framing generation as producing a signed pkpass or wallet save URL.

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 explains the context: generating a pass from a published template, with wallet_type variants and scope. It lacks an explicit 'when not to use' section naming alternatives, but the context and 'Do not invent other paths' guidance effectively route the agent.

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

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

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds operational context beyond annotations by specifying the required org:read scope, the exact OpenAPI route, and that PassFast HTTP API billing and rate limits apply, plus a warning not to invent paths. 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 compact and front-loaded with the purpose, then scope and route details. Minor redundancy exists between 'Get current app details' and 'Returns the current app's settings,' but every other sentence adds useful operational context.

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 tool with one optional parameter and no output schema, the description gives enough to invoke correctly: purpose, scope, route, and parameter behavior are covered by the schema. It could describe return fields in more detail, but 'current app's settings' plus the operation mapping is sufficient for a basic getter.

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 single optional parameter x_app_id is already documented as overriding X-App-Id and defaulting to the MCP connection header. The description adds no additional parameter detail, 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 ('Get current app details') and reinforces it by saying it returns the current app's settings. It further disambiguates by mapping to GET /manage-org/app and naming the operationId getApp, which separates it from sibling getters like getOrganization or getTemplate.

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: this tool reads the current app's settings and requires org:read scope. It does not explicitly enumerate alternatives or exclusions, but the operation mapping and resource scoping make the intended use obvious. A 4 is appropriate because context is clear though no when-not 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 annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description goes further by explaining the meaning of `template_refs`, `pass_refs_count`, and `safe_to_delete`, plus the `images:manage` scope, the OpenAPI path mapping, and the same HTTP API/rate-limit behavior. This adds substantial context beyond structured fields.

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: a one-line summary, a purpose statement, a bulleted list of output fields, and concise operational notes. Every sentence adds value, including the guardrail about not inventing other paths.

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 present, the description compensates by explaining the return fields and their semantics. It also covers the required scope, API mapping, and operational constraints, making the tool fully invocable without needing external 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?

Schema description coverage is 100%, with clear descriptions for `id` and `x_app_id`. The description does not add significant parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Get image usage / reference counts' and explains that it reports how an image is referenced across templates and passes. This clearly distinguishes it from sibling tools like listImages, uploadImage, and deleteImage by focusing on reference counts rather than listing, uploading, or deleting.

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 identifies when to use the tool: 'Useful before DELETE to confirm an image is unused, or to find which templates a shared asset is attached to.' It does not explicitly name alternatives or exclusion cases, but the use cases are clear enough to guide an agent.

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

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

Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds useful context beyond those annotations by stating the org:read scope, mapping to the exact GET endpoint, and returning readiness flags that influence signing modes. This is transparent and consistent with 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 compact and well-structured: the purpose is stated first, followed by behavioral implications, scope, and endpoint mapping. Every sentence adds meaningful information, and there is no redundant or filler content.

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

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

For a zero-parameter read-only status check, the description is complete. It explains the return semantics, the conditions that affect downstream usage, the required scope, and the exact API mapping. Even without an output schema, an agent knows what to expect from the tool.

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

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

The tool accepts no parameters, and schema description coverage is 100%, so the schema leaves nothing ambiguous. The description still adds value by explaining what the response fields mean, even though it does not need to document 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 clearly states the tool checks managed signing availability for Apple and Google wallets and explains the meaning of the returned fields. It does not explicitly differentiate itself from sibling tools like testAppleCertificates or testGoogleConnection, but the resource and behavior are specific enough to avoid confusion.

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 a clear use case: checking whether managed signing credentials are available so apps can use signing_mode: 'managed'. It does not explicitly mention alternatives or exclusions, so it falls short of a 5, but the context is sufficient for an agent to select this tool.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful context beyond annotations: the exact API path, org:read scope, rate-limit/billing alignment, and a warning not to invent other paths.

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 short, front-loaded with the purpose, and every sentence contributes information: resource, scope, OpenAPI mapping, and API constraints. 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 zero-parameter read-only operation, it covers the endpoint, scope, and rate-limit constraints, which is sufficient for selection and invocation. It does not enumerate the specific settings fields returned, but those are not required to call 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 takes zero parameters and schema coverage is 100%, so there is no parameter information for the description to add. Per baseline for zero-parameter tools, this is appropriately handled.

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 'Get organization details' and clarifies it 'Returns the current organization's settings,' giving a specific verb, resource, and scope. It also maps to GET /manage-org, which distinguishes it from sibling getters like getApp and getPass.

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 intended use is implied by the resource name and description, but there is no explicit when-to-use or when-not-to-use guidance versus alternatives. The 'Do not invent other paths' caution is a constraint, not a routing decision.

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, idempotentHint, and non-destructive behavior. The description adds value by disclosing the required OAuth scope (passes:read), the exact HTTP mapping, and billing/rate-limit consistency, which are useful behavioral/operational traits 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 brief and front-loaded with the core purpose, followed by scope/endpoint details and a guardrail against inventing paths. There is slight redundancy between 'Get a pass' and 'Returns the full details of a single pass,' but overall it is efficient and well-structured.

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

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

For a simple get-by-ID tool with strong annotations and fully documented schema, the description covers the core purpose, endpoint mapping, scope, and rate-limit consistency. It does not explain error cases or how to choose between getPass and getPassBySerial, but the context is largely sufficient 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?

Schema description coverage is 100%, so both parameters (id and x_app_id) are already fully documented in the schema. The description does not add any parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Returns the full details of a single pass' and maps to GET /manage-passes/{id}. This clearly identifies the operation and, through the {id} path, implies it differs from the sibling getPassBySerial, though it does not name any sibling explicitly.

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?

There is no guidance on when to use getPass versus alternatives like listPasses or getPassBySerial. The description provides constraints ('Same PassFast HTTP API, billing, and rate limits. Do not invent other paths.') but does not explain the selection criteria among sibling tools.

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 the safety profile (readOnly, idempotent, non-destructive). The description adds useful context: the required OAuth scope (`passes:read`), the exact GET mapping, and the operational caveat about shared PassFast API billing and rate limits. 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?

Four short, purpose-driven paragraphs with the headline action first and supporting detail in order of importance. No filler or repetition of obvious schema facts; each line adds behavioral or routing context.

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 three-parameter read-only lookup, the description gives the endpoint, scope, wallet selection logic, and API constraints; the input schema already documents all parameters. It slightly undersells the return shape ('full details' without a schema/field list), but that is not necessary 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?

Schema coverage is 100%, so baseline is 3, but the description adds value by indicating that serial_number is a path parameter (via GET /manage-passes/serial/{serial_number}) and that wallet_type is a query parameter with a default behavior. The wallet_type disambiguation sentence reinforces the enum's purpose beyond the schema text.

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 clear verb and resource: 'Get a pass by serial number' and 'Returns the full details of a single pass'. The OpenAPI operation and GET path make the lookup-by-serial scope explicit, separating it from siblings like listPasses or downloadPassBySerial. Could have named an alternative, but the resource and path are 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?

Provides clear context for the wallet_type parameter ('when a serial has both Apple and Google passes') and states scope, billing/rate limits, and the exact endpoint. It does not explicitly compare this tool with alternatives such as getPass or downloadPassBySerial, so when-to-use-this-vs-that is implied rather than stated.

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?

Adds meaningful behavior beyond the annotations: explicitly public, no authentication, maps to GET /share-pass/{token}, and shares the same API, billing, and rate limits. The warning not to invent other paths is an extra guardrail. No contradiction with readOnly/idempotent hints.

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

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

Front-loaded with the core purpose, then adds auth context, endpoint mapping, and a rate-limit note. Slightly redundant with the tool name and operationId, but every sentence contributes useful information and the length is appropriate.

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, one-parameter public metadata lookup, the description covers purpose, authentication, endpoint, and constraints. Nothing needed to invoke 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?

The only parameter, token, is fully described in the schema as 'Share token (32 hex characters),' giving 100% coverage. The description does not add further parameter-level details, so the baseline of 3 applies.

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

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

Clearly states the action ('Get shared pass metadata') and the resource (a shared pass), and specifies it returns public metadata with no authentication. The public-share-page use case and endpoint mapping further distinguish it from authenticated pass tools like getPass or downloadSharedPass.

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: used by the public share page, no API key required, and maps to a specific public endpoint. It does not explicitly list sibling alternatives or exclusion conditions, but the intended use is easy to infer.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context beyond annotations: it requires the templates:manage scope, maps to a specific HTTP GET endpoint, and states that the same PassFast HTTP API, billing, and rate limits apply. It also explicitly warns not to invent other paths, which is a behavioral guardrail. It doesn't describe pagination or error behavior, but for a single-resource GET with strong annotations, this is solid.

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: the first line states the core action, then the return value, then scope, then mapping, then constraints. Every sentence earns its place, and there is no redundant filler. It is appropriately sized for a simple GET tool.

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

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

For a single-resource GET with no output schema, the description covers the essential context: what it returns, the required scope, the exact HTTP mapping, and the constraint not to invent other paths. It doesn't describe the response shape, but the absence of an output schema and the simplicity of the operation make that a minor gap. The annotations cover safety, and the schema covers parameters, so the description is complete enough for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents both parameters ('Template ID' and 'Override X-App-Id for this call. Defaults to the MCP connection header.'). The description adds no additional parameter-level meaning beyond what the schema provides. Per the calibration baseline, when schema coverage is high, a 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'), a specific resource ('a single template'), and explicitly says it returns full details. It also names the OpenAPI operationId and HTTP path, which disambiguates it from sibling tools like listTemplates or updateTemplate. This is a clear, specific statement of what the tool does.

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

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

The description provides clear context: it maps to GET /manage-templates/{id}, requires the templates:manage scope, and notes that it shares the same API, billing, and rate limits. It doesn't explicitly say 'use this instead of listTemplates when you need a single template's full details,' but the scope and path make the usage context clear. It also warns against inventing other paths, which is a useful usage constraint.

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 define readOnlyHint, idempotentHint, and destructiveHint, so the description need not repeat them. It adds value by specifying the required organization scope and warning against inventing paths. This goes beyond annotation coverage and gives 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, with a clear lead sentence, a bullet for scope, and a brief note on API mapping and constraints. Every line earns its place without fluff.

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

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

For a zero-parameter, read-only list operation, the description includes necessary operational context: scope, endpoint mapping (GET /manage-keys), and cautions about rate limits and path invention. Nothing essential 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?

The tool has zero parameters, and per rubric the baseline is 4. The description correctly avoids speculative parameter details. No additional 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 clearly states the action (List) and resource (API keys) with explicit scope ('current organization'). It is distinct from sibling tools like createApiKey, deleteApiKey, and revokeApiKey, making it 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 defines when to use the tool (to list all API keys for the organization) and adds a required permission scope (`org:manage`). It doesn't explicitly contrast with sibling list operations like listCertificates or listImages, but the resource type is obvious. The technical mapping and rate-limit note provide additional 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 already cover read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond those annotations: the required scope `certs:manage`, the exact HTTP mapping to GET /manage-certs, and a warning about billing/rate limits and not inventing other paths. 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 compact and front-loaded with the core purpose, followed by scope and API mapping. The final sentence about 'Same PassFast HTTP API, billing, and rate limits' is somewhat vague about what 'same' refers to, preventing a perfect score, but overall every sentence earns its place.

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

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

For a simple read-only list operation with a single well-documented parameter and strong annotations, the description is sufficiently complete. It provides the required scope, HTTP mapping, and rate-limit caution, and no output schema is needed to call the tool correctly. Minor gap: no mention of response shape or pagination, but that is not critical for this tool.

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

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

The only parameter, x_app_id, is fully described in the schema with its override/default behavior. Schema description coverage is 100%, so the description does not need to add parameter-level detail; 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 opens with a specific verb and resource ('List certificates') and clarifies it returns all certificates for the current app. This clearly distinguishes it from sibling certificate tools like deleteCertificate, uploadCertificate, and uploadP12Certificate.

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 an agent needs the full set of certificates for the current app, but it does not explicitly state when to choose this tool versus alternatives, nor does it mention exclusions or direct the agent to a sibling tool. 'Returns all certificates for the current app' provides context but no explicit routing.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond annotations: it returns only active credentials, is scoped to the current app, maps to a GET operation, and carries the same API/billing/rate limits.

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

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

The description is compact and front-loaded with the essential return semantics. The endpoint mapping, scope, and API-context notes all add value, though the opening title line and first sentence are slightly 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 simple read-only list operation with one optional parameter and no output schema, the description covers what the tool returns, the scope, and the underlying endpoint. It does not specify the exact response format, but for this level of complexity the description is largely 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 single parameter x_app_id is fully described in the schema with its override behavior and default to the MCP connection header. The description adds no additional parameter meaning, so the baseline of 3 applies because 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 clearly states a specific verb and resource: 'List Google credentials' and 'Returns all active Google Wallet credentials for the current app.' It also pinpoints the exact endpoint, GET /manage-certs/google, which distinguishes it from upload/deactivate credential 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?

It gives clear context for when to use the tool: retrieving all active Google Wallet credentials for the current app, and notes the certs:manage scope. It does not explicitly contrast with alternatives like uploadGoogleCredentials or deactivateGoogleCredential, but the scope and resource are unambiguous enough.

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

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

Annotations already carry readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds value beyond that: the `images:manage` auth scope requirement, the GET /manage-images mapping, the note that billing and rate limits match the underlying HTTP API, and the signed-preview-URL return behavior. There is no contradiction with the read-only 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?

Five short, front-loaded segments: purpose, return behavior, auth scope, API mapping, and an anti-hallucination guardrail. Every sentence earns its place, and the closing instruction 'Do not invent other paths' is a high-value, low-cost addition that keeps agents from fabricating alternative endpoints.

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-optional-parameter read-only list tool with rich annotations and no output schema, the description is sufficient. It states the resource, scope, return value (signed preview URLs), auth requirement, and HTTP equivalence. An agent has everything needed to invoke it correctly; response-shape or pagination details are not critical for an 'all images for the current app' read 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?

Schema description coverage is 100%: the single optional x_app_id parameter is fully documented in the schema as an override for the X-App-Id header, defaulting to the MCP connection header. The description contributes no additional parameter guidance, so the baseline of 3 applies.

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

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

The description opens with the imperative 'List images' then specifies the resource (images), the scope ('for the current app'), and the return payload ('including signed preview URLs'). It also maps to GET /manage-images, and among the sibling tools the only image-related operations are uploadImage, deleteImage, and getImageUsage, so this listing tool is clearly distinguishable.

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 implied usage context: it is the way to fetch all images for the current app, and it warns 'Do not invent other paths' and to expect the same API, billing, and rate limits. However, it never names an alternative or an exclusion — for example, it does not mention getImageUsage for image consumption analytics — so tool-selection guidance among siblings is left to inference.

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, idempotent, non-destructive safety. The description adds useful context: pagination, scope, endpoint mapping, and billing/rate-limit equivalence. It does not detail the response shape or rate-limit behavior, 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 compact and front-loaded: the core action, pagination, scope, endpoint, and important constraints are each covered in a few sentences with 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 read-only list operation with 10 optional but fully schema-described parameters, the description provides the missing context: current-app scoping, exact endpoint, and scope. It does not describe the return payload, but that is a modest gap given the simple listing purpose and absence of an 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?

Schema coverage is 100%, with every parameter having its own description, so the description does not need to repeat parameter meanings. The 'paginated' mention aligns with limit/offset but adds no new 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?

The description states a clear verb and resource ('List passes') and specifies that it returns a paginated list for the current app. It does not explicitly differentiate itself from getPass or getPassBySerial, but its scope and endpoint mapping make the purpose unambiguous.

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

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

It provides context by saying it lists passes for the current app and maps to GET /manage-passes, so an agent can infer when to call it. However, it does not mention alternatives such as getPass or getPassBySerial or state when not to use this tool, so selection guidance is only 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 mark the call read-only and idempotent; the description adds the required templates:manage scope, the exact OpenAPI operationId and GET path, and a warning about PassFast HTTP API/billing/rate limits plus not inventing other paths. This is useful behavioral context 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 compact and front-loaded: the core behavior comes first, followed by scope and API mapping. The 'Do not invent other paths' line is slightly imperative but earns its place by preventing hallucinated endpoints.

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 operation with two optional parameters and no output schema, the description covers scope, filtering, authentication scope, endpoint mapping, and rate-limit behavior. It does not enumerate response fields, but the domain term 'templates' and the absence of nested objects make this acceptable.

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

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

Schema description coverage is 100%, so the schema already documents archived and x_app_id. The description adds default/archived behavior, but this largely mirrors the schema and provides no additional detail on x_app_id or format beyond what is already present.

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 templates') and immediately clarifies scope: it returns all templates for the current app, with a default non-archived filter and an archived toggle. This clearly distinguishes it from singular getTemplate and other 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 gives clear usage context: list all templates for the current app, with archived=true as the only filter variant. It does not explicitly say when to prefer getTemplate or other siblings, so it stops short of a full when/when-not statement.

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, idempotent, and non-destructive behavior. The description adds useful context beyond that: the `org:read` scope, the exact API path, the paginated response nature, and the note that the same PassFast HTTP API, billing, and rate limits apply. This gives the agent operational expectations without contradicting 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 compact and front-loaded, with the core action stated first and supporting details kept to a few high-value sentences. Every line adds useful information: resource scope, API mapping, auth scope, and path constraints. There is no filler.

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

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

For a read-only paginated list tool with fully self-describing parameters, the description covers what the tool does, what scope it requires, how it maps to the underlying API, and important constraints about not inventing other paths. No critical information needed to select or invoke this tool 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 input schema provides full descriptions for all five parameters, including defaults for limit and offset and enums for event_type and delivery_status. The description adds no parameter-specific semantics beyond saying the list is paginated, 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 the specific verb-resource pair 'List webhook events' and further clarifies that it returns 'a paginated list of webhook event delivery records for the current app.' It also maps to the exact OpenAPI operation and HTTP endpoint, making the tool's purpose unambiguous and distinct from siblings like testWebhook.

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 lists webhook event delivery records for the current app, is scoped to `org:read`, and maps to GET /manage-org/webhook-events. It does not explicitly discuss when to choose this over an alternative, but no close sibling exists, so this 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?

The description adds meaningful behavioral context beyond annotations: it discloses the state transition, the irreversible consequence that published templates cannot be modified, the required scope, and the shared billing/rate-limit behavior. 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 compact and front-loaded with the core purpose, followed by scope, endpoint mapping, and a guardrail against inventing paths. The opening line 'Publish a template' is somewhat redundant with the tool name, but nearly every other sentence earns its place.

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

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

For a simple action with one required parameter, the description provides the endpoint, scope, side effect, and a useful anti-hallucination note. It does not describe the response format or behavior when publishing an already-published or non-draft template, but those are minor given the annotations and 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 input schema already covers both parameters with 100% description coverage. The description adds that `id` appears in the URL path, which is mildly useful, but it does not otherwise elaborate parameter meaning beyond what the 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: it publishes a draft template and makes it available for pass generation. It also clearly distinguishes this state-transition tool from create/update/delete/get/list operations by naming the operationId and endpoint.

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

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

The description gives clear context that this is for publishing draft templates and notes that published templates cannot be modified, implying a boundary around when the action applies. It does not explicitly name alternatives or say when not to use it, but the draft-template framing is sufficient for typical routing.

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 a destructive, non-read-only operation; the description adds meaningful behavioral context: revoked keys become inactive, cannot authenticate, require scope org:manage, map to PATCH /manage-keys/{id}, and must not be called via invented paths.

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 content is useful and front-loaded, but 'Revoke an API key' is immediately restated by 'Revokes an API key'. The endpoint and scope details earn their place, though the redundancy weakens the structure.

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

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

For a simple one-parameter destructive operation, the description covers the effect, scope, API mapping, and a guard against hallucinated paths. It is nearly complete, though it does not mention the expected response or whether revocation is reversible.

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

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

The schema fully documents the single required id parameter as a UUID API key ID, so the description does not need to repeat it. The description adds no extra parameter-level meaning, but 100% schema coverage makes this acceptable.

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 and resource: revoke an API key, making it inactive and unable to authenticate. This clearly distinguishes the operation from deletion or creation, and the state transition is explicit.

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?

There is no guidance on when to revoke versus delete or manage an API key, and no prerequisites or exclusions are provided. The intended usage is only implied by the tool name and the first sentence.

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, the description discloses key behavioral traits: the test pass is ephemeral, not stored, and returned directly as a binary download. It also states the required scope (certs:manage) and explicitly maps to the underlying OpenAPI operation. No contradiction with the annotations is present.

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: purpose first, then behavioral detail, then operational constraints. Every sentence adds useful information, and there is 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 tool with one optional parameter and no output schema, the description is complete: it explains what the tool does, what the response is, that nothing is stored, the required scope, and the exact API mapping. Nothing essential is missing for an agent to select and invoke it correctly.

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

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

Schema description coverage is 100%, and the only parameter, x_app_id, is already well described in the schema. The tool description does not add parameter-level detail, but it does not need to because the schema carries the full semantic weight.

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 and resource ('Test Apple certificates') and then explains the concrete behavior: generating an ephemeral .pkpass file to verify uploaded Apple signing certificates. It clearly distinguishes this from siblings like testGoogleConnection and testWebhook by scoping it to Apple certificates.

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 frames when the tool is appropriate: to verify uploaded Apple signing certificates are valid and complete. It also provides operational guardrails like the API path, scope, and rate-limit context. It does not explicitly name alternative tools or state when not to use this tool, 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?

The annotations already flag the operation as not read-only and not idempotent. The description adds useful behavioral context: it hits the Google Wallet API, requires `certs:manage` scope, and is subject to the same HTTP API, billing, and rate limits. 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 compact and front-loaded with the core purpose, then adds scope, endpoint, and constraint details in a clearly structured way. The repeated title line and the slightly instructional 'Do not invent other paths' add minor redundancy, but overall it is 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?

For a simple test operation with one optional parameter and no output schema, the description provides purpose, endpoint, scope, and rate-limit expectations. It leaves return/error semantics implicit, but an agent has enough information 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 single optional parameter `x_app_id` is fully documented in the schema with its override/default behavior, so schema coverage is 100%. The description adds no additional parameter meaning, 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 states a specific action ('Tests... by attempting to authenticate') on a specific resource ('configured Google Wallet credentials'), and explicitly names the OpenAPI operationId and POST path. This clearly differentiates it from sibling tools like testAppleCertificates and testWebhook.

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 verify configured Google Wallet credentials against the Google Wallet API, and it adds the required scope `certs:manage` and exact endpoint mapping. It does not explicitly name alternatives or when-not conditions, but the context is clear enough for an agent to decide.

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, the description discloses the outbound side effect: it sends a sample payload to a configured URL and returns the result. It also adds operational traits such as scope, API mapping, and billing/rate-limit applicability. No contradiction with the annotations is present.

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: the purpose is stated first, followed by scope, API mapping, and a guard against inventing paths. Each sentence contributes either operational clarity or constraint information without unnecessary filler.

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

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

For a one-optional-parameter tool with annotations covering mutability and idempotency, the description is largely complete: it covers the action, scope, API path, and rate-limit context. The only minor gap is that 'returns the result' does not describe the result shape, but no output schema exists and the outcome is reasonably inferable.

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, `x_app_id`, is fully described in the schema as an optional override defaulting to the MCP connection header. The description adds no parameter-specific detail, so the baseline score of 3 is appropriate.

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

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

The description states a specific action ('Sends a sample validation webhook payload') and a clear resource ('the configured URL'), then names the OpenAPI operation and HTTP path. This makes the tool's function unambiguous and distinct from sibling test tools like testAppleCertificates and testGoogleConnection.

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 useful context: it is the validation-webhook test operation, requires `org:manage` scope, and shares PassFast HTTP API billing and rate limits. It does not explicitly list when to prefer this over alternatives such as listWebhookEvents, but the purpose is clear enough that the agent can infer the appropriate 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?

The description adds valuable context: org:manage scope, HTTP method/path, rate limits, and the one-time-only return of webhook_secret_raw. However, the regenerate_webhook_secret behavior directly contradicts the idempotentHint=true annotation, because repeated calls with regenerate_webhook_secret=true produce new secrets. Per the rubric, this is an annotation contradiction, which forces a score of 1 regardless of the other useful 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 and front-loaded: it states the core action, then highlights the non-obvious secret regeneration behavior, then provides scope and API mapping. Every sentence adds information; there is no padding 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 10-parameter mutation tool with no output schema, the description is quite complete: it covers the required scope, the HTTP mapping, the single critical response field, and warns against inventing paths. The main gap is the unresolved inconsistency with idempotentHint, which prevents a perfect score.

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

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

The input schema already provides 100% coverage with helpful descriptions for all 10 parameters, so the baseline is 3. The description adds meaningful operational meaning for regenerate_webhook_secret by explaining the new secret is returned in webhook_secret_raw and shown only once. It also groups webhook-related fields under 'webhook configuration,' aiding parameter understanding.

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 operation: update the current app's settings, including webhook configuration. It also provides the OpenAPI operationId and exact PATCH path, which makes the tool unambiguous and distinct from sibling update tools like updateOrganization, updatePass, and updateTemplate.

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 identifies the target resource as the current app and gives a concrete use case (regenerating a webhook secret). It also explicitly says to use the same PassFast HTTP API and instructs the agent not to invent other paths, which helps prevent hallucinated endpoints. It does not explicitly contrast with sibling update tools, but the resource scoping is strong enough for correct routing.

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 idempotent and non-destructive; the description adds behavioral context beyond them by giving the HTTP PATCH path, required `org:manage` scope, and noting the same billing and rate limits apply. 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 short, front-loads the core action, and adds only a few operationally relevant details. The 'do not invent other paths' line is slightly defensive but still earns its place against hallucinated endpoints.

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, optional-field PATCH with no output schema, the description covers scope, endpoint, and rate-limit expectations. It does not explain partial-update semantics when no fields are supplied, but that is a minor gap given the schema and annotations.

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 four parameters. The description only adds that APNs-specific parameters are included, which is useful but not necessary 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 states a specific verb and resource: 'Updates the current organization's settings, including APNs credentials.' The target is clearly the organization, not apps, passes, or templates, which distinguishes it from the many update* 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?

It gives clear context for when to use it: updating the current organization's settings, and it declares the required scope `org:manage`. It does not explicitly name sibling tools to avoid, but the org-scoped context is enough to route an agent correctly.

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?

Given annotations already mark the operation as mutating, non-destructive, and idempotent, the description adds meaningful behavioral detail: it optionally triggers push notifications to registered devices, requires an active pass, and warns about the same API/billing/rate limits. 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 compact and well-organized, front-loading the core behavior, then covering the required-field condition, scope, operation mapping, and operational guardrails. Each sentence adds actionable information 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?

For a nine-parameter tool with nested objects and no output schema, the combination of schema and description is largely sufficient to invoke it correctly: it covers path, scope, the at-least-one constraint, push behavior, and API limits. It stops short of explaining response shape or error cases, but those are not essential for selection and invocation.

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

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

All parameters already have descriptive schema text, so the baseline is 3. The description adds the critical cross-field constraint that at least one of data, expires_at, locations, relevant_date, or max_distance must be provided, and clarifies that id is the path parameter in the PATCH URL.

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 clear verb and resource: 'Update a pass' and 'Updates the dynamic data of an active pass,' and grounds it in a concrete operation path (PATCH /manage-passes/{id}). It does not explicitly contrast itself with siblings like updatePassBySerial or generatePass, so it stops short of full sibling differentiation.

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

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

The description provides useful call context, including that the pass must be active, that at least one update field is required, and the required scope (passes:manage). It never names an alternative tool or states when to prefer another variant, so the usage guidance is implied rather than explicit.

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

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

Annotations already cover read-only, destructive, and idempotence hints. The description adds valuable non-obvious behavior: optional push notification side effect, the active-pass-only restriction, dual-wallet selection behavior, the passes:manage scope, and the exact OpenAPI route and rate-limit expectations. No contradiction with annotations was found.

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 mostly front-loaded: the core operation appears first, followed by constraints, scope, and API mapping. There is minor redundancy between the title line 'Update a pass by serial number' and the first sentence, but overall every piece earns its place and nothing is bloated.

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 10 parameters, nested objects, no output schema, and notable behavioral nuances, the description covers the essential calling context: field requirements, active-pass restriction, wallet selection, push behavior, scope, and API endpoint mapping. A short note about the return shape or error behavior would make it fully complete, but nothing critical is missing for making the call.

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 important meaning beyond the schema: it states that at least one of data, expires_at, locations, relevant_date, or max_distance is required, which is not obvious from the schema's required list. It also clarifies wallet_type behavior for serials with both Apple and Google passes.

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 a specific verb and resource: updating the dynamic data of an active pass by serial number. It also mentions the optional push notification behavior. It does not explicitly differentiate from the sibling tool updatePass, so it misses the top score for sibling distinction, but the serial-number lookup is specific enough.

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

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

The description provides useful operational constraints: at least one update field is required, only active passes are updated, and wallet_type must be used for dual-wallet serials. However, it does not explicitly say when to choose this tool over alternatives like updatePass or when not to use it, so the guidance is implied rather than explicit.

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

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description adds valuable context: draft-only modification, required scope `templates:manage`, the exact PATCH path, and a warning not to invent other paths. It does not contradict the annotations and gives more operational detail than the structured fields 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 five short sentences, front-loaded with the core action and constraint, followed by scope, path, and API context. Every sentence earns its place; there is 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 and a complex 16-parameter nested input, the description should clarify return behavior, partial update semantics, and what 'updating a template' actually changes. It only covers draft-only status and API constraints, leaving critical usage details unspecified 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 description coverage is only 31%, and the description adds no parameter-level guidance. It does not explain partial versus full updates, which fields can be changed, how the `structure` object is merged, or the role of image IDs. The agent must rely entirely on the under-covered schema, making this a significant gap.

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 a specific action ('Update a template') and adds the key constraint 'Updates a draft template. Published templates cannot be modified.' This distinguishes it from siblings like createTemplate, deleteTemplate, and publishTemplate without needing to inspect 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?

The description explicitly says published templates cannot be modified, which tells the agent when NOT to use this tool. It also names the scope and API path. However, it does not mention alternatives such as createTemplate or publishTemplate by name, so it stops short of full routing 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 carry readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the write behavior is known. The description adds value beyond those: it discloses the required auth scope (certs:manage), the exact HTTP endpoint, billing/rate-limit context, and the guardrail 'Do not invent other paths.' 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 definition is compact — five short lines with the core purpose front-loaded. There is mild redundancy between the first sentence ('Upload a single certificate') and the second ('Uploads a single PEM-encoded certificate or key'), but the remaining lines (scope, endpoint, rate limits, path guardrail) each earn their place.

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

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

This is a low-complexity tool: 3 flat parameters, 100% schema coverage, no nested objects, no output schema. The description covers scope, endpoint, and rate-limit behavior, which is sufficient for invocation. Minor gaps: no statement about what a successful upload returns and no explicit differentiation from uploadP12Certificate, but neither blocks correct use.

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% — all three parameters (x_app_id, cert_data, cert_type) are documented with formats and enum constraints in the schema itself. The description adds no parameter-level detail beyond the schema (e.g., no hint about which cert_type combinations are valid together), so the baseline 3 applies.

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

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

The description states a specific verb and resource ('Uploads a single PEM-encoded certificate or key') with the format and cert types (signer_cert, signer_key, wwdr) implicit in the schema. The 'PEM-encoded' qualifier distinguishes it from the close sibling uploadP12Certificate, so an agent can tell which cert-upload tool it is.

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 invocation context — the certs:manage scope, the POST /manage-certs mapping, and rate-limit/billing notes — but never says when to prefer this tool over the sibling uploadP12Certificate or when not to use it. Usage is implied via 'PEM-encoded' rather than explicitly contrasted with alternatives.

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

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

Annotations already indicate this is a mutating, non-idempotent operation. The description adds useful behavioral context: credentials are stored securely, the operation maps to a specific OpenAPI endpoint, and standard API/billing/rate limits apply. 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 compact and front-loaded with the core purpose. The redundant opening line 'Upload Google credentials' and the first sentence say nearly the same thing, but the rest of the content is purposeful and concise, adding endpoint and scope information without unnecessary 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 moderate-complexity upload tool with no output schema, the description provides enough context for an agent to select and invoke it: the action, required inputs, scope, endpoint, and operational constraints. Minor gaps like duplicate-credential behavior or error cases are not covered, but the description is largely 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 covers 100% of the parameters, so the baseline is 3. The description names the two required parameters but does not add additional semantic detail beyond what the schema already provides. This is acceptable because the schema descriptions are sufficient.

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: uploading Google service account credentials for Google Wallet pass signing. It identifies the exact resource type and distinguishes this from sibling tools like listGoogleCredentials, deactivateGoogleCredential, and the certificate upload 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 implies the intended use case through the purpose statement and scope, but it does not explicitly state when to choose this over alternatives or when not to use it. No sibling tool is named as an alternative, leaving the agent to infer the selection from 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?

The description is highly transparent, disclosing deletion of previous images on replace, accumulation of strip uploads, manual cleanup, scope, and rate limits. However, annotations declare destructiveHint=false while the description explicitly says uploading non-strip purposes deletes the previous image from storage and DB; this is a direct contradiction, so per rubric the score is 1 and the flag is set.

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 operation, then uses clearly labeled bullets to explain per-purpose behavior. It is lengthy but every section (mechanics, accumulation/replacement semantics, scope, API mapping, rate limits) earns its place.

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

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

For a tool with no output schema, it covers the essential call context: multipart format, purpose-specific behavior, scope, OpenAPI mapping, and the returned id's downstream use. It does not enumerate error conditions or exact response shape, but the provided information is enough 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?

Schema coverage is 100% and already describes purpose and file_base64 well. The description adds value by explaining the multipart field mapping, PNG expectation, and the meaning of the returned id for strip_image_id, going beyond the schema 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 opens with a specific verb and resource: uploading an image for pass templates or per-pass strip overrides. It also clearly distinguishes the operation from sibling image tools (listImages, deleteImage, getImageUsage) by describing the output and 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?

It gives concrete when-to-use guidance: multipart fields, what to do with strip IDs on pass create/update, and which purposes accumulate vs replace. It doesn't explicitly name alternative tools for image management, but the behavior by purpose is specific enough to prevent misuse.

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 meaningful behavior beyond annotations: the bundle is decrypted with the password, certificates are extracted, and stored with AES-256-GCM encryption. It also provides scope, endpoint mapping, and rate-limit/billing context. It does not describe the response shape or failure modes, but annotations already indicate a non-read-only, non-destructive mutation.

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 purpose is front-loaded, followed by scope, endpoint mapping, and API context. There is minor redundancy between the first line and the following sentence, but overall the description is tight and every remaining sentence adds useful information.

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

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

The description covers the operation's behavior, scope, and endpoint, and the schema fully documents the parameters. However, it omits return/response information, error semantics, and explicit guidance on password requirements beyond what the schema already states.

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 reinforces that the password decrypts the bundle and that the data is base64-encoded, but it does not add substantial meaning beyond the input 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 names a specific verb and resource: upload a PKCS#12 (.p12) bundle containing a signer certificate and private key. It also maps to the exact OpenAPI operationId and path, making it easy to distinguish from the sibling uploadCertificate by file type and 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 intended use is implied clearly: use this tool when uploading a .p12 certificate bundle. However, it does not explicitly say when to prefer this over uploadCertificate or other certificate-related siblings, nor does it state exclusions or when not to use it.

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

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

Annotations only signal destructiveHint=true and readOnlyHint=false, so the description carries meaningful extra weight and delivers. It discloses the invalidation side effects (push notifications to registered devices, immediate appearance in Apple Wallet), the non-fatal failure semantics (rebuild failure still voids at the DB level), the required auth scope, and rate/billing limits. This goes well beyond what the annotations convey, particularly the failure-mode nuance.

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

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

The description is tight and well-structured: a one-line summary, then distinct sentences for behavior, side effects, failure handling, scope, endpoint mapping, and constraints. Every sentence adds unique, non-redundant information, and critical behavioral details are front-loaded ahead of the operational footnotes.

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 mutation with no output schema, the description covers the essentials: what happens to the pass, the rebuild behavior, push-notification side effects, non-fatal failure, auth scope, and API constraints. Minor gaps remain — it does not describe the response format, nor what happens if the pass is already voided (relevant given idempotentHint=false). These are small but not trivial for an agent deciding whether a retry is safe.

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 both parameters (id, x_app_id) are already fully documented in the schema. The description's endpoint path /manage-passes/{id}/void reinforces that id is a path parameter, but adds no semantic meaning beyond the schema. At 100% coverage, baseline 3 is appropriate.

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

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

The description opens with a specific verb+resource ('Void a pass') and explains the mechanism in detail: marks the pass invalidated, rebuilds the .pkpass with Apple's voided flag, and pushes notifications. It maps to a concrete endpoint (POST /manage-passes/{id}/void), making the operation unambiguous. However, it does not explicitly distinguish itself from its closest sibling voidPassBySerial, so an agent must infer the by-ID-vs-by-serial difference from the parameter and path.

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

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

The description provides useful operational context: required scope (passes:manage), the OpenAPI operation mapping, and reminders about standard billing/rate limits and not inventing paths. But it never states when to use this tool versus alternatives — notably voidPassBySerial, which performs the same action by a different identifier. The usage window is left implicit in the 'id' parameter rather than being made explicit.

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

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

Annotations already indicate destructive=true, but the description adds valuable context: it rebuilds the .pkpass file with voided: true, sends push notifications to devices, and notes scope and API mapping. This goes beyond annotations and informs the agent 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 moderately sized but every sentence adds value: action, effect, wallet selection, scope, API mapping, and a caution not to invent paths. It's well-structured with front-loaded 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?

For a void operation with no output schema, it explains the process, device impact, and parameter behavior. It doesn't describe the response, but that's a minor gap given the operation's simplicity and the existing annotations.

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 documents all parameters. The description adds meaning for wallet_type (explains default and when to use) and serial_number (uniqueness), which is beyond the schema. It doesn't repeat schema text verbatim.

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 clear verb (void) and resource (pass by serial number), and distinguishes itself from siblings like voidPass and updatePassBySerial. It explicitly mentions the lookup method and the action, leaving no 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 provides when to use this tool (void a pass by serial) and includes a specific scenario for the wallet_type parameter (when both Apple and Google passes exist). It doesn't explicitly state when not to use it, but the purpose clarity and mention of alternatives in sibling names imply the context.

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