What can you do with this server?

The RAD Security MCP Server provides AI-powered security insights and management for Kubernetes and cloud environments. Core Capabilities: * Container Security: List and search containers with filtering, analyze process trees and runtime behavior, get runtime baselines, and perform LLM-powered analysis of container behavior * Kubernetes Management: List clusters and resources (pods, deployments, services, etc.), inspect resource manifests, and detect misconfigurations with policy listings * Identity & Access Management: List identities (service accounts, users, groups) across clusters, get identity details, and audit pod shell access logs * Cloud Security: Inventory cloud resources across AWS, GCP, Azure, and Linode with compliance monitoring and filtering by type, account, and status * Image Security: List container images, retrieve SBOMs, analyze vulnerabilities filtered by severity, and identify top vulnerable images * Network Security: Monitor HTTP requests with PII detection, track network connections between workloads, and analyze connection patterns * Threat Detection: List and analyze threat vectors with filtering by namespace, cluster, resource, severity, type, and status * Security Findings Management: List findings (misconfigurations, threats, runtime alerts, audit anomalies) and update their status (open, closed, ignored) * CVE Database: Search CVEs by vendor/product, view detailed CVE information, list vendors and products, and access the latest 30 CVEs with CAPEC, CWE, and CPE expansions * Inbox Management: List inbox items with flexible filtering, get item details, and mark items as false positives with reasons Customization: Filter toolkits using INCLUDE_TOOLKITS or EXCLUDE_TOOLKITS environment variables across 15 toolkit categories, with multiple deployment options (npm, Docker with Streamable HTTP or SSE). Note: Authentication with RAD_SECURITY credentials is required for most operations, except CVE database access and misconfiguration policy listing.

Which integrations are available for this server?

Enables runtime security analysis of containers, including process behavior monitoring, baselines, and container inventory management. Provides security insights for Kubernetes environments, including cluster inventory, container details, Kubernetes resource monitoring, and identifying security vulnerabilities in Kubernetes objects. Required runtime environment for the MCP server, with version 20.x or higher needed for operation. Used for package installation and management of the MCP server. Provides audit capabilities to track and monitor shell access to pods.

How do I use RAD Security?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@RAD Security show me the latest security findings for my production cluster" 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.

de en es ja ko ru zh

RAD Security

Official

by rad-security

Overview Schema Related Servers Score Discussions

TypeScript

Remote

RAD Security MCP Server

npm version

A Model Context Protocol (MCP) server for RAD Security, providing AI-powered security insights for Kubernetes and cloud environments.

Connect (hosted — recommended)

RAD Security runs the MCP server for you, so most users don't need to install or host anything. Point your MCP client at the hosted endpoint and authenticate with your RAD Security credentials.

Endpoint: https://api.rad.security/mcp/ — note the trailing slash.
Transport: Streamable HTTP.
Authentication: send your credential in the Authorization header:
```
Authorization: Bearer <access_key_id>:<secret_key>:<account_id>
```
<access_key_id> and <secret_key> are a RAD Security API access key (create one in the RAD Security console); <account_id> is your account ID. The server authenticates every request against the RAD Security API — no credentials are stored server-side.

A short-lived form Bearer ory_st_<session_token>:<account_id> also works, but session tokens expire — prefer an access key for anything long-lived (e.g. Slack / Claude Tag).

Claude Code

claude mcp add --transport http rad-security https://api.rad.security/mcp/ \
  --header "Authorization: Bearer <access_key_id>:<secret_key>:<account_id>"

OpenAI Codex CLI

~/.codex/config.toml:

[mcp_servers.rad-security]
url = "https://api.rad.security/mcp/"
http_headers = { "Authorization" = "Bearer <access_key_id>:<secret_key>:<account_id>" }

Or via the CLI, keeping the secret in an env var (export RAD_MCP_TOKEN=<access_key_id>:<secret_key>:<account_id>):

codex mcp add rad-security --url https://api.rad.security/mcp/ --bearer-token-env-var RAD_MCP_TOKEN

Cursor

.cursor/mcp.json:

{
  "mcpServers": {
    "rad-security": {
      "type": "http",
      "url": "https://api.rad.security/mcp/",
      "headers": {
        "Authorization": "Bearer <access_key_id>:<secret_key>:<account_id>"
      }
    }
  }
}

VS Code (GitHub Copilot)

.vscode/mcp.json — note the wrapper key is servers, not mcpServers:

{
  "servers": {
    "rad-security": {
      "type": "http",
      "url": "https://api.rad.security/mcp/",
      "headers": {
        "Authorization": "Bearer <access_key_id>:<secret_key>:<account_id>"
      }
    }
  }
}

Gemini CLI

~/.gemini/settings.json — note the URL field is httpUrl (not url):

{
  "mcpServers": {
    "rad-security": {
      "httpUrl": "https://api.rad.security/mcp/",
      "headers": {
        "Authorization": "Bearer <access_key_id>:<secret_key>:<account_id>"
      }
    }
  }
}

Cline

cline_mcp_settings.json — note type must be exactly streamableHttp (camelCase):

{
  "mcpServers": {
    "rad-security": {
      "type": "streamableHttp",
      "url": "https://api.rad.security/mcp/",
      "headers": {
        "Authorization": "Bearer <access_key_id>:<secret_key>:<account_id>"
      }
    }
  }
}

Windsurf

~/.codeium/windsurf/mcp_config.json — note the URL field is serverUrl:

{
  "mcpServers": {
    "rad-security": {
      "serverUrl": "https://api.rad.security/mcp/",
      "headers": {
        "Authorization": "Bearer <access_key_id>:<secret_key>:<account_id>"
      }
    }
  }
}

Other clients

Most MCP clients accept a remote Streamable HTTP server with a URL and an Authorization header — only the field names differ. Keep the trailing slash on the URL in every case.

Client	Config location	URL field	Transport marker	Header field
Claude Code	`claude mcp add`	positional arg	`--transport http`	`--header`
OpenAI Codex CLI	`~/.codex/config.toml`	`url`	inferred	`http_headers` / `bearer_token_env_var`
Cursor	`.cursor/mcp.json`	`url`	`type: "http"`	`headers`
VS Code	`.vscode/mcp.json` (`servers`)	`url`	`type: "http"`	`headers`
Gemini CLI	`~/.gemini/settings.json`	`httpUrl`	inferred	`headers`
Cline	`cline_mcp_settings.json`	`url`	`type: "streamableHttp"`	`headers`
Windsurf	`~/.codeium/windsurf/mcp_config.json`	`serverUrl`	inferred	`headers`

Claude.ai / Claude Desktop / Claude Tag (Slack)

These surfaces add remote MCP servers as connectors, which use their own credential settings rather than a raw request header. Add https://api.rad.security/mcp/ as a custom connector, then supply the bearer credential through the connector's settings:

Claude Tag (Slack): attach the server as a plugin whose .mcp.json points at the endpoint, and add the bearer credential on the Access bundle's Credentials tab. See Claude Tag — connect a custom MCP server.
Claude.ai / Desktop: add it under Settings → Connectors; see custom connectors.

Test it (MCP Inspector or curl)

npx @modelcontextprotocol/inspector
# Transport:      Streamable HTTP
# URL:            https://api.rad.security/mcp/   (trailing slash)
# Custom headers: { "Authorization": "Bearer <access_key_id>:<secret_key>:<account_id>" }

curl -H "authorization: Bearer <access_key_id>:<secret_key>:<account_id>" \
  -H "content-type: application/json" \
  -H "accept: application/json, text/event-stream" \
  -X POST https://api.rad.security/mcp/ \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"curl","version":"1"}}}'

Scoping the tools an agent sees

By default a connection gets every toolkit. To give an agent a smaller set — less context/token overhead, and least privilege — add a scoping header to that connection alongside Authorization. The subset is enforced: an out-of-scope tool is hidden from tools/list and rejected if called.

Header	Effect
`X-Rad-Toolkits: findings, images`	only these toolkits
`X-Rad-Exclude-Toolkits: workflows`	every toolkit except these
`X-Rad-Readonly: true`	only read-only tools (drops the write tools)

Toolkits: containers, clusters, audit, images, kubeobject, runtime, findings, inbox, workflows, knowledge_base, radql, dashboards, integrations. All are enabled by default — narrow with the headers above, and use X-Rad-Readonly when you want to exclude every write tool.

Example — a read-only findings/images agent (any client that supports headers; Cursor shown):

{
  "mcpServers": {
    "rad-security-findings": {
      "type": "http",
      "url": "https://api.rad.security/mcp/",
      "headers": {
        "Authorization": "Bearer <access_key_id>:<secret_key>:<account_id>",
        "X-Rad-Toolkits": "findings, images",
        "X-Rad-Readonly": "true"
      }
    }
  }
}

In Claude Code, pass an extra --header:

claude mcp add --transport http rad-security https://api.rad.security/mcp/ \
  --header "Authorization: Bearer <access_key_id>:<secret_key>:<account_id>" \
  --header "X-Rad-Toolkits: findings, images"

Related MCP server: IBM QRadar MCP Server

Features

All tools require authentication and an account in RAD Security. The hosted endpoint exposes every toolkit below by default; scope a client down with X-Rad-Toolkits / X-Rad-Exclude-Toolkits, or drop all write tools with X-Rad-Readonly: true.

Account Inventory
- List clusters and their details
Containers Inventory
- List containers and their details
Security Findings
- List and analyze security findings
- Update the status of a security finding
Runtime Security
- Get process trees of running containers
- Get runtime baselines of running containers
- Analyze process behavior of running containers
Audit
- List who shelled into a pod
Images and Vulnerabilities
- Get SBOMs
- List images and their vulnerabilities
- Get top vulnerable images
- Ignore / unignore CVEs and list active CVE dispositions
Kubernetes Objects
- Get details of a specific Kubernetes resource
- List Kubernetes resources
Inbox
- List inbox items and their details
- Mark an inbox item as a false positive
Automations (workflows)
- List automations, runs and schedules
- Get automation and run details
- Run an automation
- Create and update automations, and add cron schedules
"Automation" is the product name users see; "workflow" is the underlying Windmill object the API and tool names use. They are the same thing.
Knowledge Base
- Search the knowledge base
- List collections and documents
- Run structured queries against a document
Dashboards
- List dashboards and get their details
- List and get dashboard and widget templates
- Create a dashboard, and update one in place (omitted fields are left unchanged, so a small edit does not require resending the whole dashboard)
Integrations
- List external integrations
RadQL (Advanced Querying)
- List available data types for querying (containers, findings, kubernetes_resources, etc.)
- Get schema/metadata for specific data types
- List possible values for filter fields
- Execute RadQL queries with filtering, searching, and aggregations
- Build queries programmatically from structured conditions
- Execute multiple queries in parallel

Self-hosting

Prefer to run the server yourself — for example an air-gapped environment, data-residency requirements, or if you don't want to route through the hosted gateway? It's published to npm and as a container image.

Prerequisites

Node.js 20.x or higher

Credentials

Provide your RAD Security credentials via environment variables:

RAD_SECURITY_ACCESS_KEY_ID="your_access_key"
RAD_SECURITY_SECRET_KEY="your_secret_key"
RAD_SECURITY_ACCOUNT_ID="your_account_id"

# Optional: fetched automatically from the account if not set
RAD_SECURITY_TENANT_ID="your_tenant_id"

npx (stdio) — e.g. Claude Desktop

{
  "mcpServers": {
    "rad-security": {
      "command": "npx",
      "args": ["-y", "@rad-security/mcp-server"],
      "env": {
        "RAD_SECURITY_ACCESS_KEY_ID": "<your-access-key-id>",
        "RAD_SECURITY_SECRET_KEY": "<your-secret-key>",
        "RAD_SECURITY_ACCOUNT_ID": "<your-account-id>"
      }
    }
  }
}

Docker (Streamable HTTP)

docker build -t rad-security/mcp-server .
docker run \
  -e TRANSPORT_TYPE=streamable \
  -e RAD_SECURITY_ACCESS_KEY_ID=your_access_key \
  -e RAD_SECURITY_SECRET_KEY=your_secret_key \
  -e RAD_SECURITY_ACCOUNT_ID=your_account_id \
  -p 3000:3000 \
  rad-security/mcp-server

Toolkit filtering

Control which toolkits a self-hosted server exposes:

INCLUDE_TOOLKITS: comma-separated list of toolkits to include (only these are enabled).
EXCLUDE_TOOLKITS: comma-separated list of toolkits to exclude (all others are enabled). Ignored if INCLUDE_TOOLKITS is set.

Available toolkits: containers, clusters, audit, images, kubeobject, runtime, findings, inbox, workflows, knowledge_base, radql, dashboards, integrations. All are enabled by default.

# Only the workflows toolkit
INCLUDE_TOOLKITS="workflows"

# Everything except runtime
EXCLUDE_TOOLKITS="runtime"

Multi-tenant (per-request auth)

MCP_AUTH_MODE controls how a streamable HTTP deployment authenticates inbound requests — this is what the hosted endpoint uses:

MCP_AUTH_MODE=env (default) — every session uses the RAD_SECURITY_* environment credentials. Single-tenant, and unauthenticated at the HTTP layer, so it must not be reachable from untrusted networks.
MCP_AUTH_MODE=header — every request must carry its own credential in the Authorization header (the Bearer <access_key_id>:<secret_key>:<account_id> form above); a missing or malformed header is rejected with 401. Only supported with TRANSPORT_TYPE=streamable. RAD_SECURITY_API_URL is taken from server config, not the caller.

docker run \
  -e TRANSPORT_TYPE=streamable \
  -e MCP_AUTH_MODE=header \
  -e RAD_SECURITY_API_URL=https://api.rad.security \
  -p 3000:3000 \
  rad-security/mcp-server

The SSE transport (TRANSPORT_TYPE=sse) is deprecated in favor of Streamable HTTP and uses env credentials only.

Development

# Install dependencies
npm install

# Run type checking
npm run type-check

# Run linter
npm run lint

# Build
npm run build

License

MIT License - see the LICENSE file for details

Available Tools

65 tools

get_cloud_resource_detailsC

Get detailed information about a specific cloud resource

ParametersJSON Schema

Name	Required	Description
`provider`	Yes	Cloud provider (aws, gcp, azure, linode)
`resource_type`	Yes	Type of cloud resource (to be fetched from get_cloud_resource_facet_values or from list_cloud_resources)
`resource_id`	Yes	ID of the cloud resource

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'Get detailed information,' implying a read-only operation, but does not clarify aspects like authentication needs, rate limits, error handling, or what 'detailed information' entails (e.g., format, depth). This leaves significant gaps for a tool with no annotations.

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

Conciseness5/5

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

The description is a single, clear sentence with no wasted words. It is front-loaded and efficiently conveys the core purpose without unnecessary elaboration, making it easy to parse quickly.

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

Completeness2/5

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

Given the complexity of cloud resources and lack of annotations and output schema, the description is insufficient. It does not explain what 'detailed information' includes, potential return formats, or any behavioral traits. For a tool with three required parameters and no structured output guidance, more context is needed to ensure proper usage.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents the parameters (provider, resource_type, resource_id). The description adds no additional meaning beyond what the schema provides, such as explaining how these parameters interact or examples of valid inputs. Baseline 3 is appropriate as the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the verb ('Get') and resource ('detailed information about a specific cloud resource'), making the purpose understandable. However, it does not differentiate from sibling tools like 'get_cloud_resource_facets' or 'get_cloud_resource_facet_value', which might also retrieve cloud resource information, so it lacks sibling 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/5

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, such as needing to fetch resource_type from other tools like 'get_cloud_resource_facet_values' or 'list_cloud_resources' as hinted in the schema, nor does it specify use cases or exclusions.

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

get_cloud_resource_facetsC

Get available facets for filtering cloud resources from a provider

ParametersJSON Schema

Name	Required	Description	Default
`provider`	Yes	Cloud provider (aws, gcp, azure, linode)

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Get') but doesn't describe what 'facets' are, the format of the response, whether this is a read-only operation, potential rate limits, or authentication requirements. This leaves significant gaps for an AI agent to understand the tool's 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/5

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

The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'facets' are, the return format, or how this tool fits into broader workflows with sibling tools. For a tool that likely returns structured metadata, more context is needed for effective use.

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

Parameters3/5

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

The input schema has 100% description coverage, with the single parameter 'provider' fully documented in the schema. The description adds no additional parameter semantics beyond implying the provider is needed, so it meets the baseline of 3 where the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the verb ('Get') and resource ('available facets for filtering cloud resources'), making the purpose understandable. It specifies the scope ('from a provider'), which helps differentiate it from generic facet tools, though it doesn't explicitly distinguish it from sibling tools like 'get_cloud_resource_facet_value'.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_cloud_resources' or 'get_cloud_resource_details', nor does it explain prerequisites or typical use cases for retrieving facets versus other operations.

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

get_cloud_resource_facet_valueC

Get values for a specific facet from a cloud provider

ParametersJSON Schema

Name	Required	Description	Default
`provider`	Yes	Cloud provider (aws, gcp, azure, linode)
`facet_id`	Yes	ID of the facet

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden but lacks behavioral details. It doesn't disclose if this is a read-only operation, what permissions are needed, how results are formatted, or any rate limits. The description is too minimal to inform the agent adequately about how the tool behaves beyond its basic purpose.

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

Conciseness4/5

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

The description is a single, efficient sentence with no wasted words, making it easy to parse. However, it could be more front-loaded with critical context (e.g., clarifying 'facet' or usage), but as-is, it's appropriately concise for its limited content.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete for a tool that likely returns data values. It doesn't explain what 'values' are returned (e.g., strings, lists, structured data), error conditions, or how to interpret results. For a tool with two parameters and potential complexity, this leaves significant gaps for the agent.

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

Parameters3/5

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

Schema description coverage is 100%, with clear descriptions for both parameters (provider and facet_id), including an enum for provider. The description adds no extra meaning beyond the schema, such as explaining what a facet_id represents or examples of facet types. Baseline 3 is appropriate as the schema does the heavy lifting.

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

Purpose3/5

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

The description states the action ('Get values') and resource ('for a specific facet from a cloud provider'), which is clear but vague. It doesn't specify what a 'facet' is or how it differs from sibling tools like 'get_cloud_resource_facets' or 'get_cloud_resource_details', leaving room for confusion about its exact scope.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. With siblings like 'get_cloud_resource_facets' (likely listing facets) and 'get_cloud_resource_details' (likely broader details), the description offers no context for selection, leaving the agent to guess based on tool names alone.

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

get_cluster_detailsC

Get detailed information about a specific Kubernetes cluster managed by RAD Security

ParametersJSON Schema

Name	Required	Description	Default
`cluster_id`	Yes	ID of the cluster to get details for

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets' information (implying a read operation) but doesn't clarify what 'detailed information' includes, whether it requires specific permissions, if there are rate limits, or what the response format looks like. This leaves significant gaps for a tool that presumably returns complex cluster data.

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

Conciseness5/5

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

The description is a single, efficient sentence that front-loads the key information ('Get detailed information') without unnecessary words. Every part of the sentence contributes to understanding the tool's purpose.

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

Completeness2/5

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

Given the lack of annotations and output schema, and the likely complexity of Kubernetes cluster details, the description is insufficient. It doesn't hint at what 'detailed information' entails (e.g., configuration, status, resources), leaving the agent uncertain about the tool's output and behavioral context.

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

Parameters3/5

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

The input schema has 100% description coverage, with the single parameter 'cluster_id' clearly documented in the schema. The description doesn't add any additional semantic context beyond what the schema provides, such as where to find cluster IDs or format examples, so the baseline score of 3 is appropriate.

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

Purpose4/5

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

The description clearly states the action ('Get detailed information') and resource ('a specific Kubernetes cluster managed by RAD Security'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'list_clusters' or 'get_k8s_resource_details', which could provide similar cluster-related information.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. For example, it doesn't specify if this should be used after 'list_clusters' to get more details for a specific cluster ID, or how it differs from 'get_k8s_resource_details' which might overlap in functionality.

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

get_compliance_controlC

Get detailed information about a specific compliance control

ParametersJSON Schema

Name	Required	Description	Default
`control_name`	Yes	Name of the compliance control
`datasource_ids`	Yes	Comma-separated datasource IDs (e.g. AWS Account IDs)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but reveals minimal behavior. It states it's a read operation ('Get') but doesn't disclose authentication requirements, rate limits, error conditions, response format, or whether it's idempotent. For a tool with required parameters and no output schema, this leaves significant gaps in understanding 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.

Conciseness4/5

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

The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple retrieval tool, though it could be slightly more informative about what 'detailed information' entails to better justify its place.

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

Completeness2/5

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

For a tool with 2 required parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'detailed information' returns, how datasource filtering affects results, or any behavioral constraints. The agent lacks critical context to use this tool effectively beyond basic parameter passing.

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

Parameters3/5

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

Schema description coverage is 100%, providing complete parameter documentation. The description adds no additional parameter semantics beyond implying 'control_name' identifies which control and 'datasource_ids' filters results. Since the schema already fully describes both parameters, the baseline score of 3 is appropriate.

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

Purpose4/5

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

The description clearly states the verb 'Get' and resource 'compliance control' with the qualifier 'detailed information about a specific' one. It distinguishes from sibling 'list_compliance_controls' by focusing on a single control rather than listing multiple. However, it doesn't specify what 'detailed information' includes or how it differs from other get_* 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/5

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 doesn't mention prerequisites, compare with 'list_compliance_controls' for overview vs detail, or indicate when datasource filtering is needed. The agent must infer usage from the tool name and parameters alone.

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

get_container_detailsB

Get detailed information about a container secured by RAD Security

ParametersJSON Schema

Name	Required	Description	Default
`container_id`	Yes	ID of the container to get details for

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves 'detailed information,' implying a read-only operation, but doesn't specify what details are included, whether authentication is required, or if there are rate limits. This leaves gaps in understanding the tool's behavior beyond basic retrieval.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly for an AI agent.

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

Completeness3/5

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

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is minimally adequate. It clarifies the tool's purpose but lacks details on output format, error handling, or behavioral context, which could be important for a security-focused tool in a complex environment with many siblings.

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

Parameters3/5

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

The input schema has 100% description coverage, with the 'container_id' parameter clearly documented. The description adds no additional meaning beyond the schema, such as format examples or constraints, so it meets the baseline score of 3 where the schema handles parameter documentation adequately.

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

Purpose4/5

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

The description clearly states the action ('Get detailed information') and resource ('about a container secured by RAD Security'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_container_llm_analysis' or 'get_containers_baselines', which also retrieve container-related information but with different scopes or types of data.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, such as 'list_containers' for a summary view or other 'get_*' tools for specific container details. Without explicit context or exclusions, the agent must infer usage based on tool names alone.

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

get_container_llm_analysisC

Get LLM analysis of a container's process tree

ParametersJSON Schema

Name	Required	Description	Default
`container_id`	Yes	Container ID to get LLM analysis for

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. While 'Get' implies a read operation, it doesn't disclose behavioral traits like authentication requirements, rate limits, what 'LLM analysis' entails, response format, or potential side effects. The description is minimal and lacks necessary context 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.

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete for a tool that presumably returns complex LLM analysis results. It doesn't explain what 'LLM analysis' includes, the format of the output, or any behavioral considerations. For a tool with potential complexity, this minimal description leaves significant gaps.

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

Parameters3/5

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

Schema description coverage is 100% (the single parameter 'container_id' is documented in the schema), so the baseline is 3. The description doesn't add any meaningful parameter semantics beyond what's already in the schema—it mentions 'container' but provides no additional context about format, constraints, or examples.

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

Purpose4/5

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

The description clearly states the action ('Get LLM analysis') and the target resource ('container's process tree'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_container_details' or 'get_containers_process_trees', which might offer related but different functionality.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools related to containers (e.g., 'get_container_details', 'get_containers_process_trees'), there's no indication of context, prerequisites, or exclusions for this specific LLM analysis tool.

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

get_containers_baselinesC

Get runtime baselines for multiple containers

ParametersJSON Schema

Name	Required	Description	Default
`container_ids`	Yes	List of container IDs to get baselines for

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states what the tool does but lacks behavioral details like whether this is a read-only operation, what format the baselines are returned in, if there are rate limits, or any authentication requirements. This is a significant gap for a tool with no 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.

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It is appropriately sized and front-loaded, making it easy to parse quickly.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'runtime baselines' entail, how results are structured, or any behavioral traits, leaving gaps in understanding for a tool that likely returns complex data.

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

Parameters3/5

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

Schema description coverage is 100%, with the parameter 'container_ids' well-documented in the schema as 'List of container IDs to get baselines for'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3.

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

Purpose4/5

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

The description clearly states the verb 'Get' and the resource 'runtime baselines for multiple containers', making the purpose specific and understandable. It distinguishes from siblings like 'get_container_details' by focusing on baselines rather than general details, though it doesn't explicitly contrast with them.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name and parameters alone.

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

get_containers_process_treesC

Get process trees for multiple containers

ParametersJSON Schema

Name	Required	Description	Default
`container_ids`	Yes	List of container IDs to get process trees for
`processes_limit`	No	Limit the number of processes to get

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but lacks details on permissions, rate limits, response format, or potential side effects. For a tool that likely queries system data, this is a significant gap in 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/5

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making 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.

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what a 'process tree' entails, how results are structured, or any behavioral constraints. For a tool with two parameters and likely complex output, this leaves significant gaps for an agent to operate effectively.

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

Parameters3/5

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

Schema description coverage is 100%, meaning the input schema fully documents both parameters ('container_ids' and 'processes_limit'). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline score without compensating or detracting.

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

Purpose4/5

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

The description clearly states the action ('Get') and resource ('process trees for multiple containers'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_container_details' or 'get_container_llm_analysis' that might also retrieve container-related information, so it doesn't reach the highest 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/5

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 doesn't mention sibling tools like 'get_container_details' or 'list_containers', nor does it specify prerequisites or contexts for usage, leaving the agent to infer based on the name alone.

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

get_cveB

Get details for a specific CVE ID. Source: cve-search.org

ParametersJSON Schema

Name	Required	Description	Default
`cveId`	Yes	CVE ID to retrieve information for

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Get details') and source, but lacks critical information: whether this is a read-only operation, if it requires authentication, rate limits, error handling, or what the output format looks like (e.g., JSON structure). For a tool with no annotation coverage, this is a significant gap.

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

Conciseness5/5

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

The description is extremely concise and front-loaded: two sentences with zero waste. The first sentence states the core purpose, and the second provides the data source. Every word earns its place, making 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.

Completeness3/5

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

Given the tool's low complexity (single parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and source, but lacks behavioral context (e.g., read/write nature, error cases) and usage guidelines relative to siblings. For a simple lookup tool, it's functional but could be more informative.

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

Parameters3/5

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

Schema description coverage is 100%, with the single parameter 'cveId' fully documented in the schema. The description adds no additional parameter semantics beyond what's in the schema (e.g., format examples like 'CVE-2021-44228' or validation rules). Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Get details for a specific CVE ID.' It specifies the verb ('Get details') and resource ('CVE ID'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_latest_30_cves' or 'search_cves', which reduces clarity in a crowded namespace.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It mentions the data source ('Source: cve-search.org'), but doesn't explain when to choose this over 'get_latest_30_cves' (for recent CVEs) or 'search_cves' (for broader queries), leaving the agent without context for tool selection.

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

get_dashboardB

Get detailed information about a specific dashboard

ParametersJSON Schema

Name	Required	Description	Default
`dashboard_id`	Yes	ID of the dashboard

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get detailed information' implies a read-only operation, it doesn't specify authentication requirements, rate limits, error conditions, or the format/scope of the returned information. For a tool with no annotation coverage, this leaves significant behavioral gaps.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loaded with the essential information.

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

Completeness3/5

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

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks behavioral details that would be helpful without annotations. For a basic read operation, it's complete enough to understand the core function but could provide more context about the returned data.

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

Parameters3/5

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

The input schema has 100% description coverage, with the single parameter 'dashboard_id' clearly documented in the schema. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('detailed information about a specific dashboard'), making it immediately understandable. However, it doesn't distinguish this tool from its sibling 'list_dashboards' or other 'get_' tools that retrieve specific resources, which prevents a perfect 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/5

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 doesn't mention the sibling 'list_dashboards' for browsing dashboards or clarify that this tool is for retrieving details of a single, known dashboard. Without any usage context or exclusions, the agent must infer when this tool is appropriate.

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

get_dashboard_templateB

Get detailed information about a specific dashboard template

ParametersJSON Schema

Name	Required	Description	Default
`dashboard_template_id`	Yes	ID of the dashboard template

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It states the tool retrieves 'detailed information', implying a read-only operation, but doesn't disclose behavioral traits such as authentication requirements, rate limits, error conditions (e.g., invalid ID handling), or response format. For a tool with no annotation coverage, this leaves significant gaps in understanding 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/5

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

The description is a single, efficient sentence with zero waste. It front-loads the core purpose ('Get detailed information') and specifies the resource clearly. Every word earns its place, making it easy to parse quickly.

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

Completeness3/5

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

Given the tool's low complexity (single required parameter, no nested objects) and high schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it lacks details on behavioral aspects (e.g., what 'detailed information' includes) and response format, leaving room for improvement in guiding the agent.

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

Parameters3/5

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

Schema description coverage is 100%, with the single parameter 'dashboard_template_id' fully documented in the schema. The description adds no additional parameter semantics beyond implying specificity ('a specific dashboard template'), which is already clear from the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the verb ('Get') and resource ('dashboard template'), specifying it provides 'detailed information about a specific dashboard template'. It distinguishes from sibling tools like 'list_dashboard_templates' by focusing on a single template rather than listing multiple. However, it doesn't explicitly contrast with 'get_dashboard' or 'get_widget_template', which could cause confusion about scope boundaries.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a template ID), differentiate from similar tools like 'get_dashboard' or 'get_widget_template', or specify use cases (e.g., for template customization or analysis). The agent must infer usage from the name and parameter alone.

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

get_identity_detailsC

Get detailed information about a specific identity in a Kubernetes cluster

ParametersJSON Schema

Name	Required	Description	Default
`identity_id`	Yes	Identity ID to get details for

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read-only operation but doesn't disclose authentication needs, rate limits, error conditions, or what 'detailed information' entails (e.g., format, depth). For a tool with zero annotation coverage, this is inadequate.

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

Conciseness5/5

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

The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It avoids redundancy and wastes no space, making it easy to parse quickly.

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

Completeness2/5

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

Given no annotations and no output schema, the description is insufficient for a tool that presumably returns complex identity details. It doesn't explain the return format, error handling, or dependencies, leaving significant gaps in understanding how to interpret results.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents the single parameter 'identity_id'. The description adds no additional parameter context beyond implying it fetches details for a specific identity, meeting the baseline for high schema coverage without extra value.

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

Purpose4/5

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

The description clearly states the action ('Get detailed information') and resource ('about a specific identity in a Kubernetes cluster'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_identities' or 'get_k8s_resource_details', which would require more specific scoping to earn a 5.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an identity ID from 'list_identities'), contrast with bulk retrieval tools, or specify use cases, leaving the agent to infer usage 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.

get_image_sbomB

Get the SBOM of a container image

ParametersJSON Schema

Name	Required	Description	Default
`digest`	Yes	Image digest (required for SBOM)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only states the basic function without disclosing behavioral traits like authentication needs, rate limits, or response format. It lacks details on what 'Get' entails operationally, such as whether it's a read-only fetch or 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.

Conciseness5/5

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

The description is a single, clear sentence with zero waste, front-loading the key information efficiently. It's appropriately sized for the tool's simplicity.

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

Completeness3/5

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

Given the tool has one parameter with full schema coverage and no output schema, the description is minimally adequate but lacks context on behavioral aspects and usage guidelines. It's complete enough for basic understanding but misses details needed for optimal agent invocation.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents the 'digest' parameter fully. The description adds no additional meaning beyond implying the digest is for SBOM retrieval, but doesn't clarify format or constraints beyond the schema, meeting the baseline for high coverage.

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

Purpose4/5

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

The description clearly states the action ('Get') and resource ('SBOM of a container image'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'get_container_details' or 'list_images', which might also involve container images, so it lacks sibling 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/5

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, such as 'list_image_vulnerabilities' or other container-related tools. The description only states what it does, not when it's appropriate, leaving usage unclear.

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

get_inbox_item_detailsB

Get detailed information about a specific inbox item

ParametersJSON Schema

Name	Required	Description	Default
`inbox_item_id`	Yes	ID of the inbox item to get details for

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get'), but doesn't cover aspects like authentication requirements, rate limits, error handling, or what 'detailed information' includes (e.g., fields, format). This leaves significant gaps for a tool with no annotation support.

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

Conciseness5/5

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

The description is a single, focused sentence with no wasted words. It's front-loaded with the core action and resource, making it efficient and easy to parse.

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

Completeness3/5

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

Given the simple input schema (1 parameter, 100% coverage) and lack of annotations/output schema, the description is minimally adequate. It clarifies the tool's purpose but lacks behavioral details and usage context, which are important for a read operation in a complex environment with many sibling tools.

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

Parameters3/5

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

The schema description coverage is 100%, with the single parameter 'inbox_item_id' fully documented in the schema. The description doesn't add any parameter details beyond what the schema provides (e.g., format examples, sourcing hints), so it meets the baseline of 3 for high schema coverage.

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

Purpose4/5

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

The description clearly states the verb ('Get') and resource ('detailed information about a specific inbox item'), making the purpose understandable. However, it doesn't distinguish this tool from potential sibling tools like 'list_inbox_items' or 'get_identity_details' in terms of scope or detail level.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an inbox item ID from list_inbox_items), exclusions, or comparisons to sibling tools, leaving the agent to infer usage context.

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

get_k8s_resource_detailsB

Get the latest manifest of a Kubernetes resource

ParametersJSON Schema

Name	Required	Description	Default
`cluster_id`	Yes	ID of the Kubernetes cluster
`resource_uid`	Yes	Resource UID to get the details for

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation but doesn't clarify if it's read-only, what permissions are required, whether it returns structured data or raw manifests, or if there are rate limits. This leaves significant behavioral gaps for a tool that interacts with Kubernetes clusters.

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

Conciseness5/5

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

The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple retrieval operation and front-loads the essential information.

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

Completeness3/5

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

For a tool with no annotations and no output schema, the description is minimally complete but lacks important context. It identifies what the tool does but doesn't explain what 'latest manifest' means, what format it returns, or how it differs from other Kubernetes resource tools. The 100% schema coverage helps, but behavioral gaps remain.

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

Parameters3/5

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

The input schema has 100% description coverage, clearly documenting both required parameters. The description adds no additional parameter semantics beyond what the schema already provides, so it meets the baseline score of 3 for adequate but not enhanced parameter documentation.

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

Purpose4/5

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

The description clearly states the action ('Get') and resource ('latest manifest of a Kubernetes resource'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_k8s_resource_misconfig' or 'list_k8s_resources' that also retrieve Kubernetes resource information, preventing a perfect 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/5

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. With many sibling tools like 'get_k8s_resource_misconfig' and 'list_k8s_resources' that might retrieve similar or overlapping data, there's no indication of when this specific 'get details' operation is appropriate versus other retrieval methods.

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

get_k8s_resource_misconfigC

Get detailed information about a specific Kubernetes resource misconfiguration

ParametersJSON Schema

Name	Required	Description	Default
`cluster_id`	Yes	ID of the cluster to get misconfiguration for
`misconfig_id`	Yes	ID of the misconfiguration to get details for

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only states it 'gets detailed information' without disclosing behavioral traits. It doesn't mention if this is a read-only operation, what format the details are in (e.g., JSON structure), potential errors (e.g., invalid IDs), or any rate limits. This leaves significant gaps for a tool that likely returns complex security data.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every part contributing to clarity.

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

Completeness2/5

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

Given the complexity of Kubernetes security misconfigurations and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' includes (e.g., severity, remediation steps), the response format, or error handling. For a tool with no structured output documentation, this leaves too much unspecified.

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

Parameters3/5

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

Schema description coverage is 100%, with both parameters clearly documented in the schema. The description adds no additional meaning beyond implying these IDs are needed to fetch details, which is already covered. This meets the baseline of 3 when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the verb 'Get' and the resource 'detailed information about a specific Kubernetes resource misconfiguration', making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list_k8s_resource_misconfigs' or 'get_k8s_resource_details', which would require mentioning this retrieves details for a specific misconfiguration ID rather than listing multiple.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like needing a specific misconfiguration ID from a list operation, nor does it compare to siblings like 'list_k8s_resource_misconfigs' for browsing or 'get_k8s_resource_details' for general resource info.

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

get_latest_30_cvesA

Get the latest/newest 30 CVEs including CAPEC, CWE and CPE expansions. Source: cve-search.org

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the source ('cve-search.org'), which adds useful context about data origin, but does not cover other behavioral aspects such as rate limits, authentication needs, error handling, or response format. The description is informative but lacks comprehensive behavioral 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/5

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

The description is a single, efficient sentence that front-loads the core functionality ('Get the latest/newest 30 CVEs') and adds valuable details ('including CAPEC, CWE and CPE expansions. Source: cve-search.org') without any waste. Every part of the sentence contributes meaningfully to understanding the tool.

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

Completeness3/5

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

Given the tool's complexity (retrieving CVEs with expansions), lack of annotations, and no output schema, the description provides a good overview but is incomplete. It specifies what data is included and the source, but does not describe the return structure, potential errors, or operational constraints, which could hinder an agent's ability to use it effectively.

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

Parameters4/5

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's output scope. This meets the baseline for tools with no parameters, as it avoids unnecessary repetition.

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

Purpose5/5

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

The description clearly states the action ('Get'), the resource ('latest/newest 30 CVEs'), and specific details about what's included ('CAPEC, CWE and CPE expansions'). It distinguishes from sibling 'get_cve' and 'search_cves' by specifying a fixed count of 30 and the 'latest/newest' qualifier, making the purpose specific and differentiated.

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

Usage Guidelines4/5

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

The description implies usage context by specifying 'latest/newest 30 CVEs', suggesting this tool is for retrieving recent vulnerabilities. However, it does not explicitly state when to use this versus alternatives like 'get_cve' or 'search_cves', or provide any exclusions or prerequisites, leaving some ambiguity in tool selection.

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

get_top_vulnerable_imagesC

Get the most vulnerable images from your account

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It states a read operation ('Get'), but doesn't disclose behavioral traits like authentication needs, rate limits, pagination, sorting criteria for 'most vulnerable', or what data is returned. This leaves significant gaps for an agent to understand how to use it 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/5

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

The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to parse quickly.

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

Completeness2/5

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 a vague purpose, the description is incomplete. It doesn't explain what 'most vulnerable' means, how results are returned, or any constraints. For a tool that likely returns prioritized data, more context is needed to use it correctly.

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

Parameters4/5

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is fine here. Baseline is 4 since it's appropriate for a zero-param tool.

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

Purpose3/5

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

The description 'Get the most vulnerable images from your account' states a clear action ('Get') and resource ('most vulnerable images'), but it's vague about what 'most vulnerable' means (by count, severity, recency?). It doesn't distinguish from siblings like 'list_images' or 'list_image_vulnerabilities' which might provide similar functionality.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like 'list_images' or 'list_image_vulnerabilities'. The description implies a filtered or prioritized view, but doesn't specify prerequisites, context, or exclusions for usage.

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

get_widget_templateC

Get detailed information about a specific widget template

ParametersJSON Schema

Name	Required	Description	Default
`widget_template_id`	Yes	ID of the widget template

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only states it 'gets' information without disclosing behavioral traits like read-only nature, error handling, authentication needs, or rate limits. It lacks details on what 'detailed information' includes or how it behaves, leaving gaps for a tool with no structured safety hints.

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

Conciseness4/5

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

The description is a single, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for a simple tool, though it could be more front-loaded with key details. No waste, but slightly under-specified.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete for a tool that presumably returns data. It doesn't explain what 'detailed information' includes, potential response formats, or error cases. For a retrieval tool with no structured output, more context is needed to guide the agent effectively.

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

Parameters3/5

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

Schema description coverage is 100%, so the input schema fully documents the 'widget_template_id' parameter. The description adds no meaning beyond this, as it doesn't explain parameter usage, format, or examples. Baseline 3 is appropriate since the schema handles parameter documentation adequately.

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

Purpose3/5

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

The description 'Get detailed information about a specific widget template' clearly states the action (get) and resource (widget template), but it's vague about what 'detailed information' entails and doesn't differentiate from siblings like 'list_widget_templates' or 'get_dashboard_template'. It avoids tautology but lacks specificity.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as when to choose 'get_widget_template' over 'list_widget_templates' for a single item versus multiple items. The description offers no usage context.

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

get_workflowC

Get detailed information about a specific workflow by ID. It contains the workflow definition, default arguments, and schema how to run the workflow

ParametersJSON Schema

Name	Required	Description	Default
`workflow_id`	Yes	ID of the workflow to get

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool as a read operation ('get') and hints at the return content, but it does not cover critical aspects like authentication requirements, error handling, rate limits, or whether the operation is idempotent. For a tool with zero annotation coverage, this is insufficient, though it at least implies a safe read operation.

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

Conciseness4/5

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

The description is concise and front-loaded, with the core purpose stated in the first sentence and additional details in the second. Both sentences are relevant and add value, with no wasted words. It could be slightly more structured by explicitly separating purpose from return details, but it remains efficient.

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

Completeness3/5

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

Given the tool's low complexity (single parameter, no nested objects) and lack of annotations or output schema, the description is minimally adequate. It covers the basic purpose and return content, but it misses usage guidelines and behavioral details that would enhance completeness. The absence of an output schema means the description should ideally explain return values more thoroughly, which it only partially does.

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

Parameters3/5

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

The input schema has 100% description coverage, with the single parameter 'workflow_id' clearly documented. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. According to the rules, when schema coverage is high (>80%), the baseline score is 3, which applies here.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Get detailed information about a specific workflow by ID.' It specifies the verb ('get'), resource ('workflow'), and scope ('by ID'), and mentions the content returned ('workflow definition, default arguments, and schema how to run the workflow'). However, it does not explicitly differentiate from sibling tools like 'get_workflow_run' or 'list_workflows', which is why it scores 4 instead of 5.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools such as 'list_workflows' (for listing workflows) or 'get_workflow_run' (for run details), nor does it specify prerequisites or exclusions. This lack of contextual usage information limits its effectiveness for an AI agent.

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

get_workflow_runB

Get detailed information about a specific workflow run

ParametersJSON Schema

Name	Required	Description	Default
`workflow_id`	Yes	ID of the workflow
`run_id`	Yes	ID of the workflow run

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns structured data, or handles errors. This leaves significant gaps for a tool that likely interacts with workflow systems.

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

Conciseness5/5

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

The description is a single, clear sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and efficiently conveys the core functionality, making it easy to parse quickly.

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

Completeness3/5

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

Given the tool's moderate complexity (retrieving detailed run information) and lack of annotations or output schema, the description is minimally adequate but incomplete. It doesn't explain what 'detailed information' includes, potential error conditions, or system dependencies, which could hinder effective use by an AI agent.

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

Parameters3/5

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

The input schema has 100% description coverage, clearly documenting both required parameters (workflow_id and run_id). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage.

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

Purpose4/5

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

The description clearly states the tool's purpose as retrieving detailed information about a specific workflow run, which is a specific verb (get) and resource (workflow run). However, it doesn't distinguish itself from sibling tools like 'get_workflow' or 'list_workflow_runs' beyond the specificity of 'run' versus 'workflow' or 'runs'.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, such as 'get_workflow' for workflow metadata or 'list_workflow_runs' for multiple runs. There's no mention of prerequisites, context, or exclusions, leaving usage entirely implicit.

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

list_cloud_resourcesC

List cloud resources for a specific provider with optional filtering

ParametersJSON Schema

Name	Required	Description
`provider`	Yes	Cloud provider (aws, gcp, azure, linode)
`filters`	No	Filter string (e.g., 'resource_type:EC2NetworkInterface,resource_type:SQSQueue,aws_account:123456789012,compliance:not_compliant')
`offset`	No	Pagination offset. Default: 0
`limit`	No	Maximum number of results to return
`q`	No	Free text search query

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists resources with filtering but doesn't describe critical behaviors like pagination handling (implied by offset/limit parameters), rate limits, authentication requirements, error conditions, or the format/structure of returned data. For a list operation with 5 parameters and no output schema, this leaves significant gaps in understanding how the tool 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/5

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

The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly states the action, target, and key feature (optional filtering), earning its place with zero waste. This is appropriately concise for a tool with a clear schema.

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

Completeness2/5

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

Given the tool's complexity (5 parameters, no annotations, no output schema), the description is incomplete. It lacks behavioral context (e.g., pagination, errors), doesn't differentiate from siblings, and provides minimal guidance. While the schema covers parameters well, the description fails to compensate for missing annotations and output schema, leaving the agent under-informed about how to effectively use this tool.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all 5 parameters with descriptions and defaults. The description adds no additional parameter semantics beyond implying filtering is optional. It doesn't explain filter syntax beyond the schema's example, clarify provider-specific nuances, or detail interactions between parameters like 'filters' and 'q'. Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'List cloud resources for a specific provider with optional filtering.' It specifies the verb ('list'), resource ('cloud resources'), and scope ('specific provider'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list_clusters' or 'list_k8s_resources' that might also list cloud resources, preventing a perfect 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/5

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 doesn't mention sibling tools like 'list_clusters' or 'list_k8s_resources' that might overlap in functionality, nor does it specify prerequisites, exclusions, or contextual triggers for usage. The agent must infer usage from the name and parameters alone.

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

list_clustersB

List Kubernetes clusters managed by RAD Security

ParametersJSON Schema

Name	Required	Description	Default
`page_size`	No	Number of clusters per page for list_clusters (default: 50)
`page`	No	Page number to retrieve for list_clusters (default: 1)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a list operation, implying read-only behavior, but does not cover aspects like authentication requirements, rate limits, pagination details beyond schema defaults, or error handling, leaving significant gaps.

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

Conciseness5/5

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

The description is a single, direct sentence with no unnecessary words, efficiently conveying the core purpose. It is appropriately sized and front-loaded, making it easy to parse quickly.

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

Completeness3/5

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

Given the tool's low complexity (list operation with 2 optional parameters) and 100% schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it lacks details on behavioral traits and return values, leaving room for improvement in completeness.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents the two parameters (page_size and page) with defaults. The description adds no additional parameter semantics beyond what the schema provides, 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.

Purpose4/5

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

The description clearly states the action ('List') and resource ('Kubernetes clusters managed by RAD Security'), making the purpose unambiguous. However, it does not differentiate from sibling tools like 'list_cloud_resources' or 'list_k8s_resources' that might also list resources, missing explicit 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/5

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 such as 'list_cloud_resources' or 'get_cluster_details'. The description lacks context about prerequisites, scenarios, or exclusions, offering minimal usage direction.

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

list_compliance_controlsC

List all compliance control summaries for the account

ParametersJSON Schema

Name	Required	Description
`status`	No	Filter by failure status: failing or passing
`providers`	No	Comma-separated list of cloud providers (aws, azure, gcp, linode)
`page`	No	Page number starting from 1
`page_size`	No	Page size

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions 'list all' but doesn't disclose pagination behavior, rate limits, authentication requirements, or what 'summaries' entails. For a listing tool with 4 parameters and no output schema, this leaves significant behavioral gaps.

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

Conciseness5/5

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

The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it efficient and easy to parse.

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

Completeness2/5

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

Given 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'summaries' include, how pagination works, or the tool's scope relative to siblings. For a listing tool in a complex domain with many alternatives, more context is needed.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description adds no additional parameter context beyond implying a listing operation, which aligns with the schema but doesn't provide extra semantic value. Baseline 3 is appropriate when schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the action ('List all') and resource ('compliance control summaries for the account'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_compliance_frameworks' or 'list_requirement_controls', which reduces specificity.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools in the compliance and listing categories, there's no indication of context, prerequisites, or exclusions that would help an agent choose appropriately.

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

list_compliance_frameworksB

List all compliance frameworks available for cloud resources (e.g., CIS, SOC2, PCI-DSS)

ParametersJSON Schema

Name	Required	Description
`datasource_ids`	No	Comma-separated datasource IDs (e.g. AWS Account IDs)
`page`	No	Page number starting from 1
`page_size`	No	Page size

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It implies a read-only list operation but doesn't mention pagination behavior (though parameters suggest it), rate limits, authentication requirements, or what the return format looks like. For a tool with three parameters and no output schema, this leaves significant behavioral gaps.

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

Conciseness5/5

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

The description is a single, efficient sentence that immediately states the tool's purpose with helpful examples. There's no wasted language or unnecessary elaboration, making it easy to parse and understand at a glance.

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

Completeness3/5

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

For a list tool with no annotations and no output schema, the description adequately states what the tool does but lacks important context about behavior, output format, and usage guidelines. The 100% schema coverage helps with parameters, but without output schema or annotations, the description should do more to compensate for these gaps.

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

Parameters3/5

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

Schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter semantics beyond implying the tool lists 'compliance frameworks' generally. It doesn't explain how datasource_ids relate to frameworks or clarify pagination behavior, so it meets the baseline but doesn't add value beyond the schema.

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

Purpose4/5

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

The description clearly states the action ('List all') and target resource ('compliance frameworks available for cloud resources'), providing specific examples (CIS, SOC2, PCI-DSS) that help clarify scope. However, it doesn't explicitly differentiate from sibling tools like 'list_framework_requirements' or 'list_compliance_controls', which might have overlapping domains.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or compare with related tools like 'list_compliance_controls' or 'list_framework_requirements', leaving the agent to infer usage based solely on the tool name and description.

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

list_containersB

List containers secured by RAD Security with optional filtering by image name, image digest, namespace, cluster_id, or free text search

ParametersJSON Schema

Name	Required	Description
`filters`	No	Filter string (e.g., 'image_name:nginx' or 'image_digest:sha256:...' or 'owner_namespace:namespace' or 'cluster_id:cluster_id'). Multiple filters can be combined with commas.
`offset`	No	Pagination offset. Default: 0
`limit`	No	Maximum number of results to return. Default: 20
`q`	No	Free text search query

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('List') but doesn't specify if it's safe, requires authentication, has rate limits, or what the output format looks like. The mention of 'secured by RAD Security' hints at security context but lacks details on access controls or potential 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/5

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

The description is a single, efficient sentence that front-loads the core purpose and lists filtering options without unnecessary words. Every part of the sentence contributes directly to understanding the tool's functionality.

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

Completeness3/5

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

Given the tool's complexity (listing with multiple filters and pagination), no annotations, and no output schema, the description is adequate but incomplete. It covers the basic purpose and parameters but lacks behavioral details like pagination behavior, error handling, or security requirements, which are important for a tool in a security context.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all parameters. The description adds minimal value by listing filterable attributes (image name, digest, namespace, cluster_id, free text search), but doesn't explain syntax or usage beyond what's in the schema. This meets the baseline for high schema coverage.

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

Purpose4/5

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

The description clearly states the verb ('List') and resource ('containers secured by RAD Security'), making the purpose evident. It distinguishes from siblings like 'get_container_details' by focusing on listing with filtering rather than retrieving details. However, it doesn't explicitly differentiate from 'list_images' or 'list_k8s_resources', which could involve overlapping resources.

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

Usage Guidelines2/5

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

The description mentions optional filtering but provides no guidance on when to use this tool versus alternatives like 'list_images' or 'get_container_details'. It lacks context on prerequisites, such as whether specific permissions are needed, or when filtering is appropriate versus other listing tools.

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

list_control_resourcesC

List cloud resources associated with a specific compliance control

ParametersJSON Schema

Name	Required	Description
`control_name`	Yes	Name of the compliance control
`datasource_ids`	Yes	Comma-separated datasource IDs (e.g. AWS Account IDs)
`page`	No	Page number starting from 1
`page_size`	No	Page size

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists resources but doesn't describe what the output looks like, whether it's paginated (though parameters suggest it), if there are rate limits, authentication requirements, or potential side effects. For a tool with 4 parameters and no output schema, this leaves significant gaps.

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

Conciseness5/5

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

The description is a single, clear sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration or redundancy.

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

Completeness2/5

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

Given the complexity (4 parameters, no annotations, no output schema) and the need to distinguish from many sibling tools, the description is incomplete. It doesn't explain output format, behavioral constraints, or usage context, leaving the agent with insufficient information to use the tool effectively beyond basic parameter passing.

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

Parameters3/5

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

Schema description coverage is 100%, meaning all parameters are documented in the schema itself. The description doesn't add any additional meaning beyond what's in the schema (e.g., it doesn't explain how 'control_name' relates to compliance frameworks or what format 'datasource_ids' should follow beyond the schema's example). Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the action ('List') and target ('cloud resources associated with a specific compliance control'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'list_cloud_resources' or 'list_compliance_controls', which would be needed for a perfect 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/5

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. There are many sibling tools (e.g., 'list_cloud_resources', 'get_compliance_control') that might overlap in functionality, but the description offers no explicit when/when-not instructions or alternative recommendations.

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

list_cve_productsC

Get a list of all products associated with a vendor in the CVE database. Source: cve-search.org

ParametersJSON Schema

Name	Required	Description	Default
`vendor`	Yes	Vendor name to list products for

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'Get a list' but doesn't describe key behaviors: whether it's a read-only operation, how results are formatted (e.g., pagination, sorting), potential rate limits, or error handling. The source mention hints at external data but lacks operational details, leaving significant gaps for an agent to understand how to invoke it effectively.

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

Conciseness4/5

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

The description is concise with two sentences: the first states the purpose, and the second provides the source. There's no wasted language, and it's front-loaded with the core functionality. However, the source attribution, while useful, could be integrated more seamlessly, and it lacks structural elements like bullet points for clarity.

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

Completeness3/5

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

Given the tool's low complexity (single parameter, no output schema, no annotations), the description is minimally complete. It covers the basic purpose but misses behavioral details (e.g., response format, limitations) and usage context. Without annotations or output schema, the agent must infer behavior, making this adequate but with clear gaps for reliable invocation.

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

Parameters3/5

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

The input schema has 100% description coverage, with the 'vendor' parameter clearly documented as 'Vendor name to list products for'. The description adds no additional parameter semantics beyond this, such as format examples or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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

Purpose4/5

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

The description clearly states the action ('Get a list') and resource ('products associated with a vendor in the CVE database'), making the purpose understandable. It distinguishes itself from sibling tools like 'list_cve_vendors' by focusing on products rather than vendors. However, it doesn't explicitly differentiate from 'get_cve' or 'search_cves', which could be related, so it's not a perfect 5.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_cve_vendors' (for listing vendors) or 'search_cves' (which might allow product filtering), nor does it specify prerequisites or exclusions. The source attribution ('Source: cve-search.org') adds minimal context but doesn't aid in tool selection.

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

list_cve_vendorsB

Get a list of all vendors in the CVE database. Source: cve-search.org

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the data source ('cve-search.org') but doesn't describe the return format (e.g., list structure, pagination), potential rate limits, authentication needs, or error conditions. For a read-only tool with zero annotation coverage, this leaves significant gaps in understanding 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/5

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

The description is a single, efficient sentence that front-loads the core purpose ('Get a list of all vendors in the CVE database') and adds useful context about the data source. There is no wasted verbiage or redundancy, making it highly concise and well-structured.

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

Completeness3/5

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

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but not fully complete. It covers the purpose and source, but lacks details on return values, behavioral traits, or usage context. For a basic list tool, this is minimally viable but leaves room for improvement in guiding the agent effectively.

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

Parameters4/5

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

The tool has 0 parameters, and schema description coverage is 100% (as there are no parameters to describe). The description doesn't need to add parameter semantics, so it meets the baseline expectation. It appropriately avoids discussing parameters that don't exist.

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

Purpose4/5

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

The description clearly states the verb ('Get') and resource ('list of all vendors in the CVE database'), making the purpose specific and understandable. It distinguishes from some siblings like 'get_cve' or 'search_cves' by focusing on vendors rather than vulnerabilities. However, it doesn't explicitly differentiate from 'list_cve_products', which is a closely related sibling tool.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_cve_products' or 'search_cves', nor does it specify use cases, prerequisites, or exclusions. The agent must infer usage from the tool 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.

list_dashboardsB

List dashboards for the account

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of results to return (default: 10, min: 1)
`offset`	No	Pagination offset (default: 0, min: 0)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't mention any constraints like rate limits, authentication needs, or what happens if no dashboards exist. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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/5

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

The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose ('List dashboards'), making it immediately clear. Every part of the sentence earns its place by specifying the resource and scope.

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

Completeness3/5

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

For a simple list tool with 100% schema coverage and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits (due to no annotations) and usage guidelines. Given the low complexity, it's complete enough to understand what it does, but not how to use it effectively.

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

Parameters3/5

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

Schema description coverage is 100%, with both parameters ('limit' and 'offset') well-documented in the schema. The description adds no additional parameter information beyond what the schema provides, such as typical usage patterns or semantic context. Baseline 3 is appropriate when the schema handles all parameter documentation.

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

Purpose4/5

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

The description clearly states the action ('List') and resource ('dashboards'), and specifies scope ('for the account'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get_dashboard' or 'list_dashboard_templates', which would require explicit comparison to achieve a score of 5.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as 'get_dashboard' (for a single dashboard) or 'list_dashboard_templates'. The description lacks context about prerequisites, filtering options, or any explicit when/when-not instructions, leaving usage unclear beyond the basic purpose.

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

list_dashboard_templatesB

List dashboard templates with optional filtering by category

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of results to return (default: 10, min: 1)
`offset`	No	Pagination offset (default: 0, min: 0)
`category`	No	Filter by category

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It mentions 'optional filtering by category' but doesn't disclose other behavioral traits like pagination behavior (implied by limit/offset in schema), rate limits, authentication needs, error handling, or what the return format looks like. For a list tool with no annotation coverage, this is a significant gap.

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

Conciseness5/5

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

The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and includes a key feature (filtering). Every word earns its place, making it appropriately sized for a simple list tool.

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

Completeness3/5

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

Given the tool's low complexity (a list operation with filtering and pagination), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and filtering feature, but lacks details on return values, error cases, or behavioral context. It's complete enough for a simple tool but leaves gaps an agent might need.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all three parameters (limit, offset, category). The description adds minimal value by mentioning 'optional filtering by category', which aligns with the schema but doesn't provide additional syntax or format details. This meets the baseline of 3 when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the verb ('List') and resource ('dashboard templates'), and mentions optional filtering by category. It distinguishes from siblings like 'get_dashboard_template' (singular) by indicating it returns multiple items. However, it doesn't explicitly differentiate from other list tools like 'list_dashboards' or 'list_widget_templates' beyond the resource type.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, compare with similar tools like 'list_dashboards' or 'get_dashboard_template', or specify use cases. The only contextual hint is 'optional filtering by category', which is a feature but not a usage guideline.

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

list_framework_requirementsC

List all requirements for a specific compliance framework

ParametersJSON Schema

Name	Required	Description
`framework_name`	Yes	Name of the compliance framework
`datasource_ids`	Yes	Comma-separated datasource IDs (e.g. AWS Account IDs)
`page`	No	Page number starting from 1
`page_size`	No	Page size

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It doesn't mention whether this is a read-only operation, what permissions are required, whether results are paginated (though parameters suggest it), or what format the output takes. For a tool with 4 parameters and no annotations, this is inadequate 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/5

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

The description is a single, clear sentence that efficiently communicates the core purpose without any wasted words. It's appropriately sized for a straightforward listing operation and gets directly to the point.

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

Completeness2/5

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

For a tool with 4 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain the relationship between requirements and controls (relevant given sibling tools), doesn't mention pagination behavior despite having page parameters, and provides no information about output format or structure.

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

Parameters3/5

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

The description mentions 'specific compliance framework' which aligns with the 'framework_name' parameter, but adds no additional semantic context beyond what the 100% schema coverage already provides. The schema descriptions adequately explain each parameter's purpose, so the description meets the baseline without adding extra value.

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

Purpose4/5

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

The description clearly states the verb ('List') and resource ('requirements for a specific compliance framework'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_compliance_frameworks' or 'list_requirement_controls', which reduces its score from a perfect 5.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to compliance and listing operations, there's no indication of when this specific tool is appropriate versus 'list_compliance_controls' or 'list_compliance_frameworks', leaving the agent without contextual usage information.

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

list_http_requestsC

List HTTP requests insights with optional filtering by method, path, source and destination workloads, and PII detection

ParametersJSON Schema

Name	Required	Description
`filters`	No	Filter string for filtering results. Filter options: method, path, cluster_id, scheme, source_workload_name, source_workload_namespace, destination_workload_name, destination_workload_namespace,has_pii. Example: 'method:GET,path:/api/v1/users,scheme:https,source_workload_name:my-workload,source_workload_namespace:my-namespace,destination_workload_name:my-workload,destination_workload_namespace:my-namespace,has_pii:true'
`offset`	No	Offset to start the list from
`limit`	No	Limit the number of items in the list
`q`	No	Query to filter the list of HTTP requests

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While 'List' implies a read-only operation, the description doesn't address important behavioral aspects like pagination behavior (implied by offset/limit parameters but not explained), rate limits, authentication requirements, error conditions, or what format the insights are returned in. It mentions filtering but doesn't explain how filtering logic works.

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

Conciseness4/5

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

The description is a single, efficient sentence that communicates the core functionality and filtering options. It's appropriately sized for a listing tool, though it could potentially be more front-loaded by starting with the primary purpose before listing filter options. No wasted words or redundant information.

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

Completeness2/5

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

For a tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'HTTP requests insights' actually means, what data is returned, how results are structured, or provide any context about the data source or system. The description assumes too much domain knowledge and doesn't compensate for the lack of structured metadata.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description mentions filtering by method, path, source/destination workloads, and PII detection - which aligns with the 'filters' parameter documentation but doesn't add meaningful semantic context beyond what's already in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'List HTTP requests insights' with optional filtering capabilities. It specifies the resource (HTTP requests insights) and verb (list), but doesn't explicitly differentiate from sibling tools like 'list_network_connections' or 'list_security_findings' which might handle related but different data types.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It mentions filtering capabilities but doesn't specify use cases, prerequisites, or comparisons with sibling tools like 'list_network_connections' or 'radql_query' that might offer similar functionality. There's no 'when' or 'when not' context provided.

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

list_identitiesB

Get list of identities for a specific Kubernetes cluster

ParametersJSON Schema

Name	Required	Description
`identity_types`	No	Identity types to get
`cluster_ids`	No	Cluster IDs to get identities for
`page`	No	Page number to get. Default: 1
`page_size`	No	Page size to get. Default: 10
`q`	No	Query to filter identities

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'Get list' which implies a read operation, but doesn't specify whether this requires authentication, has rate limits, returns paginated results (though schema hints at pagination), or what the output format looks like. Significant behavioral details are missing.

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

Conciseness5/5

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

The description is a single, clear sentence with no wasted words. It's appropriately sized and front-loaded with the core purpose.

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

Completeness3/5

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

For a list operation with 5 parameters and no output schema, the description is minimally adequate. It states what the tool does but doesn't provide enough context about output format, authentication requirements, or how it differs from sibling tools. The high schema coverage helps, but more behavioral context would be beneficial.

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

Parameters3/5

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

Schema description coverage is 100%, so parameters are well-documented in the schema itself. The description doesn't add any meaningful parameter semantics beyond what's already in the schema descriptions, which is acceptable given the high schema coverage.

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

Purpose4/5

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

The description clearly states the action ('Get list') and resource ('identities for a specific Kubernetes cluster'), making the purpose understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'list_clusters' or 'get_identity_details', which would be needed for a score of 5.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'get_identity_details' or 'list_clusters', nor does it mention any prerequisites or contextual constraints for usage.

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

list_imagesC

List container images with optional filtering by page, page size, sort, and search query

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Number of items per page
`offset`	No	Offset to start the list from
`sort`	No	Sort order	name:asc
`filters`	No	Filter string (e.g., 'eol:ok', 'eol:reached', 'name:nginx', 'tag:1.26.0'), where eol is end of life status of the base image
`q`	No	Free text search query

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions filtering capabilities but doesn't describe pagination behavior (beyond parameter names), rate limits, authentication requirements, error conditions, or what the output looks like. This leaves significant gaps for a tool with 5 parameters.

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

Conciseness4/5

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

The description is a single, efficient sentence that front-loads the core purpose. However, it could be slightly more structured by separating the core action from the filtering options for better readability.

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

Completeness2/5

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

For a tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'container images' means in this context, what the output format is, or provide any behavioral context beyond basic parameter mentions.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning 'optional filtering by page, page size, sort, and search query' but doesn't provide additional context beyond what's in the parameter descriptions.

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

Purpose4/5

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

The description clearly states the verb ('List') and resource ('container images'), making the purpose unambiguous. However, it doesn't differentiate this tool from sibling tools like 'list_containers' or 'list_image_vulnerabilities', which would require explicit comparison to achieve a score of 5.

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

Usage Guidelines2/5

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

The description mentions optional filtering parameters but provides no guidance on when to use this tool versus alternatives like 'list_containers' or 'list_image_vulnerabilities'. There's no mention of prerequisites, typical use cases, or exclusions.

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

list_image_vulnerabilitiesB

List vulnerabilities in a container image with optional filtering by severity

ParametersJSON Schema

Name	Required	Description
`digest`	Yes	Image digest (required for vulnerabilities)
`severities`	No	List of severity levels to filter
`page`	No	Page number for pagination
`page_size`	No	Number of items per page

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool lists vulnerabilities but omits critical details like whether this is a read-only operation, if it requires specific permissions, pagination behavior (implied by parameters but not described), rate limits, or error conditions. The description is insufficient for a mutation-sensitive 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/5

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

The description is a single, efficient sentence that front-loads the core purpose ('List vulnerabilities in a container image') and adds a useful modifier ('with optional filtering by severity'). There is zero waste or redundancy.

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

Completeness3/5

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

For a tool with 4 parameters, 100% schema coverage, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks behavioral context (e.g., pagination details, error handling) and usage guidelines relative to siblings. The absence of annotations and output schema increases the need for more descriptive completeness.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all parameters (digest, severities, page, page_size). The description adds minimal value by mentioning optional filtering by severity, which aligns with the 'severities' parameter but doesn't provide additional semantics beyond what the schema already states.

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

Purpose4/5

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

The description clearly states the action ('List vulnerabilities') and resource ('in a container image'), with the optional filtering by severity adding specificity. It distinguishes itself from sibling tools like 'get_image_sbom' or 'get_top_vulnerable_images' by focusing on vulnerabilities per image, but doesn't explicitly contrast with them.

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

Usage Guidelines2/5

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

The description mentions optional filtering by severity, which provides some usage context, but lacks explicit guidance on when to use this tool versus alternatives like 'search_cves' or 'list_security_findings'. No prerequisites, exclusions, or comparative advice are provided.

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

list_inbox_itemsB

List inbox items with optional filtering by any field. Multiple filters can be combined eg. 'search:cve-2024-12345 and severity:high'

ParametersJSON Schema

Name	Required	Description
`limit`	No	Number of inbox items per page (default: 10)
`offset`	No	Offset to retrieve (default: 0)
`filters_query`	No	Filter query string (e.g. full text search: 'search:<query>', severity: 'severity:low', type 'type:workflow_output' any other field). Multiple filters can be combined eg. 'search:cve-2024-12345 and severity:high'

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions filtering capabilities and pagination via 'limit' and 'offset' parameters, but doesn't describe key behaviors like whether this is a read-only operation, potential rate limits, authentication requirements, error handling, or the format of returned items. For a list tool with no annotation coverage, this leaves significant gaps in understanding how the tool 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/5

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

The description is extremely concise—just one sentence—with zero wasted words. It front-loads the core purpose ('List inbox items with optional filtering by any field') and immediately follows with a practical example that reinforces usage. Every part of the description earns its place by providing essential information efficiently.

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

Completeness3/5

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

Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and filter syntax but lacks details on behavioral aspects like safety, performance, or output structure. Without annotations or an output schema, the description doesn't fully compensate for these gaps, leaving the agent with incomplete context for reliable tool invocation.

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

Parameters3/5

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

Schema description coverage is 100%, with each parameter well-documented in the schema itself (e.g., 'limit' for pagination, 'filters_query' for filtering). The description adds value by providing a concrete example of filter syntax ('search:cve-2024-12345 and severity:high'), which clarifies how to use the 'filters_query' parameter beyond the schema's generic description. However, it doesn't add significant semantic depth beyond what the schema already covers.

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

Purpose4/5

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

The description clearly states the verb ('List') and resource ('inbox items'), making the purpose immediately understandable. It distinguishes this tool from sibling tools like 'get_inbox_item_details' by focusing on listing with filtering rather than retrieving specific details. However, it doesn't explicitly differentiate from other list tools like 'list_cloud_resources' or 'list_containers' beyond the resource name.

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

Usage Guidelines3/5

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

The description implies usage through the mention of 'optional filtering by any field' and provides an example filter syntax, suggesting when to use this tool for filtered listing. However, it lacks explicit guidance on when to choose this over alternatives like 'get_inbox_item_details' for specific items or other list tools for different resources, and doesn't mention any prerequisites or exclusions.

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

list_k8s_resource_misconfig_policiesB

List available misconfiguration policies used by RAD Security to detect Kubernetes resource misconfigurations

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description carries the full burden but only states the basic action without disclosing behavioral traits like pagination, rate limits, authentication needs, or return format. It fails to provide essential operational context for a tool that likely returns a list of policies.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy to understand quickly.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete for a tool that likely returns a list of policies. It lacks details on behavior, output format, or error handling, leaving significant gaps in understanding how to use the tool effectively.

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

Parameters4/5

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

The input schema has 0 parameters with 100% coverage, so no parameter details are needed. The description does not add parameter semantics, but this is acceptable given the lack of parameters, aligning with the baseline for zero parameters.

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

Purpose4/5

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

The description clearly states the action ('List available') and resource ('misconfiguration policies'), specifying they are used by RAD Security for Kubernetes resource misconfigurations. However, it does not explicitly differentiate from sibling tools like 'list_k8s_resource_misconfigs', which might be similar, so it misses full 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/5

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, such as 'list_k8s_resource_misconfigs' or other listing tools. The description lacks context on prerequisites, timing, or exclusions, offering minimal usage direction.

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

list_k8s_resource_misconfigsB

Get manifest misconfigurations for a Kubernetes resource

ParametersJSON Schema

Name	Required	Description	Default
`resource_uid`	Yes	Kubernetes resource UID to get misconfigurations for

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Get') but does not specify whether this is a read-only operation, if it requires authentication, what the output format is, or any rate limits. For a tool that likely involves security or compliance checks, this lack of detail is a significant gap.

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

Conciseness5/5

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

The description is a single, clear sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and efficient, making it easy for an agent to parse quickly, with no wasted information.

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

Completeness3/5

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

Given the tool's complexity (likely involving security misconfigurations) and the absence of annotations and output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, output, or usage context, which are important for an agent to operate effectively in a Kubernetes security environment.

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

Parameters3/5

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

The input schema has 100% description coverage, with the single parameter 'resource_uid' clearly documented. The description does not add any additional meaning beyond what the schema provides, such as examples or constraints on the UID format. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.

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

Purpose4/5

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

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('manifest misconfigurations for a Kubernetes resource'), making it easy to understand what it does. However, it does not explicitly differentiate from its sibling 'get_k8s_resource_misconfig', which appears similar, leaving some ambiguity in distinguishing between them.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, such as the sibling 'get_k8s_resource_misconfig' or other related tools like 'list_k8s_resource_misconfig_policies'. It lacks context on prerequisites, exclusions, or specific scenarios, leaving the agent to infer usage based on the name alone.

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

list_k8s_resourcesC

List Kubernetes resources with optional filtering by namespace, resource types, and cluster

ParametersJSON Schema

Name	Required	Description
`namespace`	No	Namespace to filter resources
`kinds`	No	List of kinds to filter. Example: ['Deployment', 'ServiceAccount', 'Pod']
`cluster_id`	No	Cluster ID to filter resources
`page`	No	Page number for pagination
`page_size`	No	Number of items per page

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions optional filtering but doesn't disclose behavioral traits like whether this is a read-only operation, what permissions are required, whether results are paginated (though schema hints at it), rate limits, or error conditions. The description is minimal and lacks critical operational context for a Kubernetes resource listing tool.

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

Conciseness5/5

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

The description is a single, efficient sentence that front-loads the core purpose ('List Kubernetes resources') and briefly mentions the filtering capabilities. There's no wasted language or redundancy, making it easy to parse quickly.

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

Completeness2/5

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

Given the complexity of Kubernetes resources and lack of annotations or output schema, the description is insufficient. It doesn't explain what 'resources' encompasses (e.g., pods, deployments, services), how results are structured, whether all resource types are included by default, or any authentication requirements. For a tool with 5 parameters and no structured behavioral hints, more context is needed.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all 5 parameters with descriptions and defaults. The description adds minimal value by mentioning the filtering options (namespace, resource types, cluster) but doesn't provide additional semantics beyond what's in the schema. This meets the baseline for high schema coverage.

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

Purpose4/5

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

The description clearly states the action ('List') and resource ('Kubernetes resources'), and specifies optional filtering parameters. It distinguishes from siblings like 'get_k8s_resource_details' by focusing on listing with filters rather than retrieving detailed information about a specific resource. However, it doesn't explicitly contrast with other listing tools like 'list_clusters' or 'list_cloud_resources'.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when filtering is appropriate, what happens without filters, or how this differs from other listing tools like 'list_clusters' or 'list_cloud_resources'. The agent must infer usage from the tool name and parameters alone.

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

list_knowledge_base_collectionsC

List all collections in your organization's knowledge base. Collections are used to organize and categorize documents

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of collections to return. Default: 100
`offset`	No	Number of collections to skip for pagination. Default: 0

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'List all collections' but doesn't disclose pagination behavior (implied by parameters), rate limits, authentication requirements, or what the return format looks like. For a list operation with zero annotation coverage, this is inadequate.

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

Conciseness4/5

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

The description is appropriately brief with two sentences. The first sentence states the core purpose clearly, while the second adds helpful context about collections. There's no wasted verbiage, though it could be slightly more front-loaded with usage guidance.

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

Completeness3/5

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

Given the tool's low complexity (list operation with 2 optional parameters) and 100% schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it should ideally explain more about the return format or behavioral constraints to reach completeness.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents both parameters (limit and offset). The description adds no parameter-specific information beyond what's in the schema, resulting in the baseline score of 3 for adequate but no extra value.

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

Purpose4/5

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

The description clearly states the action ('List all collections') and resource ('in your organization's knowledge base'), with additional context about what collections are used for. However, it doesn't explicitly differentiate from sibling tools like 'list_knowledge_base_documents' or 'search_knowledge_base', which would require a 5.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_knowledge_base_documents' or 'search_knowledge_base', nor does it specify prerequisites or exclusions for usage.

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

list_knowledge_base_documentsC

List documents in your organization's knowledge base with optional filtering by collections, file type, or status

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of documents to return. Default: 100
`offset`	No	Number of documents to skip for pagination. Default: 0
`filters`	No	Filter documents by collections, file_type (pdf, markdown, plaintext, csv), or status (ready, processing, error) (e.g., 'collections:vuln;security,file_type:pdf,status:ready'). Multiple filters can be combined with commas.

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While 'List' implies a read operation, it doesn't address pagination behavior (implied by offset/limit parameters but not explained), rate limits, authentication requirements, or what happens when no filters are applied. The description mentions filtering capabilities but doesn't explain the tool's default behavior or limitations.

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

Conciseness4/5

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

The description is a single, efficient sentence that front-loads the core purpose and mentions key capabilities. There's no wasted language, though it could potentially be structured to separate purpose from filtering details more clearly.

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

Completeness3/5

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

For a listing tool with 100% schema coverage but no annotations or output schema, the description provides adequate basic context about what's being listed and filtering options. However, it lacks important behavioral details about pagination, default ordering, error conditions, and relationship to sibling tools that would make it more complete for agent use.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds marginal value by mentioning the filtering options (collections, file type, status) but doesn't provide additional semantic context beyond what's in the parameter descriptions. This meets the baseline for high schema coverage.

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

Purpose4/5

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

The description clearly states the verb 'List' and resource 'documents in your organization's knowledge base', making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like 'list_knowledge_base_collections' or 'search_knowledge_base', but the resource focus is specific enough for basic differentiation.

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

Usage Guidelines2/5

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

The description mentions optional filtering capabilities but provides no guidance on when to use this tool versus alternatives like 'search_knowledge_base' or 'query_knowledge_base_document'. There's no mention of prerequisites, typical use cases, or when this listing approach is preferable to search functionality.

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

list_network_connectionsC

List network connections with optional filtering

ParametersJSON Schema

Name	Required	Description
`filters`	No	Filter string for filtering results.Filter options: source_workload_name, source_workload_namespace, destination_workload_name, destination_workload_namespace, cluster_id. Example: 'source_workload_name:my-workload,destination_workload_name:my-workload,cluster_id:my-cluster'
`limit`	No	Limit the number of items in the list
`q`	No	Query to filter the list of network connections

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions optional filtering but doesn't disclose behavioral traits like pagination, rate limits, authentication needs, or what 'list' entails (e.g., real-time vs. cached data, ordering). For a tool with no annotation coverage, this leaves significant gaps in understanding its operation.

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

Conciseness4/5

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

The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action ('list network connections') and includes a key feature ('optional filtering'). However, it could be slightly more structured by explicitly noting it's a read operation or basic usage context.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete for a tool with 3 parameters and potential complexity. It lacks details on return values, error handling, or behavioral constraints. For a listing tool in a security/network context, more context on data freshness, scope, or limitations would be beneficial.

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

Parameters3/5

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

Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds minimal value by mentioning 'optional filtering,' which aligns with the 'filters' and 'q' parameters but doesn't provide additional semantics beyond what the schema already explains. Baseline 3 is appropriate as the schema does the heavy lifting.

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

Purpose3/5

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

The description states the verb ('list') and resource ('network connections'), which provides a basic purpose. However, it's vague about scope and doesn't distinguish from sibling tools like 'list_network_connection_srcs' or 'list_http_requests' that might handle related network data. The optional filtering mention adds some specificity but remains general.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. With many sibling tools for listing various resources (e.g., 'list_http_requests', 'list_network_connection_srcs'), the description lacks context on differentiation, prerequisites, or exclusions. It merely states the action without situational advice.

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

list_network_connection_srcsC

List network connection sources with optional filtering by source and destination workloads

ParametersJSON Schema

Name	Required	Description
`filters`	No	Filter string for filtering results.Filter options: source_workload_name, source_workload_namespace, destination_workload_name, destination_workload_namespace, cluster_id.Example: 'source_workload_name:my-workload,destination_workload_name:my-workload,cluster_id:my-cluster'
`offset`	No	Offset to start the list from
`limit`	No	Limit the number of items in the list
`q`	No	Query to filter the list of network connection sources

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure but provides minimal information. It mentions filtering capabilities but doesn't describe what 'list' means operationally - whether this is a read-only operation, what format results come in, whether there are rate limits, authentication requirements, or pagination behavior beyond the offset/limit parameters. For a tool with 4 parameters and no annotation coverage, this is inadequate.

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

Conciseness5/5

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

The description is a single, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized for what it does convey, though it could benefit from additional context.

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

Completeness2/5

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

For a tool with 4 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what a 'network connection source' is, what data is returned, how results are structured, or any operational constraints. The agent would need to guess about the tool's behavior and output format.

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

Parameters3/5

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

The description mentions 'optional filtering by source and destination workloads' which corresponds to the 'filters' parameter, but doesn't add meaningful information beyond what's already in the schema descriptions. With 100% schema description coverage, the baseline is 3 - the description doesn't compensate for any gaps because there are none, but also doesn't add significant value beyond the schema.

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

Purpose4/5

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

The description clearly states the verb 'List' and resource 'network connection sources', making the purpose specific and understandable. It also mentions optional filtering capabilities, which adds useful detail. However, it doesn't explicitly distinguish this tool from sibling tools like 'list_network_connections' or 'list_http_requests', which might have overlapping functionality.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, specific contexts where this tool is appropriate, or how it differs from related tools like 'list_network_connections' or 'list_http_requests' that appear in the sibling list.

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

list_requirement_controlsB

List controls associated with a specific requirement within a compliance framework

ParametersJSON Schema

Name	Required	Description
`framework_name`	Yes	Name of the compliance framework
`requirement_id`	Yes	ID of the requirement within the framework
`datasource_ids`	Yes	Comma-separated datasource IDs (e.g. AWS Account IDs)
`page`	No	Page number starting from 1
`page_size`	No	Page size

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'List' implies a read-only operation, it doesn't specify whether this is a safe query, if it requires authentication, what the output format looks like, or if there are rate limits. For a tool with 5 parameters and no annotation coverage, this leaves significant gaps in understanding its 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/5

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

The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence contributes directly to understanding what the tool does, making it highly concise and well-structured.

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

Completeness3/5

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

Given the complexity (5 parameters, no annotations, no output schema), the description is minimally adequate but incomplete. It states the purpose clearly but lacks behavioral details, usage context, and output information, which are crucial for an agent to use this tool effectively in a server with many similar listing tools.

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

Parameters3/5

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

The schema description coverage is 100%, meaning all parameters are documented in the input schema itself. The description adds no additional parameter semantics beyond what's already in the schema (e.g., it doesn't explain the relationship between 'framework_name' and 'requirement_id' or provide examples for 'datasource_ids'). Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the action ('List') and target ('controls associated with a specific requirement within a compliance framework'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_compliance_controls' or 'list_framework_requirements', which might have overlapping functionality in the same domain.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools in the compliance and listing categories (e.g., 'list_compliance_controls', 'list_framework_requirements'), there's no indication of context, prerequisites, or exclusions to help an agent choose appropriately.

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

list_security_findingsC

List security findings with optional filtering by types, severities, sources, and status

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Number of findings to return
`types`	No	List of finding types to filter by
`severities`	No	List of severity levels to filter by
`source_kinds`	No	List of source kinds to filter by. i.e. Deployment,Pod,Container,Node,etc.
`source_types`	No	List of source types to filter by
`source_names`	No	List of source names to filter by
`source_namespaces`	No	List of source namespaces to filter by
`status`	No	Status of the findings to filter by	open
`from_time`	No	From time in RFC3339 or relative format, i.e. now-7d	now-7d
`to_time`	No	To time in RFC3339 or relative format, i.e. now-7d

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While 'List' implies a read operation, it doesn't address important behavioral aspects: whether results are paginated (the 'limit' parameter suggests they might be), default sorting, rate limits, authentication requirements, or what the response structure looks like. For a tool with 10 parameters and no output schema, this is a significant gap.

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

Conciseness5/5

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

The description is a single, efficient sentence that states the core functionality upfront. Every word earns its place: 'List security findings' establishes the purpose, and 'with optional filtering by types, severities, sources, and status' adds necessary context without redundancy. No wasted words or unnecessary elaboration.

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

Completeness2/5

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

For a tool with 10 parameters, no annotations, and no output schema, the description is insufficient. While concise, it doesn't address critical context: response format, pagination behavior, error conditions, or how the various filter parameters interact. The agent would need to guess about the return structure and operational characteristics despite the tool's complexity.

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

Parameters3/5

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

The description mentions filtering by 'types, severities, sources, and status' which maps to some parameters (types, severities, source_kinds/source_types/source_names/source_namespaces, status). However, with 100% schema description coverage, the schema already documents all 10 parameters thoroughly. The description adds minimal value beyond what's in the schema - it doesn't explain parameter interactions, precedence, or provide usage examples.

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

Purpose4/5

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

The description clearly states the verb ('List') and resource ('security findings'), making the purpose unambiguous. It also mentions optional filtering capabilities, which adds specificity. However, it doesn't explicitly differentiate this tool from sibling tools like 'list_threat_vectors' or 'list_k8s_resource_misconfigs' that might overlap in security domain.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools in the security/compliance domain (like list_threat_vectors, list_k8s_resource_misconfigs, list_image_vulnerabilities), there's no indication of scope boundaries, prerequisites, or comparative use cases. The agent must infer usage context from tool names alone.

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

list_threat_vectorsD

List threat vectors

ParametersJSON Schema

Name	Required	Description
`clustersIds`	No	Cluster ids to check for threat vectors
`namespaces`	No	Namespaces to check for threat vectors
`resource_uid`	No	Threat vector associated with this resource
`page`	No	Page number to retrieve
`page_size`	No	Number of items per page

TDQS

D1.7/5.0

Behavior1/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure but offers none. It doesn't indicate whether this is a read-only operation, whether it requires authentication, what rate limits might apply, what format the results come in, or whether the listing is paginated (though pagination parameters exist in the schema). For a tool with 5 parameters and no annotation coverage, this is critically insufficient.

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

Conciseness2/5

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

While technically concise with just two words, this represents under-specification rather than effective conciseness. The description doesn't earn its place by providing necessary context. Good conciseness balances brevity with information density, but here there's insufficient information to justify even the minimal length.

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

Completeness1/5

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

Given the complexity (5 parameters, no annotations, no output schema) and the rich sibling tool ecosystem, the description is completely inadequate. It doesn't explain what threat vectors are in this context, how they relate to other resources, what the output looks like, or any behavioral characteristics. For a tool that presumably returns security-related data, this leaves the agent with insufficient guidance.

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

Parameters3/5

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

The schema description coverage is 100%, so all parameters are documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter information in the description, which applies here.

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

Purpose2/5

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

The description 'List threat vectors' is a tautology that merely restates the tool name without adding meaningful context. It doesn't specify what threat vectors are in this system, what format they come in, or what scope is covered. While it does contain a verb ('List') and resource ('threat vectors'), it lacks the specificity needed to distinguish this from similar listing tools in the sibling set.

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

Usage Guidelines1/5

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

The description provides absolutely no guidance on when to use this tool versus alternatives. With numerous sibling tools like list_security_findings, list_cloud_resources, and list_k8s_resources, there's no indication of how threat vectors relate to these other resources or when an agent should choose this specific listing tool. No prerequisites, context, 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.

list_widget_templatesC

List widget templates with optional filtering by visualization type and category

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of results to return (default: 10, min: 1)
`offset`	No	Pagination offset (default: 0, min: 0)
`visualization_type`	No	Filter by visualization type
`category`	No	Filter by category

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. While 'List' implies a read operation, the description doesn't address critical behaviors like pagination (though hinted by parameters), rate limits, authentication requirements, error conditions, or return format. For a tool with 4 parameters and no output schema, this leaves significant gaps in understanding how the tool 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/5

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

The description is a single, efficient sentence that front-loads the core purpose ('List widget templates') and immediately adds the key filtering capabilities. There's zero wasted language, and every word earns its place by conveying essential information.

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

Completeness2/5

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

Given the tool's complexity (4 parameters, no output schema, no annotations), the description is insufficient. It doesn't explain what a 'widget template' is in this context, how results are structured, whether ordering is applied, or any side effects. For a list operation with filtering and pagination, more context is needed to use it effectively.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description mentions filtering by visualization type and category, which maps to two parameters, but adds no additional semantic context beyond what the schema provides (e.g., examples of valid types/categories). This meets the baseline for high schema coverage.

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

Purpose4/5

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

The description clearly states the verb ('List') and resource ('widget templates'), making the purpose immediately understandable. It also mentions optional filtering by visualization type and category, which adds specificity. However, it doesn't explicitly differentiate this tool from similar sibling tools like 'get_widget_template' or 'list_dashboard_templates', preventing a perfect 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/5

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. With sibling tools like 'get_widget_template' (likely for retrieving a single template) and 'list_dashboard_templates' (for a different resource type), the agent receives no help in choosing between them. There's no mention of prerequisites, typical use cases, or exclusions.

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

list_workflow_runsC

List workflow runs with optional filtering by workflow ID

ParametersJSON Schema

Name	Required	Description	Default
`workflow_id`	Yes	ID of the workflow to list runs for

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only states the basic action with optional filtering. It doesn't disclose behavioral traits such as whether this is a read-only operation, pagination behavior, rate limits, authentication requirements, or what the output format looks like (especially critical since there's no output schema).

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

Conciseness5/5

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

The description is a single, efficient sentence that front-loads the core purpose ('List workflow runs') and includes the key detail about filtering. There's no wasted language, making it appropriately sized for a simple tool.

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

Completeness2/5

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

Given the complexity (a list operation with filtering), lack of annotations, and absence of an output schema, the description is insufficient. It doesn't explain what a 'workflow run' entails, how results are returned (e.g., pagination, format), or error conditions, leaving significant gaps for an AI 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/5

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

The description mentions 'optional filtering by workflow ID,' which aligns with the single parameter 'workflow_id' in the schema. Since schema description coverage is 100% (the parameter is fully documented in the schema), the description adds minimal value beyond what's already structured, meeting the baseline score of 3.

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

Purpose4/5

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

The description clearly states the action ('List workflow runs') and resource ('workflow runs'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'get_workflow_run' (singular) or 'list_workflows', which list workflows rather than runs.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_workflow_run' (for a single run) or 'run_workflow' (to execute a workflow), nor does it specify prerequisites or exclusions for usage.

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

list_workflowsB

List all workflows

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. 'List all workflows' implies a read-only operation but doesn't disclose behavioral traits like pagination, rate limits, authentication needs, or what 'all' entails (e.g., scope, filters). It's minimal and lacks critical context 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.

Conciseness5/5

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

The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, achieving ideal conciseness.

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

Completeness2/5

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 a simple zero-parameter tool, the description is incomplete. It doesn't explain what 'list' returns (e.g., format, fields) or behavioral aspects like ordering or limits. For a tool in a security/compliance context with many siblings, more context would help the agent use it correctly.

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

Parameters4/5

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but that's appropriate here. Baseline is 4 for zero-parameter tools, as the schema fully covers the absence of inputs.

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

Purpose4/5

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

The description 'List all workflows' clearly states the verb ('List') and resource ('workflows'), making the purpose immediately understandable. It distinguishes from siblings like 'get_workflow' (singular) and 'list_workflow_runs' (different resource). However, it lacks specificity about scope or format, preventing a perfect 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/5

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 doesn't mention prerequisites, context, or differences from siblings like 'get_workflow' or 'run_workflow'. The agent must infer usage solely from the tool name and description.

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

list_workflow_schedulesC

List workflow schedules with optional filtering by workflow ID

ParametersJSON Schema

Name	Required	Description	Default
`workflow_id`	Yes	ID of the workflow to list schedules for

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states the action ('List') but lacks behavioral details such as whether this is a read-only operation, what the output format includes (e.g., pagination, sorting), or any rate limits. The description is minimal and does not compensate for the absence of annotations.

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

Conciseness5/5

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

The description is a single, efficient sentence that front-loads the core purpose ('List workflow schedules') and includes the key detail about filtering. There is no wasted verbiage, making it appropriately concise and well-structured.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete. It covers the basic action and parameter but lacks essential context such as what the output looks like, whether it's a safe read operation, or any behavioral traits. For a tool with one parameter but no structured support, more detail is needed to be fully helpful.

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

Parameters3/5

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

The input schema has 100% description coverage, with the parameter 'workflow_id' documented as 'ID of the workflow to list schedules for'. The description adds marginal value by noting it's for 'optional filtering', but does not provide additional semantics beyond what the schema already specifies. Baseline 3 is appropriate given high schema coverage.

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

Purpose4/5

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

The description clearly states the verb ('List') and resource ('workflow schedules'), making the purpose evident. It distinguishes this tool from siblings like 'list_workflows' or 'list_workflow_runs' by specifying schedules, but does not explicitly contrast with other list tools in the server.

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

Usage Guidelines2/5

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

The description mentions optional filtering by workflow ID, implying usage when schedules for a specific workflow are needed, but provides no explicit guidance on when to use this tool versus alternatives like 'get_workflow' or 'list_workflows'. No exclusions or prerequisites are stated.

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

mark_inbox_item_as_false_positiveC

Mark an inbox item as a false positive with a reason

ParametersJSON Schema

Name	Required	Description
`inbox_item_id`	Yes	ID of the inbox item to mark as false positive
`value`	No	Whether to mark the item as false positive (true) or not (false)
`reason`	Yes	Reason for marking the item as false positive

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool performs a mutation ('mark'), implying it changes system state, but doesn't describe side effects (e.g., whether the item is removed from inbox, if the action is reversible, or permission requirements). For a mutation tool, this lack of behavioral context is a significant gap.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.

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

Completeness2/5

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

For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects (e.g., side effects, permissions), usage context, or what the tool returns. Given the complexity of a state-changing operation, more information is needed to help the agent use it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all three parameters (inbox_item_id, value, reason). The description adds no additional parameter semantics beyond what's in the schema, such as format examples for 'reason' or clarification on the 'value' parameter's default behavior. Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the action ('mark as false positive') and target resource ('inbox item'), making the purpose immediately understandable. However, it doesn't differentiate this tool from any siblings since all other tools appear to be read-only queries or different operations, so it misses the opportunity to explicitly contrast with tools like 'update_security_finding_status' which might serve a similar status-update function.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an inbox item ID from 'list_inbox_items' or 'get_inbox_item_details'), nor does it clarify scenarios where marking as false positive is appropriate versus other status updates. This leaves the agent without context for tool selection.

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

query_knowledge_base_documentA

Query a CSV document from the knowledge base using natural language. IMPORTANT: This tool ONLY works with CSV documents. Use list_knowledge_base_documents with filters='file_type:csv' to find CSV document IDs (search_knowledge_base results also contain document IDs). Results are returned as a markdown table

ParametersJSON Schema

Name	Required	Description	Default
`document_id`	Yes	The ID of the CSV document to query. Use list_knowledge_base_documents with filters='file_type:csv' to find CSV document IDs. Document IDs are also available in search_knowledge_base results. This will fail if the document is not a CSV file.
`query`	Yes	Natural language question to execute against the CSV document. The system will analyze the CSV structure and generate the appropriate query (e.g., 'Show me all rows where severity is critical', 'Count the number of vulnerabilities by type', 'Show me the owner of asset IKM99832').

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool is query-only (implied by 'Query'), it has a strict input requirement (CSV documents only), it processes natural language queries, and it returns results as markdown tables. It doesn't mention error handling, rate limits, or authentication needs, but covers the core operational behavior well.

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

Conciseness5/5

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

The description is efficiently structured with three sentences that each serve a distinct purpose: stating the core function, specifying the CSV-only constraint with prerequisite guidance, and describing the output format. There's no wasted text, and important information is front-loaded with 'IMPORTANT' emphasis.

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

Completeness4/5

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

Given the tool's moderate complexity (2 required parameters, no output schema, no annotations), the description provides good coverage. It explains what the tool does, when to use it, how to prepare inputs, and what format results will take. The main gap is lack of output schema documentation, but the description compensates by specifying 'Results are returned as a markdown table.'

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds some context about document_id sourcing (list_knowledge_base_documents with CSV filter) and query examples, but doesn't provide significant additional semantic meaning beyond what's in the schema descriptions. This meets the baseline expectation when schema coverage is complete.

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

Purpose5/5

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

The description clearly states the tool's purpose: 'Query a CSV document from the knowledge base using natural language.' It specifies the exact resource (CSV document), the action (query with natural language), and distinguishes it from siblings by emphasizing it ONLY works with CSV documents, not other document types.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool: 'This tool ONLY works with CSV documents.' It also specifies prerequisites: 'Use list_knowledge_base_documents with filters='file_type:csv' to find CSV document IDs (search_knowledge_base results also contain document IDs).' This clearly tells the agent how to obtain the required document_id parameter.

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

radql_batch_queryA

Execute multiple RadQL queries in parallel for efficiency. Useful for fetching related data from different data types simultaneously (e.g., container details + vulnerabilities + network connections).

ParametersJSON Schema

Name	Required	Description	Default
`queries`	Yes	Array of queries to execute in parallel (max 10)

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the parallel execution efficiency benefit and provides a concrete example use case. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, potential rate limits, error handling for partial failures, or what the output format looks like (especially critical since there's no output schema).

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

Conciseness5/5

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

The description is perfectly concise and well-structured with just two sentences. The first sentence states the core functionality, and the second provides a concrete use case example. Every word earns its place with zero redundancy or unnecessary elaboration.

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

Completeness3/5

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

Given the complexity (batch query execution with nested parameter structure) and the absence of both annotations and output schema, the description is somewhat incomplete. While it explains the 'why' (efficiency for related data fetching), it doesn't address critical contextual information like expected return format, error behavior, or performance considerations. The description should do more to compensate for the lack of structured metadata.

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

Parameters3/5

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

The schema description coverage is 100%, so the schema already fully documents the single 'queries' parameter and its nested structure. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 is appropriate when the schema does all the parameter documentation work.

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

Purpose5/5

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

The description clearly states the tool's purpose: 'Execute multiple RadQL queries in parallel for efficiency.' It specifies the verb ('execute'), resource ('RadQL queries'), and key behavior ('in parallel'). It also distinguishes from siblings by explaining this is for batch/parallel execution rather than single queries, unlike tools like 'radql_query' or 'radql_query_builder'.

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

Usage Guidelines4/5

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

The description provides clear context for when to use this tool: 'Useful for fetching related data from different data types simultaneously (e.g., container details + vulnerabilities + network connections).' This gives a specific use case scenario. However, it doesn't explicitly state when NOT to use it or mention alternatives like the single-query 'radql_query' tool, which would be helpful for complete guidance.

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

radql_get_type_metadataA

Get schema/metadata for a specific RadQL data type. Shows available fields, data types, which fields can be filtered/searched, and provides query examples. Call this AFTER radql_list_data_types to understand how to query a specific data type.

ParametersJSON Schema

Name	Required	Description	Default
`data_type`	Yes	The data type to get metadata for (e.g., 'containers', 'kubernetes_resources', 'inbox_items'). Call radql_list_data_types first to see available types.

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description effectively communicates that this is a read-only metadata retrieval operation (implied by 'Get schema/metadata' and the instructional context), but doesn't mention potential limitations like rate limits, authentication requirements, or error conditions. It adds useful context about the tool's role in a workflow, but lacks comprehensive behavioral 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/5

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

The description is perfectly concise with two sentences that each serve a clear purpose: the first states what the tool does and what information it provides, the second gives crucial usage guidance. There's zero wasted language, and the information is front-loaded with the core functionality before the usage instructions.

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

Completeness4/5

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

For a single-parameter read operation with no output schema, the description provides excellent context about what information is returned and how to use the tool in the broader workflow. The main gap is the lack of output format details (though the description mentions what types of information are returned), but given the tool's relative simplicity and clear purpose, the description is nearly complete for agent usage.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already fully documents the single parameter. The description doesn't add any parameter-specific information beyond what's in the schema (which includes the same guidance about calling radql_list_data_types first). The description's value lies in workflow context rather than parameter semantics, meeting the baseline expectation when schema coverage is complete.

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

Purpose5/5

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

The description clearly states the specific action ('Get schema/metadata') and resource ('for a specific RadQL data type'), and distinguishes it from siblings by specifying it should be called AFTER radql_list_data_types. It explicitly mentions what information is provided ('available fields, data types, which fields can be filtered/searched, and provides query examples'), making the purpose unambiguous and distinct from other tools.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool ('Call this AFTER radql_list_data_types to understand how to query a specific data type'), including a prerequisite step and sequencing information. It clearly indicates the relationship with another tool (radql_list_data_types) and the specific context for usage, leaving no ambiguity about the appropriate timing for invocation.

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

radql_list_data_typesA

List all available RadQL data types (discovery). ALWAYS call this FIRST before using other RadQL tools to discover what data is available to query. Returns data types like 'containers', 'kubernetes_resources', 'inbox_items', 'vulnerabilities', etc. with descriptions.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It describes the return format (data types with descriptions) and examples, which is helpful. However, it lacks details on potential rate limits, authentication needs, or error behaviors, which are important for a discovery tool in a query system.

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

Conciseness5/5

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

Two sentences with zero waste: the first states the purpose and critical usage rule, the second details the return format with examples. It is front-loaded with the most important information (the 'ALWAYS call FIRST' directive) and avoids redundancy.

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

Completeness4/5

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

Given the tool's simplicity (0 parameters, no output schema), the description is nearly complete. It covers purpose, usage, and return format. The only gap is lack of behavioral details like error handling or performance, but for a discovery tool with no inputs, this is minor.

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

Parameters4/5

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

The tool has 0 parameters, and the schema description coverage is 100% (though empty). The description adds value by reinforcing the 'no parameters needed' context and emphasizing the discovery purpose, which compensates for the lack of parameters. A baseline of 4 is appropriate as it clearly communicates the simplicity of invocation.

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

Purpose5/5

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

The description clearly states the verb ('List') and resource ('RadQL data types') with specific scope ('all available'). It distinguishes from siblings by focusing on discovery of data types rather than querying or fetching specific data, making its purpose unambiguous.

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

Usage Guidelines5/5

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

Explicitly states 'ALWAYS call this FIRST before using other RadQL tools to discover what data is available to query,' providing clear when-to-use guidance and naming the alternative tools (other RadQL tools). This is a strong directive that leaves no ambiguity about its role in the workflow.

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

radql_list_filter_valuesA

List possible values for a filter field (e.g., namespace list, cluster list, severity values). Useful for building dynamic filters when you need to know available enum-like values. Call this when constructing filters that need specific values.

ParametersJSON Schema

Name	Required	Description	Default
`data_type`	Yes	The data type (e.g., 'containers', 'kubernetes_resources')
`filter_name`	Yes	The filter field name to get possible values for (e.g., 'namespace', 'cluster_id', 'severity')

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool's function as listing values for filter fields, which implies a read-only, non-destructive operation, but doesn't explicitly state this or cover other behavioral aspects like rate limits, authentication needs, or error handling. The description adds some context about dynamic filter building, but lacks depth on operational traits.

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

Conciseness5/5

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

The description is concise and front-loaded, consisting of two sentences that directly state the purpose and usage without any fluff. Every sentence earns its place by providing essential information, making it efficient and well-structured for quick understanding.

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

Completeness3/5

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

Given the tool's moderate complexity (2 required parameters, no output schema, and no annotations), the description is somewhat complete but has gaps. It explains what the tool does and when to use it, but lacks details on return values (since no output schema exists) and behavioral aspects like permissions or limitations. This makes it adequate but not fully comprehensive for an agent to invoke it confidently.

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

Parameters3/5

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

The schema description coverage is 100%, with both parameters ('data_type' and 'filter_name') well-documented in the input schema. The description adds minimal value beyond this, mentioning examples like 'namespace, cluster_id, severity' but not providing additional syntax or format details. According to the rules, with high schema coverage, the baseline is 3 even without extra param info in the description.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'List possible values for a filter field' with examples like 'namespace list, cluster list, severity values.' It specifies the verb ('List') and resource ('possible values for a filter field'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'radql_list_data_types' or 'get_cloud_resource_facets,' which might have overlapping purposes, so it doesn't reach a perfect score.

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

Usage Guidelines4/5

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

The description provides clear context on when to use this tool: 'Useful for building dynamic filters when you need to know available enum-like values' and 'Call this when constructing filters that need specific values.' This gives practical guidance on its application. However, it doesn't specify when not to use it or name alternative tools (e.g., vs. 'radql_list_data_types'), which prevents a score of 5.

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

radql_queryA

Execute RadQL queries for security investigations. Supports: list (filter/search), get_by_id (single item), stats (aggregations).

WORKFLOW: radql_list_data_types -> radql_get_type_metadata -> radql_query

COMMON FIELDS BY DATA TYPE: containers: name, image_name, image_repo, owner_kind, cluster_id, created_at Example: image_name:nginx AND owner_kind:Pod

finding_groups: type, source_kind, source_name, rule_title, severity, event_timestamp Types: k8s_misconfiguration, k8s_audit_logs_anomaly, threat_vector Example: type:k8s_misconfiguration AND severity:critical

inbox_items: severity (High|Medium|Low), type, title, archived, false_positive, created_at Example: severity:High AND archived:false

kubernetes_resources: kind, name, namespace, cluster_id, owner_kind, created_at Example: kind:Deployment AND namespace:production

CRITICAL QUOTING RULES: MUST quote when value contains:

Dates/timestamps: created_at>"2024-01-01" (NOT created_at>2024-01-01)
Hyphens: cluster_id:"abc-123-def", name:"kube-system"
UUIDs: id:"550e8400-e29b-41d4-a716-446655440000"
Spaces: title:"my alert"
Special chars: :, =, <, >, !, (, )
Wildcards with hyphens: name:"kube-*"

OK to leave unquoted:

Simple strings: status:active, kind:Pod
Numbers: count:123
Booleans: archived:true
Simple wildcards: name:nginx*

For complete schema: call radql_get_type_metadata with target data_type

ParametersJSON Schema

Name	Required	Description
`data_type`	Yes	The data type to query (e.g., 'containers', 'kubernetes_resources', 'inbox_items'). Use radql_list_data_types to discover available types.
`operation`	Yes	The operation to perform: 'list' for filtering/searching, 'get_by_id' for single item, 'stats' for aggregations
`filters_query`	No	RadQL filter query (e.g., 'severity:High AND type:misconfiguration'). Used for filtering results.
`stats_query`	No	RadQL analytics query (e.g., 'count() by severity'). Used for aggregations and grouping.
`id`	No	The ID of a specific item to retrieve (for get_by_id operation)
`limit`	No	Maximum number of results to return
`offset`	No	Pagination offset
`include_relations`	No	Relations to include (e.g., ['owner'] for containers to include Kubernetes owner resource)

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes critical behavioral traits: it explains the query language syntax, provides examples, details quoting rules for values, and outlines common fields by data type. However, it doesn't mention rate limits, authentication needs, or error handling, which are important for a query tool.

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

Conciseness4/5

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

The description is well-structured with sections for purpose, workflow, common fields, examples, and quoting rules, making it easy to scan. However, it is quite lengthy due to the detailed examples and rules, which may be necessary but could be optimized. Every sentence adds value, but the front-loading could be improved by summarizing key points first.

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

Completeness4/5

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

Given the complexity of the tool (8 parameters, no annotations, no output schema), the description is mostly complete. It covers purpose, usage, examples, and critical syntax rules. However, it lacks details on output format, error cases, or performance considerations, which would enhance completeness for such a versatile query tool.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds some value by providing context on how parameters like 'filters_query' and 'stats_query' are used with examples, but it doesn't add significant semantic details beyond what the schema provides. The baseline of 3 is appropriate when 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/5

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

The description clearly states the tool's purpose: 'Execute RadQL queries for security investigations.' It specifies the supported operations (list, get_by_id, stats) and distinguishes it from siblings by focusing on RadQL query execution rather than specific resource retrieval like the many 'get_' and 'list_' tools. The description provides a specific verb ('Execute') and resource ('RadQL queries') with clear scope.

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

Usage Guidelines5/5

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

The description explicitly provides usage guidance: it outlines a workflow ('radql_list_data_types -> radql_get_type_metadata -> radql_query'), mentions when to use alternatives ('For complete schema: call radql_get_type_metadata'), and distinguishes operations within the tool (list vs. get_by_id vs. stats). This gives clear context on when and how to use this tool versus others.

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

radql_query_builderB

Helper tool to build RadQL queries programmatically from structured conditions. Useful when you need to construct complex filter or stats queries from structured inputs.

ParametersJSON Schema

Name	Required	Description	Default
`data_type`	Yes	The data type to build a query for
`conditions`	No	Filter conditions to combine into a RadQL query
`logic`	No	Logical operator to combine conditions	AND
`aggregation`	No	Aggregation function to apply
`aggregate_field`	No	Field to aggregate (omit for count(*))
`group_by`	No	Fields to group by
`time_group`	No	Time-based grouping interval for datetime fields

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool is a 'Helper tool' for 'building' queries, which implies it's a read-only, non-destructive operation that generates query strings. However, it doesn't disclose important behavioral traits such as whether it validates inputs, returns errors for invalid conditions, or outputs a query string versus an executable object. For a tool with 7 parameters and no annotations, this is a significant gap.

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

Conciseness4/5

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

The description is concise and front-loaded, consisting of two sentences that directly state the tool's purpose and utility. There's no wasted verbiage or redundancy. However, it could be slightly more structured by explicitly mentioning key parameters or output format.

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

Completeness3/5

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

Given the tool's complexity (7 parameters, no annotations, no output schema), the description is minimally adequate. It clarifies the tool's role as a query builder, which distinguishes it from execution tools in the sibling list. However, it lacks details on behavioral traits, output format (e.g., whether it returns a query string or structured object), and explicit guidance on when to use versus siblings. With no output schema, the description should ideally explain the return value.

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

Parameters3/5

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

The description adds minimal parameter semantics beyond the schema. It mentions 'structured conditions' and 'complex filter or stats queries,' which loosely map to the 'conditions' and 'aggregation' parameters. However, with 100% schema description coverage, the schema already documents all 7 parameters thoroughly, including enums and defaults. The description doesn't add meaningful details about parameter interactions or usage examples, so the baseline 3 is appropriate.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'build RadQL queries programmatically from structured conditions.' It specifies the verb ('build') and resource ('RadQL queries'), and mentions use cases ('complex filter or stats queries'). However, it doesn't explicitly differentiate from sibling tools like 'radql_query' or 'radql_batch_query', which appear to execute queries rather than build them.

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

Usage Guidelines3/5

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

The description provides implied usage guidance: 'Useful when you need to construct complex filter or stats queries from structured inputs.' This suggests it's for constructing queries, not executing them. However, it doesn't explicitly state when to use this tool versus alternatives like 'radql_query' (which likely executes queries) or 'radql_batch_query', nor does it 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.

run_workflowC

Run a workflow with optional argument overrides

ParametersJSON Schema

Name	Required	Description
`workflow_id`	Yes	ID of the workflow to run
`async`	No	If true, run asynchronously and return immediately. If false, wait for the workflow to finish.
`args`	No	Optional arguments to override when running the workflow

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It mentions 'run' and 'optional argument overrides,' but lacks critical behavioral details: whether this is a mutation (likely yes), what permissions are required, if it's idempotent, rate limits, error handling, or what happens on success/failure. This is inadequate for a tool that likely modifies state.

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

Conciseness5/5

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

The description is a single, efficient sentence with zero waste—it states the core action and key feature (argument overrides) without fluff. It's appropriately sized and front-loaded, making it easy to parse quickly.

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

Completeness2/5

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

Given the tool likely performs mutations (running workflows) with no annotations and no output schema, the description is incomplete. It doesn't explain return values, error cases, or behavioral traits needed for safe invocation. For a 3-parameter tool in a complex domain (workflow execution), this leaves significant gaps.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents parameters (workflow_id, async, args). The description adds minimal value by implying 'args' are for overrides, but doesn't clarify syntax, format, or constraints beyond what the schema provides. Baseline 3 is appropriate as the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the action ('run') and resource ('workflow'), specifying it executes a workflow with optional argument overrides. It distinguishes from sibling tools like 'get_workflow' (which retrieves) and 'list_workflows' (which lists), but could be more specific about what 'run' entails (e.g., execution vs. scheduling).

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing workflow ID), compare to siblings like 'get_workflow_run' or 'list_workflow_runs', or specify contexts (e.g., for automation vs. testing).

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

search_cvesC

Search CVEs by vendor and optionally product. Source: cve-search.org

ParametersJSON Schema

Name	Required	Description	Default
`vendor`	Yes	Vendor name to search for
`product`	No	Product name to search for

TDQS

C2.9/5.0

Behavior2/5

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 mentions the data source ('cve-search.org') without detailing behavioral traits like pagination, rate limits, error handling, or response format. For a search tool with zero annotation coverage, this is inadequate.

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

Conciseness4/5

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

The description is concise and front-loaded in a single sentence, with no wasted words. However, it could be slightly more structured by separating the source attribution into a second sentence for better clarity.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, response format, and usage context. For a search tool with many siblings, more guidance is needed to help an agent use it effectively.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents both parameters. The description adds marginal value by emphasizing that 'product' is optional, but doesn't provide additional semantics beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the tool's purpose: searching CVEs by vendor and optionally product. It specifies the verb 'search' and resource 'CVEs' with filtering criteria. However, it doesn't explicitly differentiate from sibling tools like 'get_cve' or 'get_latest_30_cves', which prevents a perfect 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/5

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

The description provides minimal guidance: it mentions the optional 'product' parameter but doesn't explain when to use this tool versus alternatives like 'get_cve' or 'list_cve_vendors'. No context about use cases, prerequisites, or exclusions is provided.

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

search_knowledge_baseC

Search your organization's knowledge base to find relevant uploaded documents, procedures, reports, and other content using natural language queries

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Natural language question or keywords to search for across your uploaded knowledge base content. Can be a full question, technical terms, or key phrases.
`top_k`	No	Maximum number of most relevant document excerpts to return. Use higher values (10-20) for comprehensive research, lower values (3-5) for focused answers. Default: 5
`min_score`	No	Minimum semantic similarity score threshold (0.0 to 1.0). Higher values (0.8-1.0) return only highly relevant matches, lower values (0.5-0.7) include broader context. Default: 0.5
`thread_id`	No	Thread identifier for the current conversation or session. IMPORTANT: If a thread_id is available in your context, you MUST provide it to include thread-specific documents alongside general knowledge base content. Only omit if no thread context exists.
`collections`	No	Optional list of collection names to filter search results. Only documents tagged with these collections will be searched. Cannot be used with document_ids.
`document_ids`	No	Optional list of specific document IDs to search within. Use this to restrict search to known documents. Cannot be used with collections.

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions searching 'uploaded documents, procedures, reports, and other content,' it doesn't describe important behavioral aspects like authentication requirements, rate limits, pagination behavior, error conditions, or what format the results will be returned in (especially critical without an output schema).

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

Conciseness5/5

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

The description is a single, efficient sentence that clearly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality.

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

Completeness2/5

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

For a search tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what kind of results to expect, how relevance is determined, whether results are ranked, or any limitations of the search functionality. The agent would need to guess about the return format and search behavior.

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

Parameters3/5

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

The schema description coverage is 100%, providing comprehensive parameter documentation. The description adds no parameter-specific information beyond what's already in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.

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

Purpose4/5

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

The description clearly states the tool searches an organization's knowledge base using natural language queries, specifying the target resource and action. However, it doesn't differentiate from sibling tools like 'query_knowledge_base_document' or 'list_knowledge_base_documents', which appear to be related knowledge base operations.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'query_knowledge_base_document' or 'list_knowledge_base_documents', nor does it specify use cases, prerequisites, or exclusions for this search functionality.

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

update_security_finding_statusC

Update the status of a security finding

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Finding ID to update
`status`	Yes	New status for the finding

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool updates a finding status but lacks critical details: whether this requires specific permissions, if the change is reversible, what side effects occur (e.g., notifications, audit trails), or rate limits. For a mutation tool, this is a significant gap in 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/5

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

The description is a single, direct sentence with zero wasted words, efficiently conveying the core action. It's appropriately front-loaded and avoids unnecessary elaboration, making it easy to parse quickly.

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

Completeness2/5

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

For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, side effects, or response format, nor does it guide usage relative to sibling tools. This leaves the agent with insufficient context for safe and effective invocation.

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

Parameters3/5

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

The input schema has 100% description coverage, clearly documenting both parameters ('id' and 'status' with enum values). The description adds no additional semantic context beyond what the schema provides, such as format examples for 'id' or implications of status choices. This meets the baseline for high schema coverage.

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

Purpose4/5

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

The description clearly states the action ('Update') and the resource ('security finding status'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling tools that might also modify security findings, such as those that could update other attributes beyond 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/5

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. Given the sibling tools include 'list_security_findings' and 'mark_inbox_item_as_false_positive', there's no indication of prerequisites, sequencing, or contextual triggers for status updates, leaving usage ambiguous.

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

who_shelled_into_podC

Get k8s audit logs with information about users who shelled into a pod

ParametersJSON Schema

Name	Required	Description
`name`	No	Optional Pod name
`namespace`	No	Optional Pod namespace
`cluster_id`	No	Optional Cluster ID
`from_time`	No	Start time of the time range to search for audit events. Example: 2024-01-01T00:00:00Z. Default: 7 days ago
`to_time`	No	End time of the time range to search for audit events. Example: 2024-01-03T00:00:00Z
`limit`	No	Maximum number of results to return
`page`	No	Page number to return

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions retrieving audit logs but doesn't cover critical aspects like whether this requires special permissions, how results are formatted, if it's a read-only operation, potential rate limits, or error conditions. For a tool with 7 parameters and no annotations, this leaves significant gaps in understanding its 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/5

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

The description is a single, efficient sentence that clearly states the tool's purpose without unnecessary words. It's front-loaded with the core functionality and appropriately sized for what it communicates, making it easy to parse quickly.

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

Completeness2/5

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

Given the tool's complexity (7 parameters, no output schema, no annotations), the description is insufficient. It doesn't explain what the output looks like (e.g., log format, user details), how results are ordered, or any prerequisites for accessing audit logs. For a tool that likely returns structured security data, more context about the return values and operational constraints is needed.

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

Parameters3/5

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

The description doesn't add any parameter-specific information beyond what's already in the schema, which has 100% coverage with detailed descriptions for all 7 parameters. Since the schema fully documents parameters like 'name', 'namespace', 'from_time', etc., the description meets the baseline of 3 by not needing to compensate for schema gaps, but it doesn't provide additional context about how parameters interact or typical usage patterns.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Get k8s audit logs with information about users who shelled into a pod.' It specifies the action ('Get'), resource ('k8s audit logs'), and specific focus ('users who shelled into a pod'). However, it doesn't explicitly differentiate from sibling tools like 'get_k8s_resource_details' or 'list_k8s_resources' which might also retrieve Kubernetes data, preventing a perfect 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/5

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. With many sibling tools related to Kubernetes and auditing (e.g., 'get_k8s_resource_details', 'list_k8s_resources', 'list_http_requests'), there's no indication of when this specific audit log query is appropriate or what distinguishes it from other logging or resource tools.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.8/5.0

Disambiguation3/5

The tool set has clear domains (cloud, Kubernetes, compliance, vulnerabilities, workflows, etc.), but there is significant overlap and ambiguity within domains. For example, multiple tools fetch details for specific resources (e.g., get_cloud_resource_details, get_cluster_details, get_container_details) which could confuse agents about which to use for a given context. The RadQL tools (radql_query, radql_batch_query, radql_query_builder) have overlapping query capabilities, and tools like list_containers and radql_query for 'containers' data type serve similar purposes, leading to potential misselection.

Naming Consistency5/5

Tool names follow a highly consistent verb_noun pattern throughout, with clear conventions: 'get_' for retrieving specific details, 'list_' for listing items with filtering, and specific action verbs like 'mark_', 'query_', 'search_', 'run_', 'update_'. All tools use snake_case uniformly, and the naming is predictable and readable across the entire set, making it easy for agents to infer functionality.

Tool Count2/5

With 65 tools, the count is excessive for a single server, indicating poor scoping and potential bloat. While RAD Security covers a broad domain (security, compliance, cloud, Kubernetes), many tools could be consolidated (e.g., multiple RadQL query tools, overlapping list/get functions). This high number increases complexity and cognitive load for agents, making it difficult to navigate and select the right tool efficiently.

Completeness4/5

The tool surface is extensive and covers a wide range of security and compliance operations, including CRUD-like actions for resources, vulnerabilities, workflows, and knowledge base. However, there are minor gaps: for instance, no tools for creating or updating cloud resources or compliance controls (only get/list), and the RadQL tools might duplicate functionality of other list/get tools, but agents can work around these with the available query capabilities. Overall, it supports core security investigation workflows effectively.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Cortex C
io.cortex.mcp
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Developer Tools Monitoring Observability
312
ZEN SecDB A
cloud.nttzen.secdb
ZEN SecDB MCP server for CVE intelligence, CVSS/EPSS scoring, advisories, SSVC, and package audits.
Security Penetration Testing
112
ci-sentinel A
io.github.Baneado98
Multi-CI security scanner with a live threat-intel feed of compromised CI components
CI/CD & DevOps Security
2
mcp-server
com.pentest-tools
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
Penetration Testing Security
23

Related MCP Servers

secscan-mcp
Code Analysis Penetration Testing
openjkai
A
license
A
quality
A
maintenance
MCP server for Cursor that scans codebases for security issues including hardcoded secrets, SAST, vulnerable dependencies, and IaC misconfigurations.
Updated a month ago (2026-07-27 07:22 UTC)
7
MIT
IBM QRadar MCP Server
Monitoring Observability Security
ram-krishna-katakwar
A
license
Not graded
quality
D
maintenance
A Model Context Protocol (MCP) server that provides comprehensive access to IBM QRadar security intelligence platform. Query logs, events, offenses, agents, assets, and more directly from your AI assistant.
Updated 9 months ago (2025-11-20 05:20 UTC)
2
MIT
Checkmarxofficial
Penetration Testing Code Analysis Security
Checkmarx
A
license
Not graded
quality
B
maintenance
The Checkmarx Security MCP server bridges your AI assistant (Claude, Cursor, Copilot, etc.) with Checkmarx One's enterprise application security platform. It exposes security workflows as natural-language-accessible MCP tools, allowing developers to scan code, investigate findings, and receive context-aware fixes without leaving their development environment.
Updated 11 hours ago (2026-09-03 07:34 UTC)
Apache 2.0
neuvector-mcp
Security Observability Penetration Testing
darthzen
A
license
Not graded
quality
A
maintenance
MCP server for SUSE NeuVector container security, exposing inventory, vulnerability, compliance, event, and policy data as 72 typed tools. Read-only by default, with optional mutating toolsets behind a confirmation handshake.
Updated a month ago (2026-08-09 04:09 UTC)
Apache 2.0

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/rad-security/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

RAD Security MCP Server

Connect (hosted — recommended)

Claude Code

OpenAI Codex CLI

Cursor

VS Code (GitHub Copilot)

Gemini CLI

Cline

Windsurf

Other clients

Claude.ai / Claude Desktop / Claude Tag (Slack)

Test it (MCP Inspector or curl)

Scoping the tools an agent sees

Features

Self-hosting

Prerequisites

Credentials

npx (stdio) — e.g. Claude Desktop

Docker (Streamable HTTP)

Toolkit filtering

Multi-tenant (per-request auth)

Development

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Checkmarxofficial

Appeared in Searches

Latest Blog Posts

MCP directory API