GuardRail MCP v2.0 is a hybrid multi-language security analysis server for scanning source code, infrastructure-as-code, dependencies, and containers for secrets, vulnerabilities, and misconfigurations — with enterprise features like RBAC, policy gates, and audit logging.
Core Security Scanning
audit_code_safety – Multi-engine scan (secrets regex, Python AST + taint, tree-sitter, custom rules) returning redacted issues, risk scores, and verdicts
audit_infra_security – IaC misconfiguration detection with optional budget gate on estimated monthly cloud spend
audit_container_config – Security heuristics for Dockerfile/Kubernetes configs
audit_cloud_cost – Rough AWS/GCP monthly cost estimates from IaC text
Repository & Git Scanning
scan_repository – Recursive parallel repo scan with optional incremental caching (up to 2000 files)
scan_git_diff – Scan only files changed in a git range or staged changes
Dependency & Supply Chain
scan_dependencies – Dependency inventory with optional OSV CVE queries, pip audit, or npm audit
generate_sbom – Generate CycloneDX and/or SPDX SBOM JSON
Reporting & Export
export_sarif – Convert findings to SARIF 2.1.0 JSON
suggest_fixes – Template or LLM-assisted fix drafts (never auto-applied)
security_score – Compute a security score/grade from an issues list with optional history recording
compliance_report – Generate lightweight compliance evidence reports for auditors
full_pipeline – Combined repo/diff scan + dependency check + fix suggestions + SARIF + SBOM in one call
Engine & Plugin Management
engine_status – Report hybrid engine capabilities (supported languages, active plugins)
list_plugins – List loaded plugins and custom rule counts
History & Dashboard
scan_history – Retrieve recent scan history from local SQLite storage
Enterprise Features
enterprise_health – Check health, metrics, and non-secret config status
enterprise_policy_status – View active policy packs and gate thresholds for the calling tenant
evaluate_policy – Run a policy pack evaluation against a prior scan result
list_audit_events – List recent in-memory audit events (operator+ role required)
issue_access_token – Issue short-lived JWTs for RBAC roles (admin only)
reload_enterprise_config – Reload enterprise YAML/JSON config from disk (admin)
manage_tenant – Inspect or update in-memory tenant quota counters (admin)
Provides tools for auditing container configurations and security checks for Docker and Kubernetes deployments.
Allows scanning of git diffs and repositories for security vulnerabilities.
Integrates with GitHub code scanning by uploading SARIF results and can be run in GitHub Actions CI.
Exposes metrics in Prometheus format for monitoring the MCP server.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@GuardRail MCP v2.0 (Enterprise) scan my repository for security vulnerabilities and generate SARIF report"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
GuardRail exposes tools that scan source and infrastructure text for high-signal issues (secrets, dangerous APIs, injection patterns, IaC misconfigurations), with optional tree-sitter structural checks, dependency inventory/OSV, SARIF/SBOM export, and an enterprise policy gateway.
Resource | URL |
Website | |
MCPize listing | |
Accuracy policy | |
Security / threat model | |
Examples | |
Performance | |
Test results | |
Enterprise |
Does: static analysis of text you provide; redacts many secret-shaped substrings in excerpts.
Does not: execute scanned code; replace commercial SAST/DAST; guarantee zero false positives/negatives; provide SOC2 certification by itself.
Website playground: browser-only demonstration (docs/ACCURACY.md). Production use = Python MCP/CLI.
Related MCP server: Spotter-SAST
git clone https://github.com/SECRET4422/guardrail-mcp.git
cd guardrail-mcp
pip install -r requirements.txt
export PYTHONPATH=$PWD
python -m unittest discover -s tests -v
python -m guardrail --mode stdio{
"mcpServers": {
"guardrail": {
"command": "python",
"args": ["-m", "guardrail", "--mode", "stdio"],
"cwd": "/absolute/path/to/guardrail-mcp",
"env": { "PYTHONPATH": "/absolute/path/to/guardrail-mcp" }
}
}
}python - <<'PY'
from pathlib import Path
from guardrail.hybrid_scan import hybrid_scan
r = hybrid_scan(
Path("examples/vulnerable_sample.py").read_text(encoding="utf-8"),
filename="examples/vulnerable_sample.py",
)
print(r["status"], r["security_verdict"], r["issue_count"], r.get("engines"))
PYexamples/ contains intentional insecure fixtures for tests and demos only (labeled in-file). Values are synthetic.
Area | Implementation |
Secrets / high-signal patterns |
|
Python AST + multi-hop taint |
|
Tree-sitter (optional grammars) |
|
Repo / git-diff scan |
|
Dependencies / OSV |
|
SARIF / SBOM |
|
Enterprise auth, RBAC, policy |
|
Custom rules / plugins |
|
PYTHONPATH=$PWD python -m unittest discover -s tests -vPublished summary: docs/test-results.md (reproduce with the command above).
Indicative micro-benchmarks are in docs/PERFORMANCE.md and benchmarks/. Re-run on your machine before relying on numbers.
Optional multi-tenant gateway (API keys/JWT, RBAC, path sandbox, audit, rate limits). See docs/ENTERPRISE.md. Do not deploy HTTP enterprise mode without authentication.
Optional commercial listing: mcpize.com/mcp/guardrail.
Self-hosting the MIT core remains free. Pricing on MCPize is set in that marketplace dashboard.
Threat model: docs/SECURITY_MODEL.md
Vulnerability reporting: SECURITY.md
Claims policy: docs/ACCURACY.md
MIT — LICENSE.
Rough AWS/GCP monthly SKU catalog estimate from IaC text.
| Name | Required | Description | Default |
|---|---|---|---|
| cloud_provider | Yes | ||
| infrastructure_content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions 'rough estimate' but does not explain computation, data sources, limitations, or whether the operation has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. Key information is missing, making it under-specified rather than efficiently communicated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool estimating cloud costs from IaC, the description is incomplete. It lacks explanation of output, accuracy, input requirements, and does not leverage the schema or provide expected return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on the two parameters. It alludes to 'from IaC text' but provides no detail on expected format, constraints, or how the cloud_provider enum affects the estimate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a rough monthly SKU catalog estimate for AWS or GCP from IaC text, using specific verbs and resources. It distinguishes from sibling tools focused on security, compliance, and scanning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives is provided. The description only mentions 'from IaC text' but does not specify prerequisites, exclusions, or comparison to other audit tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hybrid multi-engine scan: secrets regex, Python AST + advanced multi-hop taint, tree-sitter structural sinks, language grids, custom rules/plugins. Returns redacted issues, engines used, risk score, security_verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| hybrid | No | Use full hybrid engine (recommended). | |
| use_ast | No | ||
| filename | No | ||
| language | No | ||
| tenant_id | No | ||
| use_taint | No | ||
| source_code | Yes | ||
| use_plugins | No | ||
| use_treesitter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description bears full burden. It explains the multi-engine approach and that results are redacted, which is a behavioral trait. However, it does not disclose whether the tool is read-only, error behavior, or potential side effects. Some transparency but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that efficiently conveys the core purpose, engine types, and return structure. No unnecessary words; every part earns its place. Front-loaded with 'Hybrid multi-engine scan'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but description lists return values (redacted issues, engines, risk score, security_verdict). However, with 9 parameters and many undocumented, the description does not explain how parameters like language or filename affect scanning, nor clarify single-file vs repo-level scanning compared to siblings like scan_repository.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (11%), only 'hybrid' has a description. The description indirectly explains boolean parameters like use_ast, use_taint, use_plugins, use_treesitter by mentioning those engines. However, it does not describe filename, language, tenant_id, or how source_code is used beyond being required. Adds some meaning but not fully compensating.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a 'Hybrid multi-engine scan' for security issues in source code, listing specific engines (secrets regex, Python AST taint, tree-sitter sinks, language grids, custom plugins) and return values. This differentiates it from sibling tools like scan_repository (repo-level) and audit_cloud_cost (cost-related).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Does not mention prerequisites, when not to use, or contrast with siblings like scan_dependencies or scan_git_diff. Usage context is only implied by the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dockerfile / Kubernetes security heuristics.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| filename | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'security heuristics' without disclosing whether the tool is read-only, requires permissions, or has side effects. Fails to inform agent about behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (5 words), but at the cost of missing essential information. Not every sentence earns its place because the single phrase is too vague to be useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and two parameters undocumented, the description is completely inadequate for an agent to understand tool behavior or return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds no meaning to the two parameters (content, filename). Agent has no guidance on what they represent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description is 'Dockerfile / Kubernetes security heuristics.' It indicates the tool evaluates security for container configs but lacks a verb specifying the action. It distinguishes from siblings like audit_infra_security via container focus, but is vague without explicit action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like audit_infra_security or evaluate_policy. The description implies it's for container security, but no exclusion or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
IaC misconfigs + budget gate on estimated monthly burn.
| Name | Required | Description | Default |
|---|---|---|---|
| cloud_provider | No | aws | |
| budget_limit_usd | No | ||
| infrastructure_content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions checking misconfigurations and a budget gate, but does not specify whether the tool is read-only, if it modifies resources, what authorization is needed, or how results are returned. The term 'budget gate' is ambiguous—does it block or just report? More detail is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which can be a positive for conciseness, but it is a fragment lacking verbs and structure. It could be rephrased as a clear sentence, e.g., 'Audit IaC for security misconfigurations and enforce a budget limit on estimated monthly cost.' The current brevity sacrifices clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and no annotations. The description is insufficient to understand the full scope and behavior. For a security audit tool, it should detail what types of misconfigurations are detected, how the budget gate works, and what the output contains. The current description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate by explaining key parameters. It alludes to 'budget gate' (likely budget_limit_usd) and 'IaC misconfigs' (infrastructure_content), but does not describe cloud_provider or the format of infrastructure_content. Users are left guessing about required input expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'IaC misconfigs + budget gate on estimated monthly burn' provides a general idea of the tool's function: auditing infrastructure-as-code for security misconfigurations and checking estimated costs against a budget. However, it is vague and does not clearly distinguish from sibling tools like audit_cloud_cost (cost audit) or audit_code_safety (code safety). A more precise verb and resource specification would improve clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Given sibling tools that also perform audits (e.g., audit_cloud_cost, audit_code_safety), the description should explicitly state the context for using this tool, such as 'Use for security posture assessment of IaC with cost gates.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a lightweight compliance evidence report for auditors.
| Name | Required | Description | Default |
|---|---|---|---|
| frameworks | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior but only labels it 'lightweight' without explaining implications. It doesn't state side effects, permissions needed, or whether it's read-only, leaving agents uncertain about its impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence, making it concise. However, it is too terse and omits critical information, so it does not achieve effective brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and no annotations, the description is severely incomplete. It fails to explain return format, error conditions, or how frameworks are used, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the single parameter 'frameworks'. It does not explain what values are valid, how they affect the report, or provide examples, despite 0% schema coverage requiring compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a compliance evidence report for auditors, using a specific verb and resource. However, it lacks details that differentiate it from sibling audit tools like audit_infra_security, which might also produce reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention prerequisites, context, or exclusions for using the compliance_report tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report hybrid engine capabilities (tree-sitter langs, plugins, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It indicates a read-only report, but does not disclose any additional behavioral traits such as authentication requirements, side effects, or data freshness. For a simple zero-parameter tool, this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the verb and resource, efficiently conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and no output schema, the description is vague with 'etc.' and does not hint at the return format or structure. For a tool that simply reports capabilities, more detail on what exactly is reported would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to add parameter semantics. Baseline is 4, and the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports hybrid engine capabilities with examples (tree-sitter langs, plugins). It is specific about the resource and action, but lacks explicit differentiation from sibling tools like list_plugins or scan_repository.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Given 22 sibling tools, the description should indicate scenarios or exclusions to help the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enterprise health, metrics, and non-secret config status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It implies a read-only operation but does not explicitly confirm safety, permissions, or side effects. Behavioral traits like response structure or data scope are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with key concepts. It is efficiently written but could add useful details without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and many sibling tools, the description fails to explain what the tool returns or how it fits into the broader toolset. It lacks completeness for an agent to understand its role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, achieving 100% schema coverage. Per guidelines, the baseline score is 4. The description adds minimal meaning but is not required to explain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions 'enterprise health, metrics, and non-secret config status,' which indicates the tool provides health and status information. However, it lacks a specific verb (e.g., 'get', 'retrieve') and does not clearly differentiate from sibling tools like enterprise_policy_status or engine_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not specify prerequisites, contexts, or exclusions, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show active policy pack and gate thresholds for the caller tenant.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description implies a read-only operation ('Show') but lacks any disclosure of required permissions, side effects, or limitations (e.g., rate limits, caching). The scope 'for the caller tenant' adds some context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action, no wasted words. The description is appropriately sized for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status tool with no parameters and no output schema, the description covers the basic purpose. However, it lacks information about output format or behavior (e.g., whether it returns all thresholds or active ones), which could help an agent interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%. The description implicitly explains this by stating it operates on the caller tenant, which eliminates the need for explicit parameters. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Show') and identifies the specific resource ('active policy pack and gate thresholds') and scope ('for the caller tenant'). It is distinct enough from sibling tools like evaluate_policy and compliance_report, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like evaluate_policy or compliance_report. The description states only the basic functionality, leaving the agent to infer its appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run policy pack evaluation against a prior scan result object.
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes | ||
| policy_pack | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It only states the action and input, but does not mention side effects (e.g., if it modifies state), required permissions, failure modes, or return values. This is insufficient for an agent to safely invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with only 9 words, making it very concise. It is front-loaded with the core action. However, it could benefit from slight restructuring to include key details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters (one nested object with no details), no output schema, and no annotations, the description is too brief to be complete. It does not explain what the evaluation produces, how to interpret results, or any constraints, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds minimal value beyond parameter names by mentioning 'policy pack evaluation' and 'prior scan result', but does not explain the structure of the 'result' object, the format of 'policy_pack' string, or provide examples. The required parameter is an object with no further description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run policy pack evaluation') and the resource ('against a prior scan result object'). It distinguishes from sibling tools by specifying the use of a prior scan result, which is unique among the listed tools. However, it could be more precise about what 'policy pack evaluation' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or any comparisons to sibling tools like compliance_report or audit_infra_security.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert issues to SARIF 2.1.0 JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| issues | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It only states the conversion function without disclosing side effects, authorization needs, or whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded with the key action. However, it is too brief to be maximally helpful, lacking necessary details for effective use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema and no output schema or annotations, the description should still explain the input format and output characteristics. It fails to provide sufficient context for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the 'issues' parameter—its expected format, structure, or constraints. The parameter is an array of objects with no further detail, leaving the agent without essential input guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Convert' and the resource 'issues' to a specific output format 'SARIF 2.1.0 JSON'. It distinguishes from sibling tools which are focused on auditing, scanning, and compliance, not format conversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Repo/diff scan + deps + fixes + SARIF + SBOM.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | HEAD~1 | |
| head | No | HEAD | |
| mode | No | repo | |
| path | Yes | ||
| sbom_format | No | ||
| use_network | No | ||
| include_deps | No | ||
| include_fixes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description provides no behavioral traits (e.g., read-only, destructive, side effects). The tool combines multiple operations but offers no insight into their interactions or implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While very short, the description sacrifices clarity for brevity. It is a list of features rather than a coherent statement of purpose, and it lacks front-loading of the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count, lack of output schema, and many sibling tools, the description is severely incomplete. It fails to equip an AI agent with enough information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, and the description does not mention any parameter or clarify how the 8 parameters affect behavior. This adds no value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Repo/diff scan + deps + fixes + SARIF + SBOM' lists features but lacks a clear verb and resource. It does not differentiate from sibling tools like scan_repository, scan_git_diff, or generate_sbom, leaving its primary purpose ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. With many sibling tools covering individual capabilities, the lack of usage context is a critical omission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate CycloneDX and/or SPDX SBOM JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| format | No | cyclonedx |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose behavioral traits such as read/write nature, permissions needed, or side effects. For a tool with no annotations, the description should provide more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but under-specified. It lacks structured breakdown of parameters or behavior, which is expected for a tool with multiple parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 0% schema coverage, no annotations, and no output schema, the description fails to provide essential context like what an SBOM is, how the path is used, or what the returned JSON contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% meaning description adds no explanation of parameters. It does not mention 'path' or 'format' or their meanings, leaving the agent to rely solely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it generates SBOM in CycloneDX and/or SPDX JSON format. The verb and resource are specific, and it distinguishes from sibling tools 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like scan_dependencies or suggest_fixes. Lacks context on typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Issue a short-lived JWT (admin). Requires GUARDRAIL_JWT_SECRET.
| Name | Required | Description | Default |
|---|---|---|---|
| role | Yes | ||
| subject | Yes | ||
| tenant_id | Yes | ||
| ttl_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full burden. It states it issues a JWT (write operation) and notes it is short-lived, but lacks details on side effects, error handling, or latency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) and front-loaded with the action, but it is under-specified and lacks structure for a tool with four parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and zero parameter coverage, the description is insufficient. It fails to explain return values, parameter roles, or invite further clarity for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides no information about the four parameters (role, subject, tenant_id, ttl_seconds), leaving the agent to infer their meaning from names only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool issues a short-lived JWT and is for admin use. However, it does not differentiate from sibling tools, though siblings are all audit/scan tools so distinction is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Only mentions a prerequisite (GUARDRAIL_JWT_SECRET) but provides no guidance on when to use this tool versus alternatives or any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent in-memory audit events (operator+).
| Name | Required | Description | Default |
|---|---|---|---|
| tool | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only says 'list' implying read-only, but no explicit disclosure of behavioral traits like auth needs or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise single sentence with no wasted words, but it is under-specified, lacking necessary detail for effective use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and minimal description, the tool definition is highly incomplete. Lacks details on what constitutes an audit event, return format, or parameter constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain the 'tool' or 'limit' parameters, providing no added value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists recent in-memory audit events, but the '(operator+)' qualifier is ambiguous. Distinguishes from sibling audit tools by specifying 'in-memory', but does not fully clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List loaded plugins and custom rule counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions 'list' which implies reading, but does not explicitly state it's read-only, safe, or discuss authentication requirements. For a tool with no annotations, this is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action and outputs. It is concise and front-loaded, with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description covers the essential information. It could mention that it is a read-only operation, but the absence of that is minor. Overall, it is sufficiently complete for its low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100% (vacuous). The description adds no parameter information but is not required to. With zero parameters, the baseline is 4, and the description correctly avoids extraneous detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'loaded plugins and custom rule counts', specifying both the resource and the data provided. It is distinguishable from sibling tools like 'list_audit_events' or various audit/scan tools, but could be more specific about the context (e.g., plugins for rule engine).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The usage is implied as a simple listing, but no exclusions or comparative context are provided. Since it's a straightforward list, a score of 3 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect or update in-memory tenant quota counters (admin).
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| tenant_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior; it reveals 'in-memory' and 'admin' but does not explain side effects of reset_quota 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states purpose, but it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and incomplete parameter documentation, the description leaves gaps about return values and operational context, making it insufficient for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters; 'action' enum and 'tenant_id' are left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as managing tenant quota counters with actions to inspect or update, and distinguishes it from sibling audit/compliance tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks guidance on when to use this tool versus alternatives; it only notes admin scope without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reload enterprise YAML/JSON from disk (admin).
| Name | Required | Description | Default |
|---|---|---|---|
| path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states action and source but omits side effects (e.g., config overwrite, service disruption) or required permissions beyond 'admin'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise single sentence, but under-specification reduces value. Could add parameter context without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotation, single param unexplained. Reloading config is a significant action requiring more context (side effects, prerequisites).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage and description fails to explain the 'path' parameter. No hint on format, required/optional, or what it specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Reload' and resource 'enterprise config' with qualifiers 'YAML/JSON from disk (admin)'. Distinct from sibling tools which are audit, scan, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Only '(admin)' hints at usage, no explicit when-to-use or alternatives provided. Agent has no guidance on when to reload vs other management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dependency inventory + optional OSV CVE query.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| use_network | No | ||
| run_npm_audit | No | ||
| run_pip_audit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. Only implies network usage via 'optional OSV CVE query' but doesn't state read-only, destructive potential, or output characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short (6 words) but at expense of necessary detail. Lacks structure and valuable content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no annotations, and no output schema, description is severely incomplete. Agent cannot determine return format, side effects, or parameter dependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description does not explain any parameter. 'optional OSV CVE query' hints at 'use_network' but does not clarify 'path', 'run_npm_audit', or 'run_pip_audit'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses noun phrase 'Dependency inventory + optional OSV CVE query' which indicates function but lacks a clear verb. It doesn't differentiate from siblings like 'generate_sbom' or 'scan_repository'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No when-not-to-use or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan only files changed in a git range (PR/diff) or staged changes.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | HEAD~1 | |
| head | No | HEAD | |
| path | Yes | ||
| staged | No | ||
| use_ast | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the scope (changed files) but does not explain what 'scan' entails (e.g., security scanning, linting), whether it is read-only, what side effects exist, or what output is produced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 12-word sentence, highly concise, front-loading the core purpose. No unnecessary words or redundancies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description is incomplete. It lacks details on what scanning does, how results are returned, prerequisites (e.g., git repository needed), and parameter specifics beyond inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It indirectly explains 'base', 'head', and 'staged' by mentioning git range and staged changes, but it does not explain 'path' or 'use_ast' (both critical for usage). The required parameter 'path' is not clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans only files changed in a git range or staged changes. It uses a specific verb-resource pair and distinguishes itself from sibling tools like 'scan_repository' by focusing on diff rather than whole repository.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (for changed files in a PR/diff or staged changes) but does not explicitly state when not to use it or provide alternatives among sibling tools. There is no exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return recent dashboard scan history from local SQLite.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| tenant_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as whether it is a read operation, potential performance impact, or what defines 'recent'. Barely adds beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 8 words, front-loaded and no waste. However, it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks details on output, scope of 'recent', how limit and tenant_id affect results, and any example usage. Incomplete for an agent to invoke correctly without further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on the two parameters (limit, tenant_id). The agent gets no extra meaning beyond the schema's type/default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return', resource 'dashboard scan history', and source 'local SQLite'. It distinguishes from sibling tools like audit_cloud_cost or scan_repository by focusing on dashboard scan history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Lacks any mention of prerequisites, frequency, or context for invoking this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parallel recursive repo scan with optional incremental cache.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| use_ast | No | ||
| workers | No | ||
| max_files | No | ||
| incremental | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions 'parallel' and 'optional incremental cache', hinting at performance and caching behavior, but lacks details on side effects (e.g., read-only), error handling, or resource impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. It is front-loaded with the action and key features. However, it could be expanded to cover critical parameters without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters with no schema descriptions and no output schema, the description is insufficient. It omits return values, default behaviors, and error conditions. More detail is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist. The description does not explain any of the five parameters (path, use_ast, workers, max_files, incremental), failing to add meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a 'parallel recursive repo scan' with optional incremental cache. The verb 'scan' and resource 'repository' are specific. Among sibling tools like scan_dependencies and scan_git_diff, it uniquely identifies itself as a recursive repository scan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like scan_dependencies or scan_history. No prerequisites, intended scenarios, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute security score/grade from an issues list and optionally record history.
| Name | Required | Description | Default |
|---|---|---|---|
| issues | Yes | ||
| record | No | ||
| tenant_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states it computes and optionally records history, but does not mention if it is read-only, whether recording history modifies state, or any auth requirements. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. It is appropriately sized for a simple tool, but lacks front-loading of key details. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no output schema, no annotations), the description is incomplete. It does not specify the return format (score range/grade scale), prerequisites for the issues array, or what 'record history' entails. The agent would need additional documentation to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameter. 'issues list' is vague; no details on expected object structure. 'record' and 'tenant_id' are not mentioned. The description adds no value beyond the schema for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes a security score from an issues list and optionally records history. The verb 'compute' and resource 'security score/grade' are specific. However, it does not differentiate from siblings like evaluate_policy or audit_infra_security, which also deal with security metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description implies usage when an issues list is available, but lacks explicit context or exclusions. An agent would not know if this is preferred over scan_repository or evaluate_policy for scoring.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Template or LLM-assisted fix drafts for findings (never auto-applied).
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| limit | No | ||
| issues | Yes | ||
| use_llm | No | Requires GUARDRAIL_LLM_API_KEY |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It only discloses that fixes are never auto-applied, but omits other traits like read-only nature, side effects, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded with the critical constraint (never auto-applied). No wasted words, though additional structure could improve scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters and no output schema, the description lacks context about return values, how results are structured, and how parameters like path or limit affect behavior. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (25%). Only 'use_llm' has a description that adds value (requires an API key). Other parameters (path, limit, issues) are left to schema defaults with no extra context in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it drafts fixes for findings and specifies they are never auto-applied. It distinguishes this tool from scanning/audit siblings by focusing on remediation. However, it lacks an explicit verb-resource structure like 'Suggest fixes for findings.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No prerequisites, exclusions, or context for when to invoke it are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.1.0audit_cloud_costaudit_code_safetyaudit_container_configaudit_infra_securitycompliance_reportengine_statusenterprise_healthenterprise_policy_statusevaluate_policyexport_sariffull_pipelinegenerate_sbomissue_access_tokenlist_audit_eventslist_pluginsmanage_tenantreload_enterprise_configscan_dependenciesscan_git_diffscan_historyscan_repositorysecurity_scoresuggest_fixesScored across 23 tools
Each tool has a distinct domain (cloud cost, code safety, container, infra, compliance, etc.), but some overlap exists between audit functions (e.g., audit_code_safety vs. audit_infra_security) which could cause confusion. Descriptions are clear enough to differentiate in most cases.
Most tools follow a consistent verb_noun pattern with underscores (e.g., audit_cloud_cost, scan_repository). A few tools like 'full_pipeline' and 'enterprise_health' break the pattern but are still readable. Overall consistent.
23 tools is on the high side for a single server, but each serves a specific purpose in a comprehensive security scanning and management suite. The count feels justified given the breadth of functionality.
The tool set covers scanning, auditing, compliance, reporting, policy management, and admin tasks. Minor gaps exist (e.g., no tool to delete scan history or manage users beyond tenants), but core workflows are complete.
MCP gateway with runtime security policy, tool-call-level control, and audit of agent actions.
An MCP server that provides Javelin Standalone Guardrails
The Box MCP server is a secure gateway that connects external AI agents to enterprise content stored in Box, enabling agent-based document access, advanced search, and multi-file analysis while preserving Box security policies. It provides capabilities including keyword search, Box AI-powered Q&A across files, metadata extraction, file management, and authentication, all validated against Box's granular permission controls. The server integrates with major AI platforms like Anthropic Claude, Microsoft Copilot Studio, and Mistral Le Chat, and is available both as a Box-hosted remote server and a self-hosted open-source Python project.
AgentGuard — 20-tool AI safety MCP: policy preflight, risk scoring, audit logging, rate limits.
