Server Quality Checklist

Tool Scores

• get_findingA
  3.9/5.0
  Behavior4/5

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

  Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by disclosing exactly what the returned finding contains, including how the SOC 2 mapping was derived and its confidence level. There is no contradiction 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.

  Conciseness5/5

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

  The description is a single compact sentence that leads with the core action ('Returns a single finding') and then packs the distinguishing payload details without filler. It is easy to scan and earns its length.

  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 presence of an output schema, read-only annotations, and full input-schema documentation with parameter provenance, the description is complete enough for an agent to invoke the tool correctly. It explains what makes this tool valuable without needing to restate structured schema information.

  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 batchId and findingId already have descriptions that specify their origin from scan_iac and list_findings, respectively. The tool description adds no extra parameter-level 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.

  Purpose4/5

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

  The description clearly states the verb and resource: it returns a single finding, and it enumerates the specific detail categories included: SOC 2 control mapping, mapping derivation and confidence, blast-radius classification, and remediation guidance. It does not explicitly differentiate from siblings like explain_finding, but the 'single finding' framing distinguishes it from list-oriented tools.

  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?

  Usage is implied rather than explicit: the title and description suggest retrieving full details for one finding, and the input schema mentions that batchId comes from scan_iac and findingId from list_findings. However, the description does not state when to prefer this over explain_finding or other related tools, nor does it provide when-not-to-use guidance.

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

• classify_blast_radiusA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds concrete behavioral detail: it deduplicates, classifies by blast radius, and is 'pure and offline: no scan, no network.' No side effects or caveats are omitted.

  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?

  Three sentences, front-loaded with the core transformation, then invocation modes, then a property. No filler or redundant restatement of schema fields.

  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?

  With an output schema, rich annotations, and 100% parameter coverage, the description covers purpose, invocation, and constraints. The parameter precedence (findings ignored when batchId is given) is in the schema, so no gap remains.

  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%, so the baseline is 3. The description adds slight contextual flavor by linking batchId to 'whole scan' and findings to 'results from elsewhere,' but this mostly restates schema semantics rather than adding substantive parameter meaning.

  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?

  States a specific verb 'collapses' and resource 'findings' into 'deduplicated action items' with explicit classification categories. The phrase 'turns 400 findings into 9 action items across 400 resources' clearly differentiates it from sibling tools that list or scan findings.

  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?

  Clearly frames the tool as a post-processing step and offers two invocation modes: batchId for whole scans, findings inline for external results. It does not name sibling alternatives or state when not to use it, but the context is unambiguous.

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

• export_oscalA
  4.3/5.0
  Behavior5/5

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

  The description goes well beyond the readOnlyHint/idempotentHint annotations by disclosing that the result is a STRING, that the server writes no files, and that the document contains deliberate limitations: descriptive criterion IDs due to no SOC 2 catalog, and only 'not-satisfied' findings emitted. These are non-obvious, decision-relevant behaviors.

  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?

  Three sentences with no filler: the first states the core action and format, the second covers return type and side effects, and the third explains the two key limitations. Each sentence earns its place and the most important information is front-loaded.

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

  Completeness5/5

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

  For a one-parameter, read-only, idempotent export tool with a full input schema and an output schema, this description covers every behavioral nuance an agent needs: return type, file effects, and embedded limitations. Nothing material is missing.

  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 single parameter batchId is already documented as 'Batch ID returned by scan_iac,' so the description does not need to add parameter-level detail. The baseline of 3 applies because the schema carries the semantic weight and the description adds no further parameter context.

  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 names a specific verb ('Emits') and a precise resource ('NIST OSCAL assessment-results document (JSON)'), with a clear format and purpose. The machine-readable GRC orientation implicitly differentiates it from human-readable siblings like render_trust_page and preview_trust_page, so an agent can tell them apart.

  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 gives useful context about the output being machine-readable for GRC platforms and assessment tooling, so an agent can infer this is for integrations rather than human review. However, it never explicitly states when to use this tool versus alternatives, nor does it mention any exclusion criteria.

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

• render_trust_pageA
  4.3/5.0
  Behavior5/5

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

  Beyond the readOnlyHint and idempotentHint annotations, the description explicitly discloses that no file is written and the returned HTML is fully self-contained with no CDN, webfont, analytics, script, or external requests. This adds meaningful behavioral detail and aligns 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.

  Conciseness5/5

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

  The description is compact and front-loaded: it states the core behavior first, then gives actionable usage guidance, then explains the self-contained security rationale. Every sentence contributes meaning without redundancy.

  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 annotations and output schema, the description covers the essential operational details: what it returns, that it does not write files, and why the output is self-contained. This is sufficient for an agent to call the tool and handle the result 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 description coverage is 100%, so the schema already documents the parameters. The description references HTML and Markdown, which maps to the format enum, but it does not add extra parameter-level detail beyond the schema.

  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 returns the trust page as a complete HTML or Markdown string. It identifies the exact resource and output form, but it does not explicitly distinguish itself from the sibling preview_trust_page, so it lacks 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.

  Usage Guidelines4/5

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

  The description gives clear practical guidance: the server never writes files, so the agent must save the output itself or have its agent write it to go through approval. This is useful context, though it does not explicitly discuss when to prefer render_trust_page over preview_trust_page.

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

• preview_trust_pageA
  4.4/5.0
  Behavior5/5

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

  The description goes well beyond the readOnly/idempotent annotations by disclosing that no publish or file write occurs, that the output is data-only, and that it never emits compliance language like 'compliant' or 'certified' — with the CPA-attestation rationale explaining why. It also reveals a fingerprint mechanism the viewer can recompute, which is meaningful behavioral detail an agent would not infer from annotations alone.

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

  Conciseness4/5

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

  The description is front-loaded with the primary purpose and then adds traceability, non-publishing, and compliance guardrails. It is somewhat verbose, especially the CPA/attestation rationale, but every sentence contributes substantive context and none of it is 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?

  With one fully documented parameter, an output schema present, and annotations already establishing read-only and non-destructive behavior, the description is complete for safe invocation. It covers the tool's outputs, evidence lineage, side-effect absence, and content constraints, so an agent has everything needed to select and call it 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% because batchId is documented as the batch ID returned by scan_iac. The description adds only 'from a scan' at a concept level and does not provide additional parameter-specific guidance, so the schema carries the load and the baseline of 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 states a specific verb and resource: it 'builds a per-criterion evidence summary from a scan' for a prospect's security team. It also distinguishes itself from publication tools by emphasizing 'returns DATA ONLY — nothing is published and no file is written', which separates it from siblings like render_trust_page.

  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 makes the usage context clear: use this when you need a previewable evidence summary without publishing or persisting anything. It does not explicitly name alternatives or say 'use render_trust_page when you want to publish', so it lacks an explicit when-not, but the data-only framing provides strong implicit guidance.

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

• applicability_briefA
  4.5/5.0
  Behavior5/5

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

  Beyond the annotations (read-only, idempotent, non-destructive), the description adds meaningful behavioral detail: fully local, deterministic, no account, no network call, no model. It also discloses the important caveat that results are prioritization guidance, not scope reduction, which an agent could easily misunderstand.

  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 compact and front-loaded with the core value, then adds the prerequisite call and the critical scope caveat. Every sentence earns its place; there is no repetition of schema or annotation content.

  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?

  With a full input schema, an output schema, prerequisite guidance, and behavioral disclosure, the description is complete for an agent to select and invoke the tool correctly. The key caveat about not reducing scope is explicitly stated, and return-value details are covered by the output schema.

  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 every parameter described and all eight using enums, so the schema carries the parameter documentation burden. The description adds context about the questions collectively but no per-parameter meaning beyond the schema, which is acceptable given full coverage.

  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 names a specific action (answering eight questions) and a clear resource (the 33 SOC 2 Common Criteria), and explains exactly what the tool returns: tailored meaning and priorities for each criterion. It is immediately distinguishable from siblings like applicability_questions, which is positioned as a prerequisite rather than the same action.

  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 clearly instructs the agent to call applicability_questions first and warns that the tool does not remove criteria from scope, which prevents a critical misuse. It doesn't explicitly enumerate alternative tools or when-not-to-use conditions beyond the prerequisite, but the context is clear enough for routing.

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

• controlsA
  4.5/5.0
  Behavior5/5

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

  Annotations already mark the tool read-only and idempotent, and the description adds meaningful behavioral context beyond that: it limits scope to 33 Common Criteria, states which categories are not covered, and explains the IaC evidence limitations (3 primary, 8 partial, 22 requiring non-scan evidence). It also tells the agent how each control reports scan capability via `iac` and `iacNote`. This is substantial added transparency with no contradiction.

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

  Conciseness5/5

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

  The description is compact and well structured: it opens with the core behavior, then scope, then the important evidence caveat. Every sentence carries useful information and none are redundant with the annotations or schema. The front-loaded main sentence lets an agent quickly understand the tool.

  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 read-only catalog retrieval tool with one optional enum parameter and an output schema, the description is complete. It covers what the catalog contains, what it excludes, how parameter omission behaves, and what evidence capability each control reports. No critical missing context stands out.

  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?

  The schema already describes the only parameter well at 100% coverage: controlId is an enum with 'Omit for the full catalog.' The description reinforces this and adds context about what the enum values represent (CC1.1-CC9.2) and that optional categories are excluded, but it does not add materially new parameter-level semantics beyond the schema.

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

  Purpose5/5

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

  The first sentence states a specific action and resource: 'Returns the SOC 2 control catalog this server evaluates against.' The description further clarifies the exact scope (SOC 2 Security category, CC1.1-CC9.2) and distinguishes what it is not (optional A/C/PI/P categories). This is clear enough to separate it from sibling tools like list_policies or map_iac_finding_to_control.

  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 direct usage guidance: pass controlId for a single control, omit it for the full catalog. It also explicitly excludes the optional A/C/PI/P categories, which prevents a common misuse. It does not explicitly name sibling alternatives or state when not to use this tool, but the usage context is clear.

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

• draft_policyA
  4.5/5.0
  Behavior5/5

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

  Even though annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the description adds meaningful behavioral detail beyond them: the server writes no files, placeholders are explicitly marked and counted rather than silently filled, and the draft itself warns that possessing the document does not satisfy the SOC 2 criteria. This is exactly the kind of non-obvious behavior an agent needs to know.

  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 dense but each sentence earns its place: purpose and format, grounding source, placeholder behavior and rationale, and the audit-safety caveat. The core function is front-loaded, and the additional sentences address exactly what an agent must not overlook.

  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 lack of detailed documentation for 11 parameters, and the presence of annotations and an output schema, the description is remarkably complete. It clarifies output format, side effects, placeholder handling, and a non-behavioral safety concern. There is no missing behavioral information that would prevent correct invocation or mislead 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 description coverage is only 27%, so the description bears extra responsibility for parameter semantics. It does add useful meaning by tying the draft to applicability_brief answers and an optional scan batch, which helps map parameters to context. However, it does not explain the individual parameter roles or how they override or supplement the applicability_brief answers, leaving much of the semantic burden on self-explanatory enum names and 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 opens with a specific verb and resource: it produces a policy DRAFT in Markdown, grounded in applicability_brief answers and optionally a scan. It clearly distinguishes itself from sibling tools like list_policies (which lists existing policies) and applicability_brief (which gathers answers), so an agent can tell them apart immediately.

  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 explicitly states the grounding requirement: use the answers from applicability_brief and optionally a real scan. This gives clear when-to-use context. It does not explicitly name when not to use this tool or mention alternatives by name, so it stops 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.

• explain_findingA
  4.5/5.0
  Behavior5/5

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

  Beyond the readOnly/idempotent annotations, the description adds a meaningful behavioral guarantee: every output is derived from the finding itself and it never invents a risk claim. It also discloses that missing or weak control-mapping data will be explicitly flagged rather than silently filled in, which is important trust context for an AI agent.

  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?

  Three sentences each carry distinct information: what the tool produces, the content of the output, and the honesty/limitation behavior. The list of explanation components is compact and front-loaded, with no 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?

  For a read-only tool with two simple required parameters and an output schema, the description covers what the result contains, where the data comes from, and how gaps are handled. Nothing essential is missing for correct invocation and interpretation.

  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%, so the two parameters are already documented in the input schema. The description adds no extra parameter-level semantics beyond identifying the finding context, so the 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 names a specific resource ('a finding from a scan') and a specific action ('explains it without jargon'), then enumerates exactly what the explanation covers: meaning, risk, auditor relevance, remediation, and fix size. This separates it from siblings like get_finding (raw retrieval) and map_iac_finding_to_control (mapping only), even though no sibling is named.

  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 purpose is clearly to get a plain-English, auditor-oriented explanation of a specific finding, so an agent can infer when to call it after identifying a finding. It does not explicitly name alternatives or state when not to use it, but the context is clear enough that no exclusions are needed for a read-only explanation tool.

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

• list_policiesA
  4.5/5.0
  Behavior4/5

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

  Annotations already indicate read-only, idempotent, non-destructive behavior, so the description need not repeat that. It adds valuable behavioral context by revealing that the tool returns not just policy names but also SOC 2 criteria and extra deliverables beyond the document, which goes beyond the raw 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 a single sentence but conveys three distinct pieces of information: the scope (server-draftable policies), the criteria mapping (SOC 2), and the caveat about additional required outputs. There is no redundancy with the title or annotations, and every clause earns its place.

  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?

  With zero parameters, a rich output schema, and safety annotations already provided, the description covers the essential operational context: what the tool returns, the scope of that return, and a key nuance about what else is needed. Nothing critical is missing for an agent to decide whether to call this tool.

  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?

  The input schema has zero parameters, so there is no parameter burden for the description to carry. The baseline for a parameterless tool is 4, and the description appropriately focuses on return semantics instead.

  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 states a specific verb ('Returns') and resource ('the policies this server can draft'), and further specifies what each policy supports: SOC 2 criteria and additional required deliverables. This clearly distinguishes it from sibling tools like draft_policy or list_findings.

  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 clearly implies the tool should be used when an agent needs to see which policies are draftable and what each entails, which differentiates it from scanning or finding tools. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for selection.

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

• scanner_statusA
  4.5/5.0
  Behavior4/5

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

  The annotations already declare the tool read-only, idempotent, and non-destructive. The description adds useful behavioral context by specifying exactly what information is reported and when it is appropriate to call, 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.

  Conciseness5/5

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

  Two sentences carry all necessary information: the first enumerates the report contents, the second gives a direct usage directive. No filler or redundancy.

  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?

  With no parameters, a rich output schema, and strong annotations, the description is fully sufficient. It explains the tool's scope and provides actionable guidance for when to call it.

  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?

  The tool has zero parameters, so there is nothing to explain. The schema coverage is effectively complete, and the description correctly focuses on behavior rather than inputs.

  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 states a clear verb ('Reports') and specific resources: installed IaC scanners, supported control framework, and trusted roots to be scanned. This precisely distinguishes the tool from its siblings, which focus on scanning and finding operations.

  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 explicitly says 'Call this first when a scan fails,' providing clear diagnostic context. It does not list exclusions or alternative tools, but the guidance is sufficient for a zero-parameter status tool.

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

• applicability_questionsA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so no safety disclosure is needed. The description adds behavioral context by explaining that the returned questions are meant to be asked conversationally and that they feed into applicability_brief. It also discloses the substance of the return value (questions, allowed values, rationale).

  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?

  Two sentences carry the full purpose, content, and usage workflow with no wasted words. The return content is front-loaded, and the actionable instruction is placed second. This is an ideal length for a zero-parameter tool.

  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?

  With no parameters, an output schema present, and a clear usage instruction, the description covers everything needed for correct invocation. It even tells the agent what to do with the result (ask the user) and what to call next. Nothing important is missing.

  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?

  The tool has zero parameters, so there is nothing for the description to clarify. The schema is empty and fully documented by its nonexistence. The description appropriately focuses on the tool's output and usage rather than inventing parameter details.

  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 states a specific verb ('Returns') and a clear resource ('the eight questions used by applicability_brief'), and it distinguishes the tool by naming the sibling it serves. It also explains what content is included: allowed values and the rationale for each question. This is unambiguous and contextually rich.

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

  Usage Guidelines5/5

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

  The description gives explicit usage instructions: ask the user the questions conversationally, then call applicability_brief. This establishes the tool's role in a workflow and its relationship to the obvious sibling tool. No alternative tool could be confused for this one after reading the guidance.

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

• check_capabilitiesA
  4.7/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds meaningful behavioral nuance beyond that: it distinguishes server-side read-only behavior from token-level write capability, and it promises the tool never reads, stores, or transmits token values. It also clarifies the mechanism of asking each CLI what it is logged in as.

  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 dense but every sentence earns its place: the core report capability, the important read-only distinction, a direct usage instruction, and a security guarantee. It is front-loaded with the main function before providing context.

  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?

  With no parameters, rich annotations, an output schema, and a description covering purpose, usage context, and security-relevant behavior, nothing essential is missing for an agent to select and invoke this tool correctly.

  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?

  The tool has zero parameters, so there is no parameter semantics burden on the description. The baseline of 4 applies because nothing needs to be documented beyond the already-complete empty 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 names a specific verb ('Reports') and a specific resource: which cloud/VCS CLIs are authenticated and whether those credentials are write-capable. This clearly distinguishes the tool from the scanner/policy/finding siblings, none of which address credential capability checking.

  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 explicitly says to call this tool 'before telling anyone the integration is read-only', giving a clear trigger condition. It does not name alternatives or exclusions, but no sibling tool appears to be a close alternative, so the guidance is adequate.

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

• map_iac_finding_to_controlA
  4.7/5.0
  Behavior5/5

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

  Annotations already declare readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description adds valuable behavioral detail beyond annotations: it always returns mappingSource and confidence, explains what low confidence means, and clarifies that unmapped is a real answer rather than a failure. This materially helps an agent interpret the tool's response.

  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 compact and front-loaded. The first sentence states what the tool does, the second gives usage context, and the final paragraph explains output semantics. Every sentence earns its place with no filler or redundancy.

  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 simplicity, the rich input schema, the output schema, and the safety-related annotations, the description covers everything an agent needs: what it does, when to use it, what it returns, and how to interpret confidence and unmapped results. No critical behavioral gap remains.

  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 description coverage is 100%, so the baseline is 3. The description adds semantic meaning for resourceType by explaining that it 'corroborates' and raises mapping confidence, which is not fully captured in the schema. It does not add much for checkId or checkName, but those are already well documented in 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 a specific verb ('maps') and identifies the exact resource and outcome: a scanner check to a SOC 2 Trust Services Criterion. It also explicitly distinguishes itself from scan-based tools by stating it runs 'without running a scan,' which helps an agent separate it from siblings like scan_iac.

  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 when-to-use context: checks surfaced by another tool, CI output, or a scanner this server does not wrap. It also implies an exclusion ('without running a scan'), but it does not explicitly name alternative tools or state when to prefer those siblings.

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

• scan_iacA
  4.7/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint and idempotentHint, and the description adds meaningful behavioral context: the scan runs entirely on this machine, file contents are never transmitted, and the result is a summary/handoff rather than the full findings. This goes well beyond the annotation baseline and does not contradict it.

  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 dense but each paragraph earns its place: core action, privacy guarantee, result handoff, path requirement, and scope boundary. It is front-loaded with the primary purpose and contains no filler or repetition.

  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 multi-framework scanning tool, the description covers the essential operational details: supported frameworks, scanner choice, local-only execution, absolute path requirement, output handoff flow, and strict scope limitations. An output schema exists, so return-value documentation is not needed.

  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 applies. The description reinforces that path must be absolute, but the schema already states this; it adds little new parameter-level meaning beyond what the structured definitions provide.

  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 and resource: scans Infrastructure-as-Code for security misconfigurations and maps each finding to a SOC 2 Trust Services Criterion. It also clarifies the tool's role relative to downstream siblings like list_findings and get_finding, making its purpose unambiguous.

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

  Usage Guidelines5/5

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

  The description explicitly tells the agent what to do after scanning: call list_findings with the returned batchId, then get_finding for detail. It also scopes use to SOC 2 Security, lists unsupported standards, and warns against claiming unsupported coverage, which provides clear when-to-use and when-not-to-use guidance.

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

• list_findingsA
  4.9/5.0
  Behavior5/5

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

  Annotations already mark this read-only and idempotent, and the description adds meaningful behavioral context beyond those hints: it returns lightweight rows, pages via a cursor, and—crucially—never filters UNKNOWN severity findings, with a rationale. This non-obvious filter behavior could change an agent's interpretation of results, so disclosing it is high value.

  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 compact and front-loaded: the main action and sibling distinction appear in the first sentence, and the second paragraph justifies a crucial filter exception without repetition. Every sentence earns its place.

  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 paginated list tool with a rich output schema and full parameter documentation, this description covers the workflow context, row granularity, and a key behavioral exception. Nothing an agent needs to call it correctly is missing; the output schema presumably handles return-field details.

  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 value by explaining the UNKNOWN severity behavior with an underlying reason and by characterizing the return rows as lightweight, which informs how an agent should interpret limit and cursor parameters. It does not systematically enrich every parameter, but the minSeverity context goes 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 states a specific verb and resource: 'Pages through findings from a previous scan_iac call.' It also distinguishes itself from get_finding by noting it returns lightweight rows rather than full detail, which differentiates it from a key sibling without opening schemas.

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

  Usage Guidelines5/5

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

  It explicitly ties usage to a prerequisite ('from a previous scan_iac call') and routes the agent to get_finding when full detail is needed. The UNKNOWN severity caveat also tells the agent when not to expect filtering behavior, providing actionable selection guidance.

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