websex_jwt_deep_probe

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

With no annotations, the description carries the full burden, and it does disclose real behavior: the probing methodology and the fact that it issues a valid-token control request first to calibrate. It still omits authorization/permission requirements, request-rate or side-effect implications (max_requests defaults to 12), and whether it mutates target 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?

A single dense sentence that is front-loaded with the core purpose and then enumerates scope; nearly every clause carries information. The trailing calibration note is slightly abrupt but still earns its place as a workflow 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?

An output schema exists so return values needn't be explained, but for a complex live-attack tool with 11 undocumented parameters and no annotations, the description leaves too much unspecified. It conveys the attack surface well but not enough for correct invocation of the many configuration parameters.

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 0% across 11 parameters, so the description must compensate, yet it explains only a few concepts indirectly (wordlist for crack_secret, JWKS for the confusion attack, claim tampering hinting at expected_issuer/audience). Core params like token, probe_url, engagement_id, method, headers, auth_header_name, and auth_header_template receive no added meaning.

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 a specific verb and resource ('JWT audit') and enumerates the exact attack classes covered: alg=none, RS256->HS256 confusion via JWKS, HS256 secret cracking, claim tampering, and kid leads. This is far more specific than a generic audit label, but it never names the sibling tools (websex_jwt_decode, websex_jwt_audit) to differentiate itself, so an agent must infer which JWT tool to pick.

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?

'Live-oracle' implicitly signals that a reachable target is required, distinguishing it from offline decoding, and the calibration note implies an active probe workflow. However, it gives no explicit when-to-use vs when-not, and does not point to websex_jwt_decode or websex_jwt_audit as the lighter alternatives.

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