run_dast_scan

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 'Execute DAST scan' but lacks details on what this entails: whether it's a long-running process, if it requires specific permissions, potential side effects (e.g., network traffic, resource usage), or expected outcomes. For a tool that likely performs security testing with multiple parameters, this is insufficient.

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 extremely concise with a single sentence, 'Execute DAST (Dynamic Application Security Testing) scan,' which is front-loaded and wastes no words. It efficiently conveys the core action, though this brevity comes at the cost of detail.

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

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

Given the complexity (4 parameters including nested objects, no output schema, and no annotations), the description is incomplete. It doesn't explain what DAST scanning involves, the output or results, how to interpret scan outcomes, or behavioral aspects like execution time or error handling. For a security testing tool with multiple configuration options, more context is needed.

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%, so the input schema already documents all parameters (target_url, project_path, scan_type, authentication) with descriptions. The description adds no additional meaning beyond what the schema provides, such as explaining the differences between scan_type options or how authentication is used. 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.

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

The description states the action ('Execute') and resource ('DAST scan'), which provides a basic understanding of purpose. However, it's vague about what DAST scanning entails and doesn't differentiate from sibling tools like run_iast_scan or run_sast_scan, which are also security testing tools. The description merely restates the tool name without elaboration.

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

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

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools like run_iast_scan or run_sast_scan, nor does it explain the context for choosing DAST over other security testing methods. There's no indication of prerequisites, timing, 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.