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

With no annotations provided, the description fully carries the behavioral disclosure burden. It explains authentication and payment options, that hashes re-derive from a public RPC, that results are newest-first, and gives default/max bounds for window and limit. This is unusually transparent for a tool of this type.

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 content is dense and mostly worthwhile, but it is a single wall of text that leads with a long payment/auth clause before stating what the tool does. A short purpose sentence followed by structured details would make it easier to scan.

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?

The output schema exists, so return-value documentation is not required. However, the description does not state whether chain is required or what its default is, and the pool filter lacks the identifier format an agent would need to construct a correct call.

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 compensate, and it largely does: it defines type values, chain values, window units with defaults/max, and limit defaults/max. The pool parameter is only described as a filter target with no identifier format, which is the main gap.

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 identifies the resource as extracted victim order flow and enumerates the returned fields (victim transaction hash, attacker, pool, protocol, block, position, gas price, spread, profit). It does not use an explicit imperative verb like 'returns' or 'lists', and it does not name sibling tools, so it falls short of a 5.

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?

There is no statement about when to choose this tool over siblings such as mev_intel, mev_bots, or mev_flow_spec, and no explicit exclusions. Parameter instructions for filter, window, and limit exist, but they are invocation guidance, not use-case selection guidance.

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