Websocket Probe

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

Annotations declare readOnlyHint=true and destructiveHint=false, and the description reinforces this by stating it sends no frames and closes the connection immediately. It adds the limitation about not testing authentication, which is beyond annotations. No contradiction.

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 moderately long but well-structured: purpose first, then usage constraints, then behavior, then interpretation. Each sentence adds value, and the critical usage note about URL format is front-loaded. Slightly verbose but not padded.

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 output schema exists, return format is covered. The description explains the tool's purpose, usage constraints, passivity, and how to interpret results. It does not mention potential error cases or rate limits, but for a simple probe it is reasonably 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 0%, so the description must compensate. It explains the target format (https://) and implies the origin parameter is the Origin header to send, but does not explicitly define the origin parameter's semantics or default behavior. It adds some value but could be more explicit about the origin parameter's role and acceptable 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 the verb (open, report) and resource (WebSocket handshake, Origin validation) in the first sentence. It is specific and distinct from the many sibling tools, which focus on other scan types. No ambiguity.

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?

Provides explicit guidance on URL format (https:// not wss://), explains the scope engine's behavior, and notes the passive nature. It also clarifies that the tool does not test authentication, so it cannot confirm a finding alone. However, it does not name alternative tools for similar checks, so it lacks explicit 'use X instead' guidance, though the context is clear.

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