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

Goes well beyond the readOnlyHint annotation by disclosing cost (1 cent per call), the four supported chains, the window bounds, and a genuine data limitation (no per-order victim trade sizes). Missing only depth on the result's shape, which the output schema covers.

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?

Front-loaded with the purpose and constraints, which is good, but the opening sentence is a single sprawling enumeration of return metrics that duplicates the output schema. That list should be trimmed so the operational constraints (pool type, window, chains, price) carry the weight.

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?

With an output schema present and full schema coverage, the description supplies the remaining essentials: accepted pool identifier types, window bounds and default, chain coverage, per-pool granularity caveat, and cost. Only the absence of sibling routing guidance keeps it short of 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 description coverage is 100%, so pool, chain and window are already documented with formats and examples. The description restates the same facts (address or 32-byte v4/Infinity pool id, window default 1440 max 10080) and adds only the qualifier about which pool types accept a bytes32 id.

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?

Names a specific verb (check) plus a tightly scoped resource: MEV activity for one pool on one chain, pre-trade. The metric list (sandwiched/backrun/frontrun/JIT counts, victims per hour, attackers, profit medians) makes it unmistakably different from generic flow tools like mev_pressure or victim_flow.

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?

Establishes the when ('Pre-trade MEV check') and a clear scope exclusion ('Per pool, not per order: victim trade sizes are not stored'), plus the covered chains and price. It never names an alternative sibling tool or states when not to use it, so routing still requires inference.

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