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

Annotations already declare the operation as read-only, idempotent, non-destructive, and open-world. The description adds useful behavioral context beyond that: scaling `q` does not change the turn, pricing is $0.001 USDC per successful call via x402 on Solana, and an HTTPS endpoint is provided.

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 front-loaded with the core operation and then adds a concise example, an invariance note, pricing, and an alternate endpoint. Most sentences earn their place, though the unexplained `k` notation and transport details add some room for confusion.

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 tool with two required parameters and no output schema, the description should clarify quaternion convention, vector format, and the shape of the returned rotated vector. It provides mathematical context but leaves the agent without enough detail to call it reliably without guessing parameter ordering.

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%, so the description must carry parameter semantics. It identifies that `q` is a quaternion and `v` is a vector, but it does not explain the required component ordering or the fact that both are arrays of strings, which is important for correct invocation.

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 operation, rotating a vector by a quaternion, and reinforces it with the formula `q v q inverse` and a concrete half-turn example. It is clear what the tool computes, though it does not explicitly contrast itself with nearby siblings such as `quat_mul`, `quat_inv`, or `quat_pow`.

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 explains the mathematical operation but gives no explicit guidance about when to use this tool, when not to use it, or which quaternion siblings are alternatives. The example illustrates behavior rather than selection criteria.

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