agent-bom
Server Quality Checklist
Latest release: v1.0.4
- Disambiguation4/5
Most tools have distinct targets and clear descriptions, but there is some overlap in the scanning family (e.g., model_file_scan vs. model_provenance_scan) and the inventory tools (inventory_summary, inventory_list, inventory_asset, inventory) could cause misselection without careful reading.
Naming Consistency4/5Naming is predominantly snake_case with descriptive domain prefixes (e.g., runtime_blueprint_drift, identity_rotate), but a few single-word tools (scan, check, verify, diff, where, inventory) break the pattern and create slight inconsistency.
Tool Count1/5With 84 tools, this is an extreme count for any server. Even for a comprehensive security platform, it exceeds reasonable scope and would be better split into multiple focused servers, making the surface overwhelming and difficult to navigate.
Completeness4/5The tool surface covers a wide range of security functions—scanning, governance, runtime monitoring, cloud assessments, and compliance—with few obvious dead ends. Minor gaps exist (e.g., no update/delete for tickets or exceptions), but agents can work around them using the available lifecycle tools.
Average 4/5 across 84 of 84 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 113 of 126 community issues answered or closed in the last 6 months
- 1463 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the agent knows this is a write operation. The description adds the 'pending' state, which is useful, but it does not explain the effects, reversibility, or what the output represents. The 'shared REST/UI/MCP lifecycle' phrase is vague and adds little behavioral detail 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy or fluff, making it very concise. The sentence gives a clear action and object, though the lifecycle phrase is ambiguous. It is well-structured for its brevity, but the content is minimal rather than effectively enriched.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters and an output schema, the description is severely under-specified. It does not explain what a 'pending exception' is, when to submit one, what the response contains, or how it relates to the exception workflow. The schema covers parameter syntax, but the tool-level context needed for correct invocation is largely missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all nine parameters are documented in the schema. The tool description adds no parameter-specific meaning, which aligns with the baseline of 3 for high schema coverage. No compensation is needed since the schema suffices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (create) and resource (pending exception), making the core purpose clear. However, it does not differentiate from sibling tools like approve_exception or list_exceptions, which would have earned a 5. The title adds vulnerability specificity, but the description itself remains generic about the exception domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Sibling tools include list_exceptions and approve_exception, but the description neither mentions them nor explains the lifecycle stage at which this tool applies. The vague phrase 'shared REST/UI/MCP lifecycle' offers no actionable usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose destructiveHint=true, so the description's 'activate' aligns but adds little detail. It does not explain side effects, reversibility, or the audited nature of the write (though parameters mention 'audited write'). The 'canonical lifecycle store' phrase adds no behavioral context. Since annotations carry most of the burden, and the description contributes minimal additional disclosure, this is below baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that states the main action upfront. The inclusion of 'through the canonical lifecycle store' is somewhat redundant but does not bloat it materially. It is concise and structured acceptably, though it could be more informative without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and 100% parameter coverage, the description is inadequate for a destructive write operation. It omits the domain (vulnerability exceptions), the expected workflow (request -> approve), prerequisites, and any caveats. The sibling list includes closely related tools like 'request_exception' and 'list_exceptions', and this description does not clarify how it fits. Two sentences of context could dramatically improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all five parameters. The description does not add any extra meaning to parameters like 'exception_id' or 'reason'. It implicitly relates to approving an exception but adds no syntax or usage nuance. Because coverage is high, the baseline of 3 applies; the tool does not need the description to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'activate' with a resource 'pending exception', which clearly indicates the action. It distinguishes from siblings like 'request_exception' (creating) and 'list_exceptions' (listing), though the phrase 'canonical lifecycle store' is vague jargon that obscures the actual domain (vulnerability exceptions) and may confuse an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it operates on exceptions created via 'request_exception', nor when it should be avoided (e.g., for already-active exceptions). An agent is left to infer the workflow from the name and siblings with no explicit conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds minimal extra behavior insight (current, web/news) but does not discuss output format, pagination, or rate limits. It doesn't contradict 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence stating purpose is concise and front-loaded. It wastes no words, but could benefit from a brief usage hint. Still, for a simple tool with rich schema, this is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema and fully described parameters, the description could rely on those, but it offers no context about how the search integrates into threat intelligence workflows or what types of queries are most effective. It is minimally sufficient for a search tool but does not elaborate on limitations or special behaviors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema defines all parameters. The tool description adds no additional meaning beyond saying it searches for current web or news, which only loosely relates to the freshness parameter. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Search' and the resource 'You.com', specifying 'web or news context' which is clear. It distinguishes from siblings implicitly since no other search tool exists among them, but it could be more explicit about threat intelligence relevance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives or prerequisites. The phrase 'current web or news context' implies freshness but doesn't explicitly recommend this tool for threat intel searches or mention 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.
- Behavior3/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 the safety profile is covered. The description adds useful behavioral context by naming the specific outputs (durable activity, self-posture evidence) which are not in the annotations. It does not contradict annotations and provides a modest amount of additional behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words. It front-loads the main outputs in a structured list and avoids redundancy with the schema. It is appropriately sized for the tool's breadth, covering all major categories without elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity (5 params, output schema, annotations). The description covers the main outputs but does not explain what 'durable activity' means or how to paginate via cursors, and it omits any note about when to use it relatively to sibling tools. Given the output schema and annotations, many details are covered externally, but the description is not fully self-sufficient for an agent deciding when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all five parameters. The description does not add semantic detail beyond the schema, except a slight hint that 'optional self-posture evidence' maps to include_self_posture. Per the calibration, a baseline of 3 is appropriate when the schema carries the parameter burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return') and a clear resource (gateway) with its main output categories (policy, firewall, durable activity, optional self-posture evidence). It is not a tautology and distinguishes the general domain from other tools, though it does not explicitly contrast with sibling status tools like shield_status or proxy_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or context such as 'use for gateway health checks'. With many sibling status tools present, the lack of differentiation leaves the agent to infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the operation's safety profile is covered by structured data. The description adds modest context beyond annotations — 'one... snapshot' signals a single point-in-time artifact and 'bounded' signals constrained scope — but it does not disclose audit expectations, stale-evidence handling, or how the resulting snapshot is later retrieved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
At six words, the description is extremely efficient. 'Create' is front-loaded, and every modifier — 'one,' 'bounded,' 'provenance-rich' — earns its place given that the schema and annotations carry the detailed documentation burden.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema fully documents all 9 parameters, annotations cover idempotency and non-destructiveness, and an output schema exists, so an agent can technically invoke the tool correctly. However, for a tool with 9 parameters and 80+ siblings, the absence of any guidance on when to use this snapshot tool versus runtime_correlate, or how results are later consumed via graph_correlation_status, is a real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented in the input schema, which sets the baseline at 3. The description's 'bounded' and 'provenance-rich' add interpretive color about the overall operation but no parameter-level detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'Create' and the resource 'correlation snapshot,' with 'bounded' and 'provenance-rich' conveying scope and data focus. It is clear but does not explicitly differentiate itself from closely related siblings such as runtime_correlate or graph_correlation_status, so the agent must inspect the schema to understand the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The one-line description provides no when-to-use context, no exclusions, and no mention of alternatives. Given the sibling list contains runtime_correlate and graph_correlation_status, an agent receives no guidance on when a bounded snapshot correlation is the right choice versus runtime or status-checking operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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 the safety profile is fully covered. The description adds modest context by specifying the read facets (state, receipts, freshness, conflicts, bounds), but it does not disclose additional behavioral traits such as authorization requirements, rate limits, or what happens if the correlation no longer exists. This is consistent with annotations, adding some but not rich 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the action verb 'Read', and no filler. Each listed facet adds meaning, and the tool relies on structured schema fields for the remaining details. Efficient and appropriately compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only status tool with 2 parameters (1 required), complete schema coverage, full annotations, and an output schema, the description adequately states what it reads. It would be slightly more complete if it explicitly indicated the prerequisite correlation workflow, but the parameter description already tells the agent that correlation_id is returned by graph_correlate, filling that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both tenant_id and correlation_id already documented. The description contributes no parameter-level information beyond the schema; the key provenance fact that correlation_id comes from graph_correlate is already in the schema. Per baseline, 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and enumerates the resource facets: run state, receipts, freshness, conflicts, and analysis bounds. This clearly identifies it as a status/read tool for correlation graphs, and the read verb distinguishes it implicitly from siblings like graph_correlate. However, it does not explicitly contrast with any sibling, so it falls just short of the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no exclusions, and no mention of the expected workflow (e.g., after graph_correlate). The schema parameter description for correlation_id does imply the correlation flow, but the tool description itself offers no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, etc. Description adds no further behavioral details (e.g., no mention of scanning depth, file types, or output structure). Adequate but basic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant information, front-loaded with key verb and resource. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is minimal and does not elaborate on what 'AI component usage patterns' entails. Could benefit from a brief list of scanned elements (e.g., SDK imports, model refs) already partially in parameter description but not in tool description itself. Adequate for simple tool but not comprehensive given numerous siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema already fully describes the 'directory' parameter with 100% coverage. Tool-level description adds no extra parameter meaning beyond the schema's rich description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb ('scan') and resource ('source code for AI component usage patterns'). Distinguishable from sibling tools like code_scan or prompt_scan by focusing specifically on AI component usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as model_file_scan or inventory. Does not mention prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations fully cover safety (readOnlyHint, idempotentHint) so the description need not repeat those. It adds context about the AISVS standard but no additional behavioral 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key purpose. Every word contributes value; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and good annotations, the description is nearly adequate but omits the default behavior (all 9 checks) and does not reference the output schema or differentiate from similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'checks' has a complete description in the schema (100% coverage). The tool description does not add any extra meaning beyond the schema, which already explains the comma-separated IDs and default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs AISVS v1.0 compliance checks, using a specific verb and standard. It distinguishes from siblings like cis_benchmark by naming a different standard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like compliance, check, or cis_benchmark. The description lacks when/when-not criteria or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description directly contradicts the annotations: it states 'Idempotent per finding' while the idempotentHint is false. This is a serious inconsistency, making the description untrustworthy about behavioral traits. Even though it discloses auth source and required scope, the contradiction nullifies transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the purpose, the second explains the connection mechanism, required scope, and idempotency. No fluff, front-loaded, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters and an output schema, the description gives helpful context about the stored connection, admin scope, and idempotency claim. However, the idempotency contradiction undermines reliability, and it does not describe side effects beyond the annotation's destructiveHint. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage of parameters with descriptions. The tool description adds no significant parameter semantics beyond what the schema already provides; mentions of connection and idempotency are already covered in parameter descriptions (connection_id, finding_id). Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'File an ITSM ticket for a finding through a stored connection.' It uses specific verb 'file' and distinguishes this creation tool from siblings like sync_ticket_status, which suggests an update operation. The title and description align.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by noting the tool requires an admin operator and the 'ticketing:write' scope, and that auth/base URL come from the stored connection. It does not explicitly name alternatives or give when-not guidance, but the purpose of creating a ticket is clearly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description's 'Compare' action adds minimal behavioral context. No additional traits like performance or scope are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise and front-loaded with the core action and resources, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description is functionally adequate given the output schema and high schema coverage, it lacks context on what 'drift' entails or how results are presented, leaving room for interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters having descriptions. The tool description does not add any parameter-specific detail beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Compare' and the resources 'current runtime traffic' and 'approved role/profile blueprint', making the tool's purpose specific and distinguishable from siblings like 'runtime_blueprints' which likely manages blueprints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as 'runtime_correlate' or 'diff'. The description does not provide conditions or prerequisites for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive. Description adds no extra behavioral context beyond confirming it's a verification operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words, front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists but description lacks context on what Sigstore provenance means or verification outcomes. Adequate given annotations and schema, but could add more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'path'. Description does not add additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Verify' and resource 'Sigstore provenance for skill and instruction files', which is specific and distinguishes from sibling tools like 'skill_scan' or 'verify'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. With many sibling tools, explicit context is needed but missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond the annotations, which already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description simply restates the purpose, so it does not contradict annotations but also does not enrich the agent's understanding of side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 8 words, with no redundancy or filler. It is front-loaded and immediately clear, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 parameters, output schema present, no nested objects), and the description covers its core function. While it could mention that results are returned via the output schema or that it queries external sources, the combination of annotations and schema provides sufficient context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already documents both parameters (model_id and source) with clear examples and default values. The description adds no further semantic information, so it meets the baseline expectation for parameter clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check ML model provenance and supply chain metadata.' It uses a specific verb ('Check') and resource ('ML model provenance'), and the tool name itself differentiates it from sibling tools like model_file_scan or license_compliance_scan, which focus on other aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or limitations. It only states what the tool does, leaving the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent, and open-world behavior. The description adds context about scanning for trust, findings, and provenance, which aligns with annotations but does not disclose additional behavioral 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and resource. It contains no extraneous words or redundant information, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a simple parameter set, full schema coverage, rich annotations, and an output schema, the description is largely complete. It covers the tool's purpose and scope, though it could briefly mention the scanning depth or what 'findings' encompass for greater clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single 'path' parameter with a description, achieving 100% coverage. The tool description does not add any further explanation about the parameter's usage or formatting, so it meets the baseline without enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans skill and instruction files for trust, findings, and provenance. It uses a specific verb and resource, and differentiates from siblings like 'skill_trust' and 'skill_verify' by highlighting the comprehensive scanning purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative sibling tools such as 'skill_trust' or 'skill_verify'. It does not mention prerequisites, exclusions, or typical scenarios, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description confirms the read-only scanning behavior but adds no further behavioral context (e.g., performance, file system access). It adds moderate value 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence (12 words) that is front-loaded with action and resource. Every word adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple scanning tool with one parameter and output schema present, the description sufficiently covers the purpose. However, it omits any note about supported artifact formats or depth of scanning, but the schema and output likely fill those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema includes a parameter description covering directory content (MLflow, Kubeflow, W&B artifacts). The tool description adds no additional parameter meaning beyond restating the schema. With 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (scan), resource (directory), and specific purpose (ML training pipeline lineage and provenance). It distinguishes from sibling tools like code_scan or model_file_scan by focusing on training pipeline artifacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., model_provenance_scan, dataset_card_scan). The description does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent, and open-world behavior. The description adds the notion of 'assess security posture' but does not disclose any additional behavioral traits such as potential impacts, rate limits, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, front-loaded with the action and resource. Every word is necessary, no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional parameter, good annotations, output schema exists), the description covers the core purpose effectively. However, it could be more complete by briefly explaining what 'security posture' assessment entails, though not strictly necessary with the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with the 'hosts' parameter clearly described via examples and defaults. The tool description does not add further parameter meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans for running vector databases and assesses their security posture. It uses a specific verb ('scan') and resource ('running vector databases'), distinguishing it from siblings like 'scan' or 'ai_inventory_scan'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, leaving the agent to infer appropriateness from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnly, idempotent, and openWorld hints. The description adds context about the output being ranked and identical to dashboard objects, but does not disclose potential limits, error handling, or performance traits. It complements annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that deliver the core purpose and context without waste. The main action is front-loaded in the first sentence, and the second sentence adds relevant user audience information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, rich annotations, and an output schema), the description provides sufficient context about the intended users and use case. The presence of an output schema covers return values, and annotations cover safety, making the description complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all four parameters are already well-documented in the schema. The description does not add any additional meaning or constraints beyond what the schema provides, meeting the baseline for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns ranked ExposurePath JSON for headless security agents. It mentions specific MCP clients and distinguishes itself as the 'agent-native graph surface', differentiating from siblings like blast_radius or context_graph. However, it could more explicitly contrast with similar graph 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is for headless agents and lists target clients, but it does not provide explicit guidance on when to use this tool versus alternatives like blast_radius or graph_export. No when-not-to-use or alternative references are given, only implicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
'Without recording it to the control-plane tally' adds explicit behavioral context beyond the annotations (readOnlyHint, idempotentHint). Consistent with annotations and clarifies the dry-run nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with the core action and conditions. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple dry-run nature and presence of output schema, the description does not need to detail return values. However, it lacks context on what determines the firewall decision or how results are presented, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a clear description. The tool description does not add additional parameter meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
'Dry-run an inter-agent firewall decision' clearly states the verb (dry-run), resource (firewall decision), and scope (inter-agent). It distinguishes from siblings that may actually enforce or record decisions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like policy_check or check. The description implies a testing use case but does not state when not to use it or which sibling to prefer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds minimal behavioral context beyond stating it is from governed sources. It does not disclose potential limitations, data freshness, or failure states, but annotations cover the safety profile adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose efficiently. Every word is meaningful, and there is no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 optional parameters and an output schema, the description is adequate but does not elaborate on what 'local' means or the nature of 'governed intel sources.' It relies on the schema and output schema for full context. For a daily brief tool, additional context on scope or typical usage would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional semantic meaning for the parameters beyond what the schema provides. The parameters are well-documented in the schema, so the description's lack of param details does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a local analyst threat brief from governed intel sources. It specifies a specific verb ('Return'), resource ('threat brief'), and source ('governed intel sources'), distinguishing it from siblings like intel_lookup (specific indicator lookup) or intel_sources (source listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a daily brief but provides no explicit guidelines on when to use this tool versus alternatives like intel_lookup or audit_query. No exclusions or conditions are mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds context about scanning for 'dangerous permissions' but does not elaborate on what that means or how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no extraneous words, immediately conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 param, output schema present) and annotations, the description is sufficient for an agent to understand the tool's primary function, though it could hint at expected output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for the only parameter. The tool description adds no additional parameter information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Scan') and the resource ('installed browser extensions') with a specific focus ('dangerous permissions'). This distinguishes it from sibling tools like code_scan or fleet_scan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for scanning browser extensions but provides no explicit guidance on when to use or avoid this tool, nor does it mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, open world. Description adds that matching is against 'local' advisories, providing context beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, front-loaded verb. Efficient and clear for a tool with high schema coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema, annotations, and output schema, the description is sufficient. Could hint at batch matching (packages parameter) but schema already does. Not a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with detailed descriptions for all 6 parameters. Description only vaguely mentions 'package inventory coordinates' but adds no new semantic value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'match' and resource 'package inventory coordinates' to threat-intel advisories. Clearly distinguishes from siblings like intel_lookup and intel_daily_brief.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Does not mention alternatives like intel_lookup or scan. Usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey safety and idempotency; description adds the 'no CVE scanning' trait but omits other behaviors like output details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single efficient sentence front-loaded with action verb, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given rich annotations, schema, and output schema, the description is largely complete, adding the key differentiator; could mention output scope but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers the parameter fully; tool description adds no extra meaning beyond baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists MCP configurations and servers, with explicit exclusion of CVE scanning, distinguishing it from sibling scanning 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage via 'without CVE scanning' but lacks explicit when-to-use or alternatives; only gives a constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds operational context by noting tenant scoping and the canonical store, which is useful but does not disclose additional behavioral traits like pagination, rate limits, or auth requirements. Given the annotation coverage, the description provides modest extra value beyond the baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose ('List tenant-scoped exception evidence') and adds the store qualifier without filler. Every word earns its place; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing operation with three optional parameters and an output schema provided, the description covers the essential scope. It does not mention edge cases like default tenant resolution or result ordering, but these are minor given the schema and output schema. The tool is simple enough that the description, combined with structured data, is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—all three parameters (limit, status, tenant_id) have detailed descriptions with defaults and ranges. The description adds no parameter-level detail, which is acceptable because the schema fully documents them. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a specific resource ('exception evidence'), and a clear scope ('tenant-scoped' and 'canonical store'). It distinguishes itself from sibling tools like request_exception and approve_exception by focusing solely on listing existing exceptions, which is immediately clear from the language.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for retrieving existing exceptions, but it does not explicitly contrast with create/approve workflows or mention when to prefer it over siblings. It provides context ('tenant-scoped', 'canonical store') but no explicit exclusion or alternative routing, so guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, covering safety and side effects. The description adds the concept of 'assess serialization risks', which provides behavioral context beyond a simple directory listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no superfluous words. It is appropriately front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter with full schema coverage and annotations covering behavioral traits, the description is mostly complete. However, it lacks explanation of what 'serialization risks' entails and what the output schema provides. Still, it is sufficient for a focused tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with a description of the 'directory' parameter that lists file extensions. The description adds no extra semantic meaning beyond what the schema provides, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'scan' and the resource 'directory for ML model files', and adds the specific assessment of 'serialization risks'. This distinguishes it from sibling tools like dataset_card_scan or prompt_scan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives like code_scan or vector_db_scan. There is no mention of when not to use it or what distinguishes it from similar scanning tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already mark it as read-only and idempotent, the description adds value by specifying that returned alerts exclude prompts, arguments, or responses. This behavioral detail aids agent understanding of the tool's scope beyond standard 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the tool's purpose and key behavioral trait. There is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the comprehensive annotations, complete parameter schema, and presence of an output schema, the description is largely sufficient. It omits details like ordering or default time range, but 'recent' provides adequate context for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description does not add parameter-specific context beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'recent runtime proxy alerts' and specifies that it does not include 'prompts, arguments, or responses,' which precisely defines its output. This distinguishes it from sibling tools like 'proxy_status' or other alert-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention use cases, when to avoid, or suggest other tools for different needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a concrete auth precondition: writes require an authenticated admin operator with `findings:write`. The mention of the same campaign store/verification service also adds context about consistency. This does not contradict the `destructiveHint: true` annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two concise sentences and includes the most critical facts first: what the tool does and who can perform writes. There is no fluff or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich input schema covering all 15 parameters and action descriptions, the overall information is sufficient. The only minor gap is that it does not set all action modes, such as `verification_queue`, in the free-text description, but that is still easily discovered through the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Every parameter in the input schema has its own description, and schema coverage is 100%. The tool description itself does not need to explain parameters, so the text meets the baseline. No extra parameter semantics beyond schema are added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly says 'List, assign, ticket, or verify a tenant-scoped remediation campaign', giving a clear verb list and resource. It does not explicitly show why this tool is better than sibling tools like `remediate` or `verify`, but the campaign workflow scope is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context: the operation is tenant-scoped, reuses the same campaign store/verification service as REST and CLI, and writes require an authenticated admin with `findings:write`. It does not provide explicit 'when to use' or 'when not to use' guidance relative to the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safety. The description adds behavioral detail (e.g., probing DCGM endpoints on port 9400 for unauthenticated metrics leak detection), providing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that succinctly captures the tool's purpose and scope with no wasted words. Front-loaded with the key verb and resource types.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations (readOnly, idempotent, openWorld), an output schema (not shown but noted), and 100% parameter coverage in schema, the description adequately completes the picture. It identifies what the tool discovers without needing to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters already well-described in the input schema (k8s_context for K8s context, probe_dcgm for DCGM probing). The description adds little beyond framing the overall purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Discover' with specific resource types: containers, K8s nodes, and DCGM endpoints. It clearly differentiates from siblings like ai_inventory_scan or scan by focusing on GPU/AI compute infrastructure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for GPU infrastructure discovery but provides no explicit when-to-use or when-not-to-use guidance, nor does it compare to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds that it shows 'all MCP discovery paths and which config files exist', which is consistent but not deeply detailed 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence without any fluff, perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is sufficient. It clearly states what the tool shows, and the context signals confirm no missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4 applies. The description does not need to add parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Show' and resources 'MCP discovery paths' and 'config files', clearly distinguishing it from sibling tools which focus on scanning, auditing, or benchmarking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Even though it has no parameters, the description does not explain context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by disclosing the setup requirement and the potential for empty results when ClickHouse is not configured. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: first for purpose, second for prerequisites and behavior. It is front-loaded and contains no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are likely documented. The description covers prerequisites and a failure mode. Parameter schema thoroughly documents each parameter and its context. Together, these provide sufficient completeness for a query tool. Slight miss: not all query types are explicitly listed in the description, but they are in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter descriptions are detailed (e.g., listing which query types use each parameter). The description does not add significant meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Query' and the resources 'vulnerability trends, posture history, and runtime event summaries from ClickHouse.' This distinguishes it from sibling tools like audit_query or intel_lookup, which query different data sources. The parameter schema further lists all query types, reinforcing specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite ('Requires AGENT_BOM_CLICKHOUSE_URL to be set') and a fallback behavior ('Returns empty results if ClickHouse is not configured'). However, it does not explicitly guide when to use this tool over alternatives such as audit_query or intel_lookup, which also query data but from different sources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, so the description need not restate those. It adds value by specifying the scope (control-plane and runtime), which gives useful 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It is appropriately sized and efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a full schema and an output schema, the description is mostly sufficient. However, it could benefit from clarifying what 'integrity' means (e.g., hash verification) to fully cover the tool's behavior, but it is still above minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents each parameter. The description adds no additional meaning or guidance for parameter usage, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Verify' and clearly identifies the resource 'control-plane and runtime audit chain integrity'. It effectively distinguishes from sibling tools like 'audit_query' which likely queries logs rather than verifying integrity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives (e.g., 'audit_query'). It implicitly suggests it is for integrity checks, but lacks explicit context or exclusions, making it minimally informative for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive, idempotent, and open-world behavior. The description adds value by specifying that the tool returns the graph as a string in the requested format, which is not disclosed by 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a single sentence for purpose, bullet points for formats, and a returns line. It is front-loaded with the main action, and every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of a full schema and annotations, the description covers the essential aspects: purpose, formats, and return type. It is complete enough for the agent to understand and use the tool, though it omits error handling or edge cases (e.g., what happens with invalid format).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 lists the format options but does not add meaning beyond the schema's description of each parameter (e.g., config_path, format, mermaid_limit). The description does not compensate for any missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports the agent dependency graph in specific graph-native formats (graphml, cypher, dot, mermaid, json). The verb 'export' and resource are well-defined, and the listing of formats distinguishes it from other tools like context_graph or scan 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a graph-native format is needed, but it does not explicitly state when to use this tool versus alternatives (e.g., context_graph for other representations) or when not to use it. No exclusions or preconditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses that the tool returns a raw token once, adds requirement context beyond annotations (which show destructive=true), and notes non-idempotent and destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences covering action, prerequisites, and return value; no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and an output schema, description covers prerequisites and output type. Could mention default behaviors but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so description adds minimal extra meaning beyond schema. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action 'Issue a managed agent identity' with specific verb and resource, and distinguishes from sibling tools like identity_revoke and identity_rotate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists prerequisites (admin role, identity:write scope, audit reason) but does not explicitly state when to use this tool over alternatives like identity_grant_jit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds 'local threat-intel database' context, indicating no external fetch. No contradiction. However, it doesn't detail behavior on missing IDs or performance considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured sentence that is front-loaded and free of redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simplicity (1 param, output schema exists, annotations rich), the description is nearly complete. Minor gap: no mention of error handling or edge cases like invalid IDs, but output schema likely covers return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema's parameter description already provides detailed format guidance (e.g., 'CVE-2024-1234 or GHSA-abcd-1234-wxyz'). The tool description adds no new parameter-level information beyond 'one advisory,' so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Look up one advisory from the local threat-intel database.' It specifies a specific verb (look up) and resource (advisory from a local database), distinguishing it from siblings like intel_match which likely handle multiple matches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific advisory ID is known, but lacks explicit guidance on when to use this tool versus alternatives like intel_match or intel_sources. No mention of when not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds that it never returns secret material and explains graceful degradation for disabled providers, providing useful 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the core purpose and add relevant behavioral details without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 comprehensive annotations, the description covers key aspects: what is returned, safety guarantees, and error handling. Could mention pagination or limits but not necessary for this use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds minimal new meaning beyond the schema descriptions. It mentions provider gating but does not elaborate on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers non-human identities (Okta service apps / Entra service principals) with a specific verb and resource. It distinguishes from sibling tools that target different domains or actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage context: read-only, reference-only, and explains provider gating and error handling. However, it does not explicitly state when to use versus alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, non-destructive, and idempotent behavior. The description adds that it runs a scan and evaluates rules, and specifies the return structure (passed, violations, etc.), which is beyond annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with summary, details, and return info, but is slightly verbose. Could be more concise while retaining key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and existence of output schema, the description covers the essential behavior and expected output. However, it lacks details on error handling or edge cases (e.g., invalid policy_json).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds value by providing an illustrative example of the policy_json format and listing supported rule types (severity, KEV, etc.), enhancing understanding beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it evaluates a security policy against current scan results, with a specific verb and resource. It distinguishes from sibling tools like 'compliance' or 'code_scan' by focusing on custom policy rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's purpose but lacks explicit guidance on when to use it versus alternatives like 'check' or 'should_i_deploy'. It provides context on policy components but no when-not statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and idempotent behavior. The description adds important context with 'if a session is active', which is not in 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action and object, no unnecessary words. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (per context signals), the description adequately states what is returned and the key condition. However, it does not mention any time bounds or format, but these may be in the output schema. Slight deduction for lack of guidance on typical usage patterns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description and default for 'tenant_id'. The tool description does not add additional parameter semantics beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return', the resource 'MCP proxy metrics and alert summary', and includes a conditional scope 'if a session is active'. This distinguishes it from sibling tools like 'proxy_alerts' (alerts only) and 'gateway_status' (gateway component).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The implied usage is when proxy metrics and alerts are needed. Given siblings like 'proxy_alerts' and 'gateway_status', some context on differentiation would improve the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds context by specifying 'canonical' blueprints and the design purpose, enhancing transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence of 11 words with no superfluous information. Every word serves a purpose, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (two optional params, output schema present), the description adequately covers the purpose and return type. It could implicitly clarify that omitting blueprint_id returns all blueprints, but this is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 does not add any additional meaning to the parameters beyond what the schema provides, so no upward adjustment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool returns canonical role/profile blueprints for runtime policy design, using a specific verb and resource. It clearly distinguishes from siblings like runtime_blueprint_drift, which focuses on drift detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for runtime policy design but provides no explicit guidance on when to use this tool versus alternatives, such as runtime_blueprint_drift. No exclusions or context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no new behavioral details beyond confirming no state change, which aligns 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and constraint, no redundant words. Optimal for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return values. It sufficiently covers the tool's purpose and constraint for a simple read-only operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the single parameter with full description. The tool description adds no additional semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Return', resource 'Shield assessment for a session', and a key constraint 'without changing enforcement state', distinguishing it from siblings that modify state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies read-only usage by stating 'without changing enforcement state', but does not explicitly compare with sibling tools or 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds valuable behavioral details (required role, scope, audit reason) beyond annotations. Annotations already indicate destructive and non-idempotent, and description aligns without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the key action, no wasted words. Efficiently conveys essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description provides sufficient context. Could mention unblocking only works on blocked sessions, but the overall completeness is good.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description adds no new meaning beyond what the schema already provides for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Unblock Shield enforcement for a session' with explicit required permissions, distinguishing it from siblings like shield_start and shield_break_glass.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides prerequisites (admin role, shield:write scope, audit reason) but does not explicitly say when to use this tool versus alternatives 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is covered structurally. The description adds genuine value by disclosing the external dependency on OSV.dev (an outbound network query) and documenting the JSON return shape. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The key purpose is front-loaded in the first line, followed by a tight context sentence and structured Args/Returns blocks. It earns its length with the OSV.dev source note, usage guidance, and return-format disclosure, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given rich annotations, an output schema, and 100% parameter coverage, the description covers what matters beyond structure: external data source, when to invoke, and expected return fields. The only minor gap is that the offline/version parameters are not surfaced in the description text, though the schema fully documents them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented structurally and the baseline is 3. The description reinforces package/ecosystem with concrete examples but omits the offline and version parameters entirely from its Args section. It adds convenience, not new meaning, on top of the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise 'Check a specific package for known CVEs before installing' — a specific verb, resource, and scoping constraint. It clearly separates this single-package advisory check from broad siblings like scan or registry_lookup by framing it as a targeted, pre-installation safety verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this before installing an MCP server or dependency to verify it is safe' gives an explicit trigger condition and intended moment of use. However, it does not name any alternative tools or state when NOT to use it, leaving an agent to infer the boundary against scan/policy_check/marketplace_check on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'All checks are read-only,' which aligns with the readOnlyHint annotation. It additionally discloses credential requirements and the inclusion of MITRE ATT&CK mappings, providing useful behavioral context beyond the annotations. No contradiction 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear lead sentence followed by a bullet-like enumeration of benchmarks and a return format section. It is informative without excessive verbosity, though the list of check counts could be seen as slightly extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a comprehensive overview of the tool's purpose, the benchmarks it covers, the output format (JSON with pass/fail, evidence, severity, ATT&CK techniques, pass rate), and prerequisites. This is sufficient for an agent to understand expectations without an explicit output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers each parameter with clear descriptions (e.g., provider values, env var fallbacks, check ID format). The description's top-level text does not add significant new parameter information beyond the schema, so it does not exceed the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run CIS benchmark checks against a cloud account' with a specific verb and resource. It distinguishes from sibling tools like 'compliance' or 'policy_check' by explicitly naming CIS Foundations Benchmarks and enumerating provider-specific check counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It states when to use (for CIS benchmark evaluation) and implicitly differentiates from generic compliance checks. It also notes that 'appropriate credentials' are required, which is a prerequisite. It doesn't explicitly list alternatives, but the specificity is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds useful context beyond this: requires semgrep on PATH, returns typed statuses (findings, clean, skipped, failed), and scans for CWE-classified issues. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly written, with the main action front-loaded and each sentence providing useful info: purpose, vulnerability classes, return status, and a key prerequisite. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 100% parameter coverage, the description covers the essential aspects: what the tool does, what it returns (statuses), and a critical dependency. It is complete for guiding invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (path and config) are fully described in the schema (100% coverage), so the description doesn't need to add parameter details. It does not significantly enrich parameter meaning beyond the schema, which is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs SAST via Semgrep on source code and lists specific vulnerability classes (SQL injection, XSS, etc.). It is specific in verb+resource but does not explicitly differentiate from sibling tools like 'scan' or 'check'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for static security scanning of source code and mentions a prerequisite (semgrep on PATH), but it does not provide explicit when-to-use or exclusions relative to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds context on output structure (nodes, edges, lateral_paths) and analysis type, without contradicting annotations. It does not detail permissions or side effects, but annotations already cover safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences), front-loaded with purpose, and well-structured. It efficiently conveys the tool's function, modeled entities, key question, and return fields with no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and that an output schema exists (so return values need not be explained), the description sufficiently covers purpose, usage context, and output structure. It mentions all relevant return fields, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 does not add additional meaning beyond the schema, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds an agent context graph for lateral movement analysis, with a specific verb and resource. It distinguishes from siblings like 'blast_radius' and 'exposure_paths' by focusing on reachability between agents, servers, credentials, tools, and vulnerabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by answering a concrete question, 'If agent X is compromised, what else becomes reachable?' but does not explicitly guide when to use this tool versus alternatives like 'blast_radius' or 'exposure_paths'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable context: spend is derived from token counts on OpenTelemetry spans and no prompts/responses are read, revealing data source and privacy assurances 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first sentence states core purpose, second adds transparency. Information is front-loaded and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 optional parameters, complete annotations, and presence of output schema, the description sufficiently explains the tool's function and computation method. No missing critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds no extra parameter info beyond what the schema provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return LLM spend attribution (per agent/model/provider) and budget posture,' specifying the verb and resource. It distinguishes from sibling tools like cost_allocation (which allocates costs) and cost_forecast (which forecasts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 cost_allocation or cost_forecast. The description lacks explicit when/when-not scenarios or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds specific context about what is scanned (dataset_info.json, README.md frontmatter, .dvc files) and the optional PII scanning. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's core functionality. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with 2 parameters, full schema coverage, and an existing output schema, the description sufficiently covers all necessary aspects: purpose, what is scanned, and optional behavior. It is complete for an agent to use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description repeats the exact parameter descriptions from the schema. It adds no new meaning beyond what the schema already provides, so a baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans a directory for ML dataset card metadata, provenance, and optionally PII/PHI content. It distinguishes from sibling scanning tools by focusing on dataset cards and adding PII scanning, making its purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for dataset directories but provides no explicit guidance on when to use this tool versus alternatives like code_scan or model_file_scan. It does not state when not to use it or compare with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds context about default behavior (open incidents only) and incident contents (blueprint, drift score, top violations), which aids understanding without contradicting 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. First sentence immediately states the action and resource. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with two optional parameters and an output schema, the description fully covers purpose and incident structure. No missing essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with full descriptions. The tool description aligns with the include_resolved default but adds no new meaning beyond the schema. Baseline 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists open blueprint-drift incidents and explains what a drift incident is. The verb 'list' and resource 'blueprint-drift incidents' are specific and distinct from sibling 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for operators reconciling drift but does not explicitly state when to use this tool over alternatives like runtime_blueprint_drift. No exclusions or when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by specifying that the call mutates a durable runtime-evidence store scoped to the authenticated tenant, fails closed on auth, and never writes to a customer cloud target. This gives the agent critical behavioral context (side effects, auth sensitivity, write target) that annotations alone do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the primary action and target appear in the first sentence, followed by three compact clauses covering mutation, provisioning, and auth behavior. No word is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be described. The description covers the key contextual elements: what is mutated, where data goes, how sources are provisioned, and auth failure behavior, which is sufficient for the 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents source_id, secret, and signals_json. The description does not add parameter-level detail beyond the schema, which matches the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action ('Ingest') and resource ('CWPP runtime/EDR workload signals') into an explicit target ('local evidence store'), making the tool's purpose clear. However, it does not distinguish this from sibling ingestion tools like ingest_external_scan or intel_sources; the only differentiation is the resource-specific wording, not an explicit contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a useful prerequisite: sources must be provisioned via AGENT_BOM_RUNTIME_EVIDENCE_SOURCES. It does not state when to prefer this over alternative tools or give any when-not-to-use guidance, so the usage context 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent, and open-world traits. The description adds the methodology (ClawHub-style categories), which is complementary 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no unnecessary words, front-loading the action and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, full schema coverage, and comprehensive annotations, the description adequately covers the purpose and methodology, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the single parameter 'skill_path', including a description. The tool description adds only minor clarification (SCILL.md vs any instruction file), so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it assesses the trust level of a SKILL.md file using ClawHub-style categories, specifying the verb, resource, and methodology, which distinguishes it from sibling tools like skill_scan or skill_verify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for trust assessment of SKILL.md files, but does not provide explicit guidance on when not to use it or suggest alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, so the description's claim of 'surface' and 'proactive detection' aligns and adds context that the tool is analytical and non-destructive. No behavioral details are missing or contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the tool's purpose and output. No extraneous words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no required parameters, output schema exists), the description sufficiently defines purpose and use case. It could optionally mention that results include flagged outliers, but the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already contains clear parameter descriptions ('Z-score threshold...', 'Tenant scope...'). The tool's description does not add any further parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Surface') and clearly identifies the resource ('cost and behavior anomalies'), specifying the kinds of anomalies (per-agent spend, per-session tool-call-rate statistical outliers) and the purpose (proactive runaway-agent detection). This clearly distinguishes it from sibling tools like 'cost_report' or 'tool_risk_assessment'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for proactive detection of runaway agents, but it does not explicitly state when not to use it or provide alternatives. Given the large set of sibling tools, a note on when to prefer this over other scan tools would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable context about scan behavior, return structure, and the notable fact that the nist_800_53_catalog score is independently scored and NOT folded into overall_score. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with Args and Returns sections, front-loaded with purpose. It is somewhat verbose, especially the Returns details, given that a full output schema exists. However, the special NIST 800-53 scoring nuance justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with two optional parameters and an output schema, the description fully explains scope, control mapping, return structure, and the separate NIST score. It leaves no critical gaps for an agent to understand what the tool does and what it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The paragraph text essentially restates schema descriptions (config_path auto-discovers, image is a Docker reference) without adding new semantics or edge-case guidance. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Get OWASP LLM Top 10 / OWASP MCP Top 10 / MITRE ATLAS / NIST AI RMF compliance posture.' It clearly states what it does (scans MCP configurations, maps to 47 controls) and distinguishes itself from sibling tools like scan or cis_benchmark by naming unique frameworks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: scans local MCP configs with optional config_path or image, auto-discovers if omitted. However, it does not explicitly mention when to prefer this tool over alternatives or provide exclusions, 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true. The description adds value by stating that no prompts or responses are read, which is a privacy assurance beyond annotations. It also describes data sourcing (OpenTelemetry GenAI spans) and included outputs, enhancing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four front-loaded sentences. Each sentence adds unique value: main purpose, data source, included outputs, and privacy note – no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 the tool's moderate complexity (4 optional params, LLM cost rollups), the description adequately covers the purpose, data source, and privacy. It does not detail the exact output structure, but the output schema handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description does not add additional semantics beyond what is already in the schema, so it meets the baseline of 3 without enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource 'chargeback / showback LLM spend rollups', specifying the dimensions (cost-center, allocation tag) and included outputs (allocation, budget posture, forecast). It also distinguishes itself from sibling tools like cost_forecast and cost_report by focusing on rollups with budget and forecast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving cost allocation data but does not explicitly compare to alternatives or state when not to use. It provides clear context on what the tool returns, but lacks explicit usage guidance or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations: it confirms the destructive nature (already hinted by destructiveHint=true) and specifies required roles/scopes and audit requirements. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences), front-loads the purpose, and adds prerequisites efficiently. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, destructive annotations, and an output schema, the description covers the core purpose and key requirements. It could mention the temporal nature or return values, but the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description does not add extra explanation beyond the schema, but it is not expected to since the schema already explains each parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Grant' and the resource 'identity time-bound JIT access to one tool', which is specific and distinguishes from sibling tools like identity_revoke (revoke access) and identity_rotate (rotate credentials).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists prerequisites (admin role, identity:write scope, audit reason), which guides usage. It implies when to use (for temporary access) but does not explicitly state when not to use or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms the destructive nature ('immediately') and adds behavioral context about required authentication and audit logging, beyond what annotations (destructiveHint=true) alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence front-loads the action and immediately follows with critical usage requirements. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations, output schema existence, and complete parameter descriptions, the description covers the key aspects. Lacks details on post-revocation state but is adequate for a destructive action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. The description references the purpose of parameters (e.g., 'audit reason') but adds no new semantic detail beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Revoke' and resource 'managed identity', clearly distinguishing it from sibling tools like identity_grant_jit or identity_rotate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states explicit requirements (admin role, identity:write scope, audit reason), providing clear usage context. However, it does not mention 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it notes that the old token stays live during the overlap window, which is critical behavior not captured by the destructiveHint annotation. Requirements are also included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first explains the core action and key behavior, second lists requirements. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high schema coverage and presence of an output schema, the description covers the essential action and requirements. It lacks explicit guidance on when to prefer this over siblings, but the sibling list provides context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no new parameter information beyond referencing the overlap window, which is already described in the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'rotate' and the resource 'managed identity' with a specific behavioral detail about keeping the old token live. This distinguishes it from sibling tools like identity_grant_jit or identity_revoke.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists prerequisites: admin role, identity:write scope, and audit reason. It does not explicitly state when not to use, but the clear prerequisites and context provide sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral details: normalizing 2,500+ SPDX IDs, flagging network-copyleft licenses, and returning verdicts with matched policy. It provides context beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, structured with clear sections, and contains no redundant information. Every sentence serves a purpose: purpose, inputs, behavior, output, and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (license compliance, policy, SPDX normalization) and the presence of annotations and output schema, the description is mostly complete. It covers purpose, inputs, behavior, and output summary. A brief mention of error handling or edge cases would improve completeness, but it is sufficient for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description largely reiterates the schema for scan_json and policy_json, adding minor context about the default policy. Since the schema already does the heavy lifting, the description does not add significant new meaning beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates package licenses against an SPDX compliance policy, specifying the verb 'evaluate' and resource 'package licenses'. It distinguishes from sibling tools like 'scan' by noting it works on prior scan results or explicit arrays and is meant for release/procurement gates without a full scan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use guidance: 'Call this in release or procurement gates to enforce license policy on an agent's dependency set without running a full scan.' It also implies alternatives by referencing the scan tool. However, it does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive behavior. The description adds context about required authorization (admin role, shield:write scope, audit reason), which is valuable for safe invocation. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that covers the key points without unnecessary words. It is front-loaded with the action, then requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with an output schema, the description covers purpose, requirements, and mandatory parameters. It does not detail return values (handled by output schema) and is sufficiently complete for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds minimal new meaning. It mentions admin role and shield:write scope, which align with parameter descriptions but do not exceed them. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run Shield break-glass override'), specifying a distinct verb and resource. It differentiates from sibling tools like shield_start, shield_status, and shield_unblock by focusing on an emergency override scenario.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites (admin role, shield:write scope, audit reason), guiding when to use the tool. However, it does not mention when not to use it or suggest alternatives, such as shield_unblock for non-emergency cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, implying the tool modifies state. The description adds context about administrative requirements and the need for an audit reason, which goes beyond what annotations alone convey. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with maximum efficiency: states action first, then requirements. Every word earns its place, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 6 parameters (all optional), output schema exists (not shown). Description covers prerequisites but omits potential side effects or error conditions. However, annotations and output schema fill some gaps, making it mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema, only clarifying that operator_role must be admin and operator_scopes must include shield:write (already stated in schema descriptions).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Start Shield enforcement for a session,' specifying the verb and resource. It is distinct from sibling tools like shield_status, shield_unblock, and shield_break_glass, which handle different operations on the same resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites: 'Requires admin role, shield:write scope, and audit reason.' This informs the agent of necessary conditions but does not explicitly exclude alternative tools or specify when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds valuable context by stating that an admin operator + ticketing:write scope is required and that auth and endpoint are resolved from the stored connection only. This complements the annotations without contradiction, though it does not detail 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the main action and followed by necessary prerequisites. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, and the description covers the core action and prerequisites. It does not fully explain the refresh behavior or side effects, but the annotations, schema, and output schema fill in the remaining details. Given the tool's simplicity, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 5 parameters, so the schema already provides clear semantics (e.g., ticket_id described as the link id from create_ticket). The description adds no per-parameter details, but the baseline of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Refresh a filed ticket's status from its ITSM through the connection.' This is a specific verb (refresh) + resource (ticket status) and distinguishes the tool from siblings like create_ticket, which creates a ticket rather than updating its status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: it requires an admin operator and ticketing:write scope, and it resolves auth/endpoint from the stored connection only. However, it does not explicitly mention alternatives or when not to use the tool, so it lacks exclusions but still gives useful prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context: the fallback to a local MCP configuration scan, the explicit labeling of that narrower source, and the `found=false` return case. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (~100 words), front-loaded with the primary action, and structured with Args and Returns sections. Every sentence earns its place: the two behavioral notes (persisted vs. local source) and the return format are all useful. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup tool with strong annotations, a 3-param schema at 100% coverage, and an output schema, this description is complete. It covers purpose, two distinct operational modes, parameter requirement (cve_id), and a not-found outcome. The output schema presumably handles return-field details, but the description already gives the key returning fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (cve_id, scan_id, tenant_id) has a description. The description's Args section only restates cve_id syntax ('e.g. CVE-2024-1234 or GHSA-xxxx') without adding new semantics. Per the calibration baseline, 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+scope: 'Look up the blast radius of a specific CVE across your AI agent setup.' It clearly distinguishes this from siblings like exposure_paths and intel_lookup by focusing on CVE-specific blast radius. The two data-source modes (persisted control-plane evidence vs. standalone local scan) are also explicitly described.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear behavioral context: it reads persisted evidence when available and falls back to a local scan in standalone mode, labeling the narrower source explicitly. However, it does not explicitly name alternative tools or say when not to use this tool, so it stops short of a full when/when-not guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant context beyond annotations: opt-in per-provider via env flags, disabled provider behavior, returns only counts and node summary, and assures no resource secrets. Complements readOnlyHint and other annotations effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with first front-loading core purpose, second adding critical behavioral details. No filler, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero required params, high schema coverage, and presence of output schema, the description sufficiently explains tool behavior, return type, and configuration prerequisites. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, so baseline is 3. Description adds minimal additional meaning beyond schema descriptions (providers, region, tenant_id). The env flag opt-in is mentioned but not tied to parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it summarizes estate-wide cloud asset inventory with resource and identity counts, using specific verbs and outlining scope. It distinguishes from siblings like 'inventory' by referencing opt-in env flags and reference-only nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for overview but lacks explicit when-to-use or when-not-to-use compared to siblings like 'inventory' or 'ai_inventory_scan'. Mentions opt-in behavior but no alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint) already indicate safe read behavior. The description adds important context: it never returns secret values, and it specifically handles control-plane secrets. This goes beyond annotations by clarifying what is NOT exposed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the primary purpose concisely, second adds detail without redundancy. Every sentence adds value, and the description is well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and an output schema, the description fully explains the tool's purpose, scope (control-plane secrets), and what it does not return. It is complete for an agent to understand its capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema coverage is 100%. The description appropriately has no need to explain parameters. Baseline score of 4 for no-parameter tools is met.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns expiring/overdue credential posture for control-plane secrets, specifying details like near expiry, overdue for rotation, and an overall verdict. This distinctively differentiates it from sibling tools which cover other security and compliance functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when credential expiry status is needed, but lacks explicit guidance on when to use this tool over alternatives (e.g., access_review, audit_query). No exclusions or context about when not to use it are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description's mention of 'Revoke' aligns. It adds value by specifying authorization requirements (admin role, scope) and the need for an audit reason, which are not covered by 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, efficient and front-loaded with the action and requirements. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 100% schema coverage and existence of an output schema, the description is adequate. It covers the tool's purpose, prerequisites, and required parameters, enabling an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents each parameter. The description adds minimal extra value beyond what the schema provides, justifying a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Revoke' and the resource 'active JIT grant', and specifies immediate action. It clearly differentiates from sibling tools like identity_grant_jit (grant) and identity_revoke (generic revoke) by focusing on JIT grants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions required admin role, identity:write scope, and audit reason, providing clear context for when to use the tool. However, it does not explicitly contrast with alternatives like the generic identity_revoke, but the sibling list helps differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description needn't restate. It adds value by specifying the kind of data returned (canonical sources, freshness), which is transparent 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, information-dense sentence that front-loads the purpose with zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description completely covers the purpose and return value, leaving no ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description has no burden. Baseline 4 is appropriate as the tool is trivially parameter-free.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and names the resource ('canonical threat-intel sources', 'local feed-run freshness'), clearly distinguishing it from siblings like intel_lookup and intel_match.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (getting a catalog), but lacks explicit when-to-use or when-not-to-use guidance relative to alternative tools among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent, non-destructive), the description adds rich context: every collector has an explicit state (executed/skipped/unevaluable/failed), partial runs are reported as 'partial' and cannot be launder into a clean pass, and results reconcile with the REST route and CLI. This is substantial behavioral disclosure not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by distinguishing context and behavioral details. It is longer than average but each sentence contributes meaningful information, and the final 'Returns:' block clearly summarizes outputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, output, and critical behavioral nuances (collector states, partial run handling). While it does not explicitly state required permissions, the mention of 'unevaluable (a denied or absent read)' implies this. The presence of an output schema reduces the need to describe return values, so the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and parameter descriptions are already detailed (e.g., 'Opt in to per-node kubelet /configz collection (CIS section 4.2)'). The tool description does not add significant parameter-level 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'Evaluate live Kubernetes cluster security posture (KSPM)'. It clearly distinguishes itself from image discovery by stating it returns SECURITY POSTURE, not container-image inventory, which differentiates it from sibling 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (live cluster posture against CIS benchmark) and explicitly states what it is NOT (image discovery). However, it does not name alternative sibling tools directly, relying more on exclusion than explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by detailing the return structure (risk_level, verified, etc.) and the behavior when a server is not found (found=false). 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a brief first line, followed by a paragraph, then Args and Returns sections. Every sentence serves a purpose, and the most important information (purpose) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's purpose, parameters, and return format. Given the presence of an output schema, the description could have omitted return details, but it includes them for clarity. It also provides contextual info (109+ servers) and parameter constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description repeats these descriptions in the Args section and adds examples (e.g., 'filesystem', 'mcp-server-sqlite'). This is helpful but does not provide significant additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries a specific registry (agent-bom MCP server threat intelligence) and lists the data fields returned (risk level, tools, credentials, verification). It distinguishes itself from sibling tools like intel_lookup by being focused on MCP server security metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on what to use the tool for (look up MCP server details) and specifies that at least one parameter is required. However, it does not explicitly mention when not to use it or provide alternative tools for similar lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds critical context that no sensitive data (prompts, arguments, credentials) is returned, which is beyond what annotations provide. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the core purpose, second lists included and excluded details. Front-loaded and every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter, full annotations, and an output schema, the description covers all necessary context: purpose, what is summarized, and what is excluded. No gaps for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (tenant_id) with full documentation and 100% coverage. The description adds no additional meaning about the parameter beyond what the schema provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns metadata-only runtime production posture and lists specific aspects like tool-call volume, block rate, policy decisions, etc. It distinguishes itself by emphasizing it does not return prompts, raw arguments, or credential values, which separates it from sibling tools that may return raw data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a summary overview without sensitive data, but does not explicitly state when to use versus alternatives or when not to use. Given many sibling tools, more explicit guidance would help agents decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive and open-world, and the description adds valuable behavior details: it connects to configured MCP clients, calls tools/list at runtime, classifies tools, and requires explicit opt-in before launching discovered stdio server commands. It does not contradict annotations, though it could more directly state the potential side effects of allowing command execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a dense opener, compact Args/Returns sections, and a short usage sentence. Every part earns its place, and the main purpose and key constraint (allow_command_execution) are front-loaded without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations, a rich output schema, and full schema parameter coverage, the description is complete. It explains the runtime behavior, the return shape, the opt-in requirement for potentially destructive command execution, and when to apply it—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.
Parameters3/5Does 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 Args section mostly restates the schema descriptions (config_path, timeout, allow_command_execution) with only slight rephrasing like 'Explicit opt-in required,' which adds minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Live-introspect MCP servers and score each tool's capability risk.' It further defines the mechanism (calls tools/list, classifies by filesystem, network, code execution, credential access) and the resulting per-tool and per-server risk scores, making it clearly distinct from sibling scanning and inventory 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear context for use: 'Use this to assess the blast radius of MCP servers an agent can reach before granting or trusting their tools.' However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of a full when/when-not/alternatives guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds behavioral details such as checking SHA-256/SRI hashes and SLSA provenance attestations, and it describes the return format. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear opening sentence and a bullet-like return description. It efficiently conveys the tool's function and output without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters (one optional), full schema coverage, and an output schema referenced in the description, the description sufficiently explains the tool's behavior and return values. It is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 well. The description adds meaning by mentioning that the package can include a version string (e.g., 'express@4.18.2') and that ecosystems are 'npm' or 'pypi', which aligns with the schema defaults. It also explains the return value structure with hash match and provenance status, adding context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: verifying package integrity and SLSA provenance against registries. It uses specific verbs ('Verify', 'Checks', 'looks up') and mentions the resource (package integrity, SLSA provenance) and scope (npm/PyPI registries). Among siblings, it stands out as a package-specific integrity check versus more general or different scans.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool (verify integrity of npm/PyPI packages) and implicitly excludes other ecosystems or types of verification not related to registries. It does not explicitly mention when not to use or suggest alternatives, but the sibling list includes many other scanning tools, making the context clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that listing/fetching recomputes and persists status, making it an idempotent write—this adds behavioral context beyond the annotations (idempotentHint=true, readOnlyHint=false). It discloses the side effect and distinguishes this from true read-only operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (2-3 sentences) and front-loaded with the core purpose, followed by details on behavior and excluded actions. Every sentence is essential and no extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, annotations, and an output schema, the description adequately covers the primary functions, side effects, and limitations. It is complete enough for an AI agent to use correctly. Could potentially mention required permissions or authentication, but not necessary for core functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 usage pattern (omit campaign_id to list, provide to fetch one) and the effect of the limit parameter, enhancing the semantic understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists or gets NHI access-review campaigns, specifying two modes: listing (omit campaign_id) and fetching one (with campaign_id). The verb and resource are specific and 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.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each mode (with/without campaign_id) and clearly states what the tool does NOT do (creating campaigns or submitting decisions), which helps the agent avoid misuse. However, it does not explicitly name alternative tools for excluded actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false. The description adds context that the audit log is immutable, hash-chained, and that the tool never mutates enforcement state. This enriches the behavioral understanding 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and well-structured, but the Args section is somewhat verbose and repeats schema details. Still clear and logically organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 detailed annotations, the description sufficiently covers purpose, usage, filtering, paging, and pairing with audit_integrity. No gaps for an agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description's Args section mostly repeats schema descriptions without adding new meaning or constraints. Baseline 3 is appropriate as the schema already documents parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads tenant-scoped control-plane audit records with filters and paging, and distinguishes itself from the sibling tool audit_integrity by specifying that it is for reviewing changes while integrity verification is separate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Call this to review who changed what in the control plane; pair with audit_integrity to verify the chain has not been tampered with.' This tells when to use and suggests an alternative for verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint), the description adds that the forecast never blocks and returns null on sparse history, providing valuable 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two paragraphs, ~60 words) and front-loaded with the main purpose, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema covers return values, the description sufficiently explains the forecasting method, behavior on sparse history, and that it is reference-only, making it complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema, which already documents the optional agent and tenant_id parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool projects LLM spend burn rate and budget runway for the active tenant, using specific verbs and resources that distinguish it from siblings like cost_report or cost_allocation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on usage ('Reference only', 'never blocks a call') and mentions behavior on sparse history, but does not explicitly name alternative tools or specify 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only behavior, so the description's 'Writes the same entry as REST POST endpoint' aligns with that. It adds extra transparency by specifying the admin operator requirement, scope, and the justification rule for not_affected, which go 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—three sentences that front-load the purpose, then provide a REST equivalence and requirements. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values don't need explanation. The description covers prerequisites, scoping, and a critical parameter constraint. For a write operation with many parameters, this is adequately complete, though it could elaborate on side effects or idempotency, but annotations partly cover behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has full coverage of all 13 parameters, so the baseline is 3. The description adds meaningful context by clarifying that the entry is tenant-scoped (relevant to tenant_id) and explicitly states the justification requirement for not_affected, tying to a parameter. This goes slightly above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Record a tenant-scoped finding triage decision to the exception store.' This specifies a verb and resource, and the mention of the REST endpoint differentiates it from potential siblings. It is unambiguous about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context by stating the necessary admin operator and findings:write scope, and mandates a justification for not_affected decisions. It does not explicitly name alternative tools, but the prerequisites are clear enough for an agent to know when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 substantial context beyond those flags: every filter and the exact whole-query total are evaluated natively by the graph store, facets are self-excluding and not derived from the displayed page, and findings are excluded. This meaningfully informs how an agent should reason about the call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, each carrying distinct information: core operation, execution semantics, pagination behavior, and content exclusion. There is no filler and no repetition of schema defaults.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 optional parameters, rich schema documentation, and an output schema, the description covers the behavioral aspects that appear nowhere else. It does not mention sibling routing, but that is more a usage-guideline gap than a completeness gap for invoking this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 does not explain individual parameters, but it adds global filter semantics—native evaluation, self-excluding facets, and non-page-derived totals—that are absent from the schema and affect how filters should be combined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource: 'Return a filtered, paginated page of inventory asset rows.' The phrase 'page of rows' distinguishes it from singular inventory_asset and aggregate inventory_summary, and 'Findings never appear in the list' carves out a clear boundary from finding-focused siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the list-and-paginate use case and gives a useful exclusion ('Findings never appear'), but it does not name alternatives or state when to prefer inventory_asset or inventory_summary. No explicit when-to-use/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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavior: scanning for vulnerabilities, generating fix commands (npm install, pip install), credential scope reduction guidance, and reporting unfixable items. Annotations (readOnlyHint=true) align with generating instructions without executing them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, scanning, arguments, returns). It is slightly lengthy but each sentence provides relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 all necessary aspects: scanning, fix generation, optional parameters, and return structure. Together with the input and output schema, the description is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds minimal value beyond the schema. It clarifies behavior for config_path (auto-discovers if omitted) and image, but this is largely repetitive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generating remediation plans for vulnerabilities in AI agent setups. It specifies scanning for vulnerabilities and producing fix commands, distinguishing it from sibling tools that focus on scanning alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (after vulnerabilities are found) and describes the optional parameters (config_path, image). However, it does not explicitly mention when not to use or compare to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context: it distinguishes between output with and without an audit log, and explains the risk-amplified findings. It does not contradict annotations and provides useful behavioral details beyond what annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and uses bullet points for the return value. It is clear and each sentence adds value, though it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 main purpose, required inputs, alternative behavior (without audit log), and output format. It does not reiterate the output schema since one exists, making it sufficiently complete for an agent to understand when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed per-parameter descriptions. The tool description adds further context, such as the OTel trace being used for ML API call provenance, enriching the meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it cross-references vulnerability scan results with proxy runtime audit logs to identify which vulnerable tools were actually called. It uses specific verbs like 'cross-reference', 'identifies', and 'distinguishing confirmed attack surface from theoretical risk', which differentiates it from siblings like ai_inventory_scan or audit_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the requirement for a proxy audit log and explains what happens without it ('returns scan results only'). It also mentions the OTel trace as an optional input. While it does not explicitly list alternatives or when not to use, it provides clear context on prerequisites and fallback behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, and open-world hints. The description adds valuable detail: it resolves against the latest snapshot, ranks ExposurePaths by risk, and maps to a gate decision using thresholds. This explains the algorithm and usage of parameters like scan_id and thresholds.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, detailed Args section, Returns description, and usage note. Every sentence adds value. It is not overly long given the 6 parameters and output explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input parameters, the internal process, and output structure. It explains the return JSON includes decision, risk score, and ranked paths. This is complete for a pre-deployment gate tool with an existing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning: it explains candidate can be a package, resource, CVE, node ID, or deployment label; tenant_id defaults to 'default'; scan_id omitted uses latest snapshot; limit bounds and defaults; warn_risk and block_risk thresholds. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns an allow/warn/block deploy decision based on graph exposure risk. It specifies the verb 'Return', the resource 'deploy decision', and differentiates from sibling tools like exposure_paths or blast_radius by focusing on a pre-deployment gate verdict.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly calls this a 'pre-deployment gate' and recommends using it to get a 'single machine-readable verdict instead of interpreting raw findings.' While it doesn't name specific sibling tools, it provides clear context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly confirms the destructive write behavior, stating it persists the fresh scan and may prune older reports, going beyond the annotations. This adds valuable context about 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence stating purpose, followed by behavioral details and return value summary. Every sentence adds value, and the structure is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (diff with side effects) and the presence of an output schema, the description covers purpose, behavior, side effects, and return type adequately. No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the 'baseline' parameter, and the description clarifies its role and default behavior (if omitted, uses latest saved report). Schema coverage is 100%, so the description adds complementary context without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares a fresh scan against a baseline to find new and resolved vulnerabilities. It distinguishes itself from sibling tools like 'scan' by specifying the diff behavior and the fact it runs a new scan and diffs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (comparing scans to find changes), but does not explicitly state when to use this tool over alternatives like 'scan' or when not to use it. It lacks explicit 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and idempotent behavior. The description adds valuable behavioral context: it explains that risk levels are category-derived (not made-up), that every field is traceable to a source, and describes the return structure. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a succinct first sentence, followed by bullet points explaining design context, then a clear outline of return fields, and finally an explanation of risk derivation. Every sentence serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no nested objects, output schema exists), the description is highly complete. It covers purpose, usage context, input format, return structure, and risk level derivation. The only minor omission is error handling, but the output schema likely addresses that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter ('servers') with 100% coverage. The description adds value by providing examples of valid inputs (e.g., '@modelcontextprotocol/server-filesystem, brave-search') and clarifying that it expects server names without versions. This helps the agent understand the parameter's format and use case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: batch-scanning MCP server names against a security metadata registry. It specifies the target (server names), the source (registry), and the action (batch-scan). It also distinguishes itself from siblings by emphasizing its design for fleet inventory data with no version info, differentiating it from other scan 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Designed for fleet inventory data (EDR, SIEM, CSV exports) where you have server names but not versions.' This provides clear context for usage. It does not explicitly exclude other scenarios or name alternatives, but the guidance is sufficiently informative 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint, idempotentHint, and destructiveHint=false. The description adds that the tool discovers agents and servers, extracts dependencies, and generates a standards-compliant SBOM, which is consistent with read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and uses a clear structure with bullet points for arguments and return. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (mentioned in signals) and two optional parameters, the description provides complete context: what the tool does, how parameters work, and the return format. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters. The description adds value by specifying the exact format values ('cyclonedx' and 'spdx') and clarifying config_path auto-discovery behavior, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a Software Bill of Materials (SBOM) for AI agent setups, with specific details on discovering agents, MCP servers, and extracting dependencies. It distinguishes itself from sibling tools like 'scan' or 'inventory' by focusing on SBOM generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (to generate an SBOM) and explains config_path auto-discovery. However, it does not mention when not to use it or compare to alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe, read-only operation. The description adds behavioral context by specifying that it counts assets from the 'current graph snapshot', lists the specific asset types, and clarifies the exclusion of findings. This adds value beyond the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It starts with a one-line summary, then elaborates on scope and grouping, and ends with exclusion and alternatives. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated), the description does not need to explain return values. It covers the input parameters, the scope of the count, the grouping dimensions, and what is excluded. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters (scan_id and tenant_id). The description does not add significant new semantics beyond what the schema already provides. It mentions 'Omit to use the latest snapshot' but this is also present in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's purpose: returning unified asset-inventory counts by type and source group. It specifies that it counts only non-finding assets and lists the categories (AI, cloud, Snowflake, identity) and grouping methods (OCSF entity type and operator-facing groups). It also distinguishes itself from siblings by explicitly excluding findings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives: 'Findings (CVEs, misconfigurations) are excluded; use blast_radius or exposure_paths for the finding queue.' This clearly specifies the context and exclusion, helping the agent choose appropriately among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by detailing the sources (npm/PyPI, threat intel registry) and the fields returned, expanding on what the agent can expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with a clear one-line summary, followed by a paragraph of detail, then structured Args and Returns sections. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, output schema provided), the description fully covers the purpose, inputs, outputs, and sources. No missing information for an agent to decide whether to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions (100% coverage). The description adds examples ('express', 'langchain') and specifies the default for ecosystem, providing additional clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a pre-install trust check for MCP server packages, querying npm/PyPI and cross-referencing threat intelligence. It distinguishes itself from siblings like 'registry_lookup' by adding trust signals, making the purpose very specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage before installing a package through 'Pre-install trust check', but does not explicitly state when not to use it or provide alternatives. The context is clear enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive, idempotent, and open-world behavior. The description adds value by detailing the walking of directories and static inspection for specific patterns, which goes 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
At approximately 100 words, the description is concise. It is front-loaded with the purpose, followed by args, returns, and usage guidance, with no unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description succinctly describes the return value. The tool is simple (one parameter), and the description covers purpose, behavior, and usage adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'directory' is fully documented in the schema, but the description adds context about the file types scanned (.prompt, system_prompt.*, prompts/), which enriches the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans prompt template files for prompt-injection and unsafe-interpolation risks, specifying the verb 'scan' and the resources (prompt files). It distinguishes itself from sibling tools that focus on code or model scans.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this before shipping or registering agent prompts, and contrasts with package and CVE scans to indicate complementary usage. It provides clear context but does not list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds valuable behavioral context: 'read-only', enumerating, deduplicating by digest, capping, and scanning. This expands beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with action. Every word earns its place; no fluff. Highly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and 7 parameters (1 required), the description explains the core workflow (enumerate, dedupe, cap, scan) and safety (read-only). It is complete enough for an agent to understand scope. The max_images default is in schema. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add meaning specific to parameters (region, profile, etc.) beyond the schema. It explains the overall process but not parameter details, so it stays at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('sweep') and resource ('entire cloud container registry'), with detailed steps: enumerate, dedupe, cap, scan. It clearly distinguishes from sibling tools like 'registry_lookup' (specific image) and 'scan' (general) by targeting full registry sweeping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage for scanning all images in a registry, but does not explicitly state when not to use or suggest alternatives like 'registry_lookup' for individual images. Good context but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly discloses behavior: it snapshots, mounts read-only, records only SBOM and redacted secret metadata, tears down temp resources, resolves credentials via the default chain (no accepted credentials), requires an admin operator, and fails closed on missing extras/credentials. It also notes idempotency key reuse. This significantly exceeds the annotation info (readOnlyHint=false, destructiveHint=true) and adds concrete details about 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct: a one-line summary followed by a detailed but focused paragraph covering critical behavior (snapshot/teardown, metadata-only, fail-closed states, credential handling). It's organized and free of fluff, though the second paragraph is a dense run-on that could benefit from bullet points for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 13 parameters and 100% schema coverage, the description adds essential behavioral context: how the scan works (snapshot, mount, teardown), security constraints (admin role, read-only credentials, never accepts credentials), fail-closed outcomes, and metadata-only secret handling. It also clarifies idempotency via key reuseikuha, covering operational semantics beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema already provides per-parameter descriptions (100% coverage), the description adds context for parameters like idempotency_key (reuses execution record), provider-specific details (location/resource group), and the overall auth model (admin operator). It clarifies the relationship between parameters (e.g., target disk, collector VM) without repeating schema text, adding practical meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's purpose: triggers an agentless Azure/GCP disk side-scan, capturing SBOM and secret metadata only. Its scope is distinctly specified (Azure/GCP, not AWS), and it differentiates from siblings by emphasizing the agentless, read-only, metadata-only nature and the fail-closed honest results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use (triggering a scan, evaluating cloud disk state) and what it does (snapshot, mount, tear down). It lacks explicit 'when NOT to use' or alternatives, but the Azure/GCP scoping and read-only credential requirements are clear. A brief mention of the CLI-side-scan for AWS would be a nice contrast, but it's not critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, it explicitly states the mutation side effects, including bulk-ingesting findings and resolving open findings absent from the batch, and notes the required scope. It also clarifies that parse_only keeps it a read. This is rich 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear one-sentence summary, followed by a focused paragraph on behavior. Every sentence conveys necessary information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return values. It covers core aspects: accepted formats, non-execution, write gating, authentication scope, and the read-only parse_only path. This is sufficient for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents parameters. The description adds meaning by explaining the behavior implied by parse_only (read vs. write) and reconcile_absent (resolving absent findings), which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Ingest') and resource ('external SARIF, SBOM, or scanner JSON'), and the phrase 'without executing its producer' distinguishes it from scanning tools. This clearly differentiates it from siblings like 'scan' and 'generate_sbom'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the conditional write behavior ('mutates the control plane when parse_only is false') and notes the destructive-action gating with findings:write scope. However, it does not explicitly name alternative tools or provide direct 'use when vs. instead of' guidance, 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint false), the description discloses returning a clean not-found error for missing asset IDs and reuses graph store context. This adds behavioral detail without contradicting 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the primary purpose, then add context on behavior and error handling. Every word earns its place, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 params, one required), rich annotations, and output schema, the description covers purpose, behavior, error handling, and reuse context. No missing information for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents parameters. The description adds value by explaining the overall output (e.g., attributes, relationships, blast-radius impact) and error handling, complementing the schema without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns one asset's attributes, relationships, and blast-radius impact, using a specific verb ('Return') and resource ('one asset'). This distinguishes it from siblings like inventory_list (list) and blast_radius (separate tool), as it provides a combined detail view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting a single asset and mentions reusing the graph store node context like the dashboard drawer, giving clear context. However, it lacks explicit guidance on when not to use it or alternatives, such as for batch queries or separate blast radius analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, destructiveHint), the description adds crucial behavioral detail: 'Scanning is fully static and read-only — repository and image contents are parsed, never executed.' It also discloses that repos are shallow-cloned into a temporary directory, scanned, and deleted. This goes well beyond the annotations and reassures an agent about 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening line, bulleted target options, a compact summary of the scan process, and a Returns section. Every sentence earns its place; there is no filler. The front-loaded purpose and scannable list make it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 18 parameters and a rich output schema, the description is remarkably complete. It covers all target types, the scanning methodology, the static/read-only safety guarantee, and the return format. The existence of an output schema means the description need not detail the JSON structure. The description leaves no critical gap for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents each parameter with rich descriptions. The tool description adds value by explaining how parameters interact (e.g., package requires ecosystem when no launcher is named) and the auto-discovery behavior when no target is given. This contextual information helps an agent choose parameters correctly without re-reading the schema, though it doesn't describe individual parameters' formats or defaults beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Run a full AI supply chain security scan and return an AI-BOM.' It then enumerates the distinct target types (repo_url, config_path, image, sbom_path, package) and outlines what the scan does (extract dependencies, query OSV, assess config, compute blast radius). This clearly distinguishes it from siblings like skill_scan or vector_db_scan, which target narrower scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on how to select a target: 'Point it at a target with one of...' and explains the auto-discovery fallback when none is provided. It also clarifies the pairings of package with ecosystem and the mutual exclusivity of config_path and repo_url. However, it does not explicitly name alternative tools or state when not to use this tool versus siblings, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/msaad00/agent-bom'
If you have feedback or need assistance with the MCP directory API, please join our Discord server