detect-lateral-movement-paths

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

With no annotations, the description carries the full burden. It does disclose the analytical nature ('Analyze traffic patterns', 'detect potential') and the key concept of bridge apps, implying a read-only, heuristic analysis. But it does not mention data dependencies, limitations, or whether results are approximate or require additional validation.

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, zero filler. The primary purpose is stated first, and the bridge-identification detail adds meaningful clarification without bloating the text.

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?

This is a moderately complex analysis tool with no output schema and no annotations, so the description needs to explain what the agent will receive and any important caveats. It gives only a high-level notion of output ('identifies apps that serve as bridges') and omits details about result structure, false-positive potential, or how the optional parameters shape the output. An agent would likely need to call it experimentally to understand the results.

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

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

The input schema covers 100% of the parameters with clear descriptions. The tool description adds nothing beyond the schema about how these parameters influence the analysis, 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.

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

The description uses a specific verb ('Analyze') and resource ('traffic patterns') and clearly states the outcome: detecting lateral movement paths and identifying bridge apps. This is distinct from siblings like get-traffic-flows, which simply retrieve traffic data, so an agent can tell them apart.

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 makes the use case clear: when you need to find potential lateral movement paths or bridge applications. However, it does not explicitly contrast this with alternatives or state when not to use it, so the guidance is implied rather than spelled out.

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