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 disclosing behavioral traits. It does not mention whether the tool is read-only, modifies the agent configuration, requires permissions, or what the output format is (e.g., report structure). This lack of detail limits transparency.

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

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

The description is concise at two sentences, with no unnecessary words. It is front-loaded with the action and purpose. However, some additional structure or bullet points could improve scanability, but overall it is efficient.

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

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

Given the tool's complexity (nested object parameter, no output schema, no annotations), the description is incomplete. It does not explain what the output looks like (e.g., list of violations), whether it modifies state, or how to interpret flags. This leaves gaps for correct invocation.

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

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

Schema coverage for parameters is 100%, so the baseline is 3. The description does not add any extra meaning beyond what the schema already provides. It mentions 'role-based expectations' but does not specify how the role is used or clarify the nested 'agent_config' structure beyond the schema.

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

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

The description clearly states the tool's purpose: auditing an agent configuration for over-privileged access by comparing against role-based expectations. It uses a specific verb-resource pair ('audit agent configuration') and distinguishes itself from sibling security tools like 'scan_mcp_config' and 'detect_prompt_injection' which focus on different aspects.

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

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

The description implies usage for checking agent permissions but does not explicitly state when to use this tool versus alternatives. No exclusions or context about prerequisites are provided, making it adequate but not exemplary.

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

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

With no annotations provided, the description must carry the behavioral burden. It mentions 'context-aware risk scoring' and lists detected patterns, but does not disclose what happens after detection (e.g., returns a boolean, score, or flagged text). No side effects or safety info is given.

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

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

Two sentences, no wasted words. First sentence states the core purpose, second adds meaningful detail. Well front-loaded.

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

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

Input parameters are well covered, but no output schema exists and the description omits any mention of return values or structure. For a detection tool, understanding the output format is important for correct usage.

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

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

The schema covers 100% of parameters with descriptions. The description adds 'context-aware risk scoring' and lists specific injection types, providing meaning beyond the raw parameter definitions, especially for the 'context' enum values.

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

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

The description clearly states 'Analyze text for prompt injection attempts' and lists specific attack types (instruction overrides, identity manipulation, etc.), which is a specific verb+resource. Among sibling security tools, it uniquely targets prompt injection, so it distinguishes well.

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

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

The description does not explicitly state when to use this tool versus alternatives like scan_secrets or detect_tool_poisoning. It implies usage for analyzing text for injection, but provides no exclusion criteria or context-based guidance.

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

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

With no annotations, the description should fully disclose behavior. It mentions the analysis scope (OWASP vectors) but does not state that the tool is read-only, safe, or non-destructive. It also lacks details on potential side effects or rate limits.

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

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

The description is two sentences, concise and front-loaded with the core purpose. Every sentence is meaningful, and there is no redundant information.

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

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

The description lacks any mention of the return value or output format, which is critical for a security analysis tool. Users and AI agents need to know what the result looks like (e.g., risk score, list of indicators). Additionally, no output schema is provided, and annotations are absent.

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

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

The single parameter 'tool_definition' is fully described in the schema (100% coverage), but the description adds value by explaining that the tool analyzes the description text for hidden instructions and covers specific attack vectors, going beyond the schema's generic description.

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

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

The description clearly states the tool analyzes MCP tool definitions for poisoning indicators, specifically hidden instructions in descriptions that manipulate agent behavior, covering OWASP Agentic Top 10 attack vectors. It is specific and distinguishes from siblings like detect_prompt_injection.

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

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

The description implies usage when analyzing tool definitions for poisoning, but it does not provide explicit guidance on when to use this tool versus alternatives like detect_prompt_injection or validate_scope_contract. No when-not-to-use 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.

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

With no annotations, the description carries full burden. It discloses that the tool aggregates inputs and produces a report with a remediation plan and compliance notes. It does not explicitly state that it is read-only or non-destructive, but the nature of generating a report implies no side effects. Lacks explicit safety statements like 'does not modify any state.'

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

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

Two concise sentences with no wasted words. The key action and output are front-loaded: 'Generate a comprehensive security assessment report.' Every sentence adds distinct value.

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

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

Given no output schema, the description adequately explains the output (remediation plan with OWASP notes). It does not detail the output structure or format, but the mention of aggregation and prioritization provides sufficient context. Parameter coverage is complete.

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

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

Schema coverage is 100%, so the schema already describes each parameter. The description adds value by explaining that configs come from scan_mcp_config and audit_results from audit_agent_permissions, clarifying their provenance. However, it does not provide format or constraints beyond what the schema offers.

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

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

The description clearly states the verb ('Generate'), the resource ('comprehensive security assessment report'), and the scope ('for an agent deployment'). It explicitly mentions aggregating results from config scans and permission audits and producing a prioritized remediation plan with OWASP compliance notes. This distinguishes it from sibling tools like scan_mcp_config and audit_agent_permissions, which are single-purpose scanners.

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

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

The description implies usage after running config scans and permission audits (since it aggregates their results), but does not explicitly state prerequisites or when not to use it. Alternatives are implied by sibling tools (e.g., use scan_mcp_config for scans instead), but no direct guidance on exclusion criteria.

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

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

No annotations are provided, so the description carries full burden. It discloses it returns metrics (read-only), but does not mention authorization needs, rate limits, or potential side effects. For a simple health check, this is adequate but minimal.

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

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

Single sentence, no filler, front-loaded with the verb. Every word earns its place.

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

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

For a zero-parameter health check tool, the description is sufficient to convey purpose and output. However, without an output schema, an agent might benefit from hinting at the structure (e.g., 'returns JSON object'). Still, given simplicity, a 4 is appropriate.

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

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

With zero parameters and 100% schema coverage, the description adds no additional meaning for parameters, which is acceptable. The baseline is 4 since no parameter documentation is needed.

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

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

Description clearly states the action ('returns') and specific resources ('server health, uptime, version, and usage stats'), making the purpose unambiguous. It also distinguishes from sibling security-focused tools like scan_mcp_config or detect_prompt_injection.

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

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

The description implies usage for server monitoring but provides no explicit guidance on when to use this tool versus alternatives. Given siblings are all security-related, the distinction is clear, but no when-not or exclusions are stated.

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

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

No annotations provided, so description must disclose behavioral traits. It explains the scanning scope and return values (risk score, issues, recommendations), which is helpful. However, it does not state whether the tool modifies state, requires authentication, or is read-only. The absence of such details limits transparency.

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

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

Two concise sentences: first states purpose and what it scans for, second states outputs. No fluff, front-loaded with key actions and results. Every sentence adds value.

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

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

Given no output schema, the description outlines return values (risk score, issues, recommendations). The tool fits well among sibling security tools. It covers scope and output adequately but could mention idempotency or permissions. Still, it provides sufficient context for an agent to decide when to invoke it.

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

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

Schema description coverage is 100% (both parameters documented in schema). The description adds no new meaning beyond 'scan an MCP server configuration' — the schema already defines config object with command, args, env, and server_name. Baseline 3 applies as the description does not enhance parameter understanding.

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

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

The description uses a specific verb 'Scan' and resource 'MCP server configuration', listing concrete security issue categories (dangerous commands, exposed secrets, network exposure, container misconfigurations) and outputs (risk score, issues, recommendations). It clearly distinguishes from sibling tools like 'scan_secrets' or 'detect_prompt_injection'.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., scan_secrets, detect_prompt_injection). The description does not mention prerequisites, when to avoid, or when other tools are more appropriate.

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

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

With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: 'All values are masked in output.' However, it does not mention whether the tool is read-only, if it has rate limits, or any permission requirements.

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

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

Two sentences: first states purpose, second provides key detail about output masking. No wasted words, front-loaded with the action.

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

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

No output schema exists, so the description should explain the return format. It only says 'All values are masked in output,' which is vague. Missing details on result structure and error cases, but sufficient for a simple detection tool.

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

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

Schema coverage is 100% and the description does not add significant new meaning beyond what the schema already provides. The description lists secret types, which provides context, but does not elaborate on parameter formats or constraints.

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

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

Description starts with a clear verb-resource pair: 'Detect leaked secrets and credentials in text or code.' It lists specific secret types (API keys, JWT tokens, etc.), which distinguishes it from sibling tools like health_check or detect_prompt_injection.

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

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

No explicit guidance on when to use this tool versus alternatives. The description implies it's for scanning text/code for secrets, but does not mention prerequisites, when not to use, or suggest sibling tools.

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

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

With no annotations, the description carries full transparency burden. It describes what is validated but omits critical behavioral details: whether it is read-only, what happens on violation (return value, error, side effects), and performance implications. This is insufficient for an agent to predict outcomes.

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

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

Two sentences efficiently convey purpose and scope. Every word adds value, no redundancy or filler. Well-structured for quick parsing.

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

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

Given nested objects and validation complexity, the description covers the 'what' but not the 'how' (output format, error handling). Missing output schema means agents need to guess return structure. Adequate but not fully complete.

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

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

Schema coverage is 100% with descriptions for both parameters. The tool description adds overall context but no new parameter details. Baseline 3 is appropriate as schema already documents parameters.

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

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

The description clearly states the tool verifies compliance of an agent action with its scope contract, listing specific checks (tool allowlists, file paths, boundary constraints). This distinguishes it from sibling tools like health_check or scan_mcp_config which focus on different security aspects.

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

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

The description implies usage for validation but does not explicitly state when or when not to use it. It contrasts with siblings only implicitly through purpose. No guidance on prerequisites or alternative tools.

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