find_xss_vectors

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

With no annotations provided, the description carries the transparency burden. It discloses that the search is heuristic and lists exact patterns, which adds useful context about coverage. However, it does not mention read-only behavior, side effects, or output format, though these are likely implied by the tool name.

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

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

The description is a single, tightly packed sentence that front-loads the purpose and lists specific patterns without any fluff. Every word adds value, making it highly efficient and easy to parse.

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

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

For a simple one-parameter analysis tool with complete schema coverage, the description adequately covers the tool's scope and enumerates patterns. It could mention return values or prerequisites, but the schema already indicates the project must be loaded, so it is sufficiently 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?

The single parameter 'name' is fully described in the schema (100% coverage), so the description adds no additional parameter meaning. Baseline 3 is appropriate because the schema already documents the parameter completely.

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

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

The description clearly identifies the tool's function by enumerating specific XSS sink patterns across Vue, Svelte, React, and DOM, which distinguishes it from sibling security tools. The action verb 'find' is carried by the tool name rather than the description, so it loses a point for lacking an explicit verb in the description.

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 framework list implies the tool is for auditing XSS vulnerabilities in projects using those frameworks, but there is no explicit when-to-use guidance or mention of alternatives. It does not exclude other security tools, leaving the agent to infer context from the pattern list.

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