Server Quality Checklist

Tool Scores

• build_evidence_packC
  2.7/5.0
  Behavior1/5

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

  The description says 'Fold into a sealed pack' implying creation, but annotations declare readOnlyHint=true and destructiveHint=false, contradicting the implication of a side effect. No additional behavioral traits disclosed beyond the contradiction.

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

  Conciseness3/5

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

  The single-sentence front-loading is good, but the Args section is redundant with the schema, adding unnecessary length.

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

  Completeness3/5

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

  While the description explains the tool's purpose and inputs, it omits description of the return value (though output schema exists). The contradiction with annotations undermines completeness. Adequate but with gaps.

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

  Parameters3/5

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

  Schema description coverage is 100%, so baseline is 3. The description's Args block mirrors the schema without adding new semantics, formats, or constraints.

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

  Purpose4/5

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

  The description clearly states the verb 'Fold into' and resource 'sealed pack', listing the three content types. It is specific but does not explicitly distinguish from sibling tools like seal_pack or sign_pack.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool vs alternatives such as seal_pack, sign_pack, or render_markdown. The description implies usage for combining specific content types but does not state 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.

• seal_packA
  3.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that the seal is computed using SHA-256 and is deterministic, reinforcing idempotency and providing algorithmic detail. No contradictions with annotations.

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

  Conciseness5/5

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

  The description is extremely concise, consisting of two short sentences. It front-loads the core purpose without any filler or redundant explanation. Every sentence adds unique value.

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

  Completeness3/5

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

  For a simple tool with one parameter and an output schema, the description is adequate but minimal. It does not explain what a 'seal' is, the output format, or how it fits into the pack workflow. The existence of an output schema mitigates the lack of return value details.

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

  Parameters3/5

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

  Schema coverage is 100% and both schema and description describe 'pack_content' identically as 'an evidence pack as raw JSON text'. The description adds no new semantic meaning beyond the schema, earning the baseline score.

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

  Purpose5/5

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

  The description clearly states the tool computes a deterministic SHA-256 seal for an evidence pack, specifying the verb 'compute', resource 'evidence pack', and algorithm 'SHA-256'. This distinguishes it from siblings like 'verify_seal' (verification) and 'build_evidence_pack' (construction).

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

  Usage Guidelines2/5

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

  The description provides no explicit guidance on when to use this tool versus alternatives like 'verify_seal' or 'build_evidence_pack'. It only states what the tool does, forcing the agent to infer usage context from the tool name and sibling list.

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

• verify_sealA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint and idempotentHint. The description adds that it compares to an expected digest but does not disclose additional traits beyond what annotations provide.

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

  Conciseness4/5

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

  The description is concise with minimal waste. Two sentences explain the main action and parameters.

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

  Completeness4/5

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

  Given the presence of an output schema and clear annotations, the description adequately covers the verification functionality. It could mention return result but output schema fills that gap.

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

  Parameters3/5

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

  Schema coverage is 100%, and the description's parameter explanations mirror the schema descriptions. No additional meaning is added beyond the schema.

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

  Purpose5/5

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

  The description uses specific verbs ('Recompute', 'compare') and clearly identifies the resource ('pack's seal'). It distinguishes from sibling tools like seal_pack (creates seal) and verify_pack_signature (verifies signature).

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

  Usage Guidelines3/5

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

  The description states the basic operation but does not explicitly guide when to use this tool versus siblings. Usage is implied but not explicitly stated.

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

• verify_pack_signatureA
  3.9/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the specific algorithm (Ed25519) and the concept of 'canonical content,' which provides useful behavioral context beyond annotations. No contradictions.

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

  Conciseness4/5

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

  The main purpose is stated in a single sentence front-loaded. However, the Arg list repetition is redundant given the schema is provided; it adds length without new content. Otherwise efficient.

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

  Completeness4/5

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

  Given the tool's simplicity (3 required parameters, no enums, output schema present, strong annotations), the description covers the essentials: algorithm, input types, and purpose. It lacks error handling details but is complete enough for typical use.

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

  Parameters3/5

  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 parameter descriptions in the tool definition largely duplicate the schema descriptions, adding no new information (e.g., 'base64-encoded' and 'PEM' are already in schema). Minimal value added.

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

  Purpose5/5

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

  The description clearly states the action ('verify'), the cryptographic algorithm ('Ed25519'), and the resource ('detached signature over a pack's canonical content'). This unambiguously distinguishes it from sibling tools like 'sign_pack' and 'verify_seal'.

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

  Usage Guidelines3/5

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

  The description does not provide explicit guidance on when to use this tool versus alternatives. Usage context is implied by the tool's specific purpose, but no exclusions or when-not-to-use advice is given. Given sibling tools exist, a usage hint would improve clarity.

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

• render_markdownA
  4/5.0
  Behavior4/5

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

  Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds context that the output is a markdown compliance report, which is useful beyond annotation hints. 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.

  Conciseness5/5

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

  The description is extremely concise with only two sentences and an Args line, front-loading the purpose. Every sentence adds value, and there is no redundancy or fluff.

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

  Completeness4/5

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

  Given the simple single-parameter schema, comprehensive annotations, and presence of an output schema, the description provides sufficient context. It explains the input and output format, though it could optionally mention that the tool does not modify state (already covered by annotations).

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

  Parameters3/5

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

  Schema description coverage is 100% with a clear description of 'pack_content' as 'An evidence pack as raw JSON text.' The description repeats this without adding new semantics, so it does not significantly enhance parameter understanding beyond the schema.

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

  Purpose5/5

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

  The description clearly specifies the action ('Render'), the resource ('an evidence pack'), and the output format ('as a markdown compliance report'). It distinguishes this tool from siblings like build_evidence_pack (building) and seal_pack (sealing) by focusing on the rendering step.

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

  Usage Guidelines3/5

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

  The description implies usage when you have an evidence pack and need a markdown report, but it does not explicitly state when to use this tool versus alternatives like build_evidence_pack or sign_pack. No exclusions or when-not-to-use guidance is provided.

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

• verify_slsa_provenanceA
  4/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true and destructiveHint=false, but the description adds that it shells out to an external binary and may fetch metadata, and that it returns EP_EXTERNAL_TOOL if the binary is missing. This adds relevant behavioral context beyond annotations.

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

  Conciseness5/5

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

  The description is well-structured with a brief summary, a clear note about external dependencies, and a concise Args section. Every sentence adds value with no fluff.

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

  Completeness4/5

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

  The tool has an output schema, which reduces the need to explain return values. The description covers prerequisites (binary on PATH) and error behavior, which is sufficient for a verification tool. It could mention the result format, but given the output schema exists, the completeness is adequate.

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

  Parameters3/5

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

  Schema description coverage is 100%, and the description provides minimal additional meaning beyond the schema, just restating the relevant arguments. Baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool verifies an artifact's SLSA provenance using slsa-verifier, with a specific verb and resource. It distinguishes from siblings like verify_cosign_signature by specifying SLSA, but does not explicitly contrast with it.

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

  Usage Guidelines4/5

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

  The description indicates that the tool requires a locally installed slsa-verifier binary on PATH and that it may fetch metadata, but does not explicitly say when to use it over other verification tools like verify_cosign_signature or verify_seal.

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

• sign_pack_vaultA
  4.1/5.0
  Behavior4/5

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

  Annotations already indicate openWorldHint=true and destructiveHint=false, and the description adds meaningful context beyond that: it requires a pip extra, makes network calls, POSTs to a specific Vault endpoint, and returns a pack with a vault_signature block. This gives the agent a clear behavioral model 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.

  Conciseness4/5

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

  The description is front-loaded with the core purpose, then uses bolded warnings for installation and network surface, then a compact Args list. It is appropriately sized for a tool with four parameters and a network dependency, though the Args section is somewhat redundant with the schema.

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

  Completeness4/5

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

  Given the output schema exists and annotations cover open-world behavior, the description provides enough extra context: installation requirement, network reach, endpoint, and return shape. It does not deeply discuss authentication edge cases or failure modes, but for this tool's complexity it is sufficiently complete.

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

  Parameters3/5

  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's Args section largely repeats the schema's parameter descriptions without adding new semantics. The endpoint template '/v1/transit/sign/{key_name}' implicitly ties key_name to the API path, but this is minor incremental value.

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

  Purpose5/5

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

  The description opens with a specific verb+resource: 'Sign a pack's canonical bytes with HashiCorp Vault Transit.' It clearly distinguishes this tool from siblings like sign_pack_aws_kms and sign_pack by naming the Vault Transit backend, and it further differentiates by highlighting the network surface.

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

  Usage Guidelines4/5

  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 this tool: when signing with Vault Transit, and it explicitly notes that it 'reaches a Vault server over the network -- unlike the closed-world tools.' It does not explicitly name alternatives or state when not to use it, but the closed-world contrast provides useful selection guidance.

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

• sign_packA
  4.3/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context: the private key is configured via environment, never crosses boundary, returns detached signature/public key/key id, and fails with EP_NO_SIGNING_KEY. 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.

  Conciseness5/5

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

  The description is concise, with a clear one-line summary, followed by essential operational details. No extraneous sentences. The Args section is well-structured.

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

  Completeness5/5

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

  For a simple tool with one parameter, strong annotations, and an output schema, the description covers key aspects: key configuration, return values, error condition. It is fully adequate for the agent.

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

  Parameters3/5

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

  Schema coverage is 100% for the single parameter. The description repeats that pack_content is 'the evidence pack to sign, as JSON text', which adds minimal value over the schema's description. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description uses the specific verb 'Sign' and identifies the resource as 'a pack's canonical content'. It clearly distinguishes from sibling tools like 'verify_pack_signature' and 'seal_pack' by focusing on the signing operation.

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

  Usage Guidelines4/5

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

  The description implicitly places signing as part of a workflow (after building, before sealing) but does not explicitly state when not to use this tool or mention alternatives. However, the sibling context aids differentiation.

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

• sign_pack_aws_kmsA
  4.4/5.0
  Behavior5/5

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

  Adds substantial context beyond the annotations: network reachability, private key never leaving KMS, submission of only the digest, and the return shape ('aws_kms_signature' block). No contradiction with annotations; readOnlyHint=false is consistent with 'returns the pack with a signature block attached'.

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

  Conciseness4/5

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

  The description is well-structured: purpose first, key caveats in bold, then an Args list. It is concise overall, but the Args section repeats schema content already visible to the agent, adding some redundancy without much new information.

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

  Completeness5/5

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

  Given the tool's open-world nature and existing output schema, the description covers the essential operational context: network access, installation requirement, cryptographic behavior, and return value. It is sufficiently complete for an agent to decide whether this tool fits the use case and invoke it safely.

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

  Parameters3/5

  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 three parameters. The description's Args section mostly duplicates the schema text, with only minor added phrasing like 'hosting the key' and 'to sign', which does not materially deepen parameter understanding.

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

  Purpose5/5

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

  Clearly states the verb ('Sign'), the resource (pack's SHA-256 canonical digest), and the method (AWS KMS). It also distinguishes itself from sibling tools by mentioning the network surface and that the private key never leaves KMS, unlike closed-world signing tools.

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

  Usage Guidelines4/5

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

  Explicitly states the requirement for the [aws] extra and that this tool operates over the network, contrasting with closed-world tools. However, it does not name specific alternative tools (e.g., sign_pack_vault) or give explicit when-not-to-use criteria, so it falls short of a 5.

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

• export_pack_to_s3A
  4.5/5.0
  Behavior5/5

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

  The description goes beyond the annotations by revealing that the tool reaches AWS S3 over the network, requires an optional package extra, restricts supported URI schemes, returns a clear error for unsupported ones, and returns bucket, key, and etag. This is meaningful behavioral context that the 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.

  Conciseness5/5

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

  The description is well-organized, front-loads the core action, and uses short sections for requirements, behavior, return values, and arguments. Every sentence contributes useful information without excessive padding.

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

  Completeness5/5

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

  Given its two required parameters, full schema coverage, and existing output schema, the description covers the important nuance: network access, installation requirement, URI scheme restrictions, and returned fields. It is sufficiently complete 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.

  Parameters3/5

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

  Schema coverage is 100 percent and the Args section mirrors the schema descriptions closely. It adds a bit of plain-language context such as 'signed pack to upload' and the destination form, but does not substantially enrich parameter semantics beyond what the input schema already provides.

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

  Purpose5/5

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

  The description clearly states the tool uploads a signed evidence pack to Amazon S3, with a specific destination scope (s3://). It distinguishes itself from sibling tools like sign_pack and verify_seal by identifying its unique network/upload function.

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

  Usage Guidelines4/5

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

  It explicitly explains that the java [aws] package extra is required, that this tool has a network surface unlike the closed-world tools, and that only s3:// is supported with gs:// / az:// returning clear errors. It could slightly improve by naming specific sibling alternatives, but the context is strong.

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

• verify_cosign_signatureA
  4.7/5.0
  Behavior5/5

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

  The description adds significant behavioral context beyond the annotations: it shells out to an external binary, contacts the registry and transparency log, may return an EP_EXTERNAL_TOOL error, and explains the optional keyless parameters. This is exactly the kind of disclosure that helps an agent anticipate side effects and failure modes.

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

  Conciseness5/5

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

  The description is well-structured and efficient: a one-sentence purpose, a bolded external-system warning, and a concise Args list. Every sentence carries meaningful information with no redundancy or filler.

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

  Completeness5/5

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

  Given the tool's complexity, the description covers the key operational aspects: external dependency, PATH requirement, error code, keyless mode, and all parameters. The output schema likely handles return-value details, so no additional output documentation is needed here.

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

  Parameters4/5

  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 meaning by explaining that certificate_identity and certificate_oidc_issuer are only needed for keyless verification, clarifying their role in context. This goes slightly beyond the schema's individual field descriptions.

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

  Purpose5/5

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

  The description clearly states the tool verifies a container image signature with `cosign`, using a specific verb and resource. This distinguishes it from sibling tools like `verify_pack_signature` and `verify_slsa_provenance`, which target different artifact types.

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

  Usage Guidelines4/5

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

  The description gives clear context for use: verify a container image signature via cosign, with keyless verification enabled by supplying certificate identity and OIDC issuer. It notes the prerequisite of cosign being on PATH, but does not explicitly state when not to use the tool or name alternatives.

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