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

The description goes well beyond the basic annotations by disclosing operational details: bundles are fanned out to multiple relays (Flashbots, Titan, Beaver, BuilderNet, bloXroute), it's 'Free with API key attribution,' analytics are available at a specific endpoint, and submission status can be tracked via tracking_id. This gives the agent a full picture of side effects and follow-up actions.

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 fairly lengthy but well-structured: it starts with the core purpose, then usage timing, then behavior (relay fanout, analytics), then return value, and finishes with a practical tip. Every sentence adds valuable context, though it could be slightly more concise without losing information.

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 tool's complexity (submitting bundles to multiple relays, requiring signed txs, tracking status), the description covers all essential aspects: what it does, when to use it, side effects, return value (tracking_id), and supplementary endpoints. With no output schema, the inclusion of tracking_id is especially helpful. It feels complete for the task.

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 100%, so baseline is 3. The description adds contextual meaning by emphasizing that txs must be signed, mentioning the max of 10 per bundle, and explaining the api_key is for attribution (and that the tool is free with it). This reinforces and slightly extends the schema descriptions, earning a 4.

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 tool's purpose: 'Submit a signed Ethereum bundle directly to MEV SearcherNet rbuilder for inclusion.' This uses a specific verb (submit) and resource (signed Ethereum bundle) and distinguishes it from sibling analytics/viewer tools by being the action tool.

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?

Explicit usage context: 'Use this after get_liquidation_waves or get_mev_feed to act on a liquidation opportunity.' It also provides a workflow pair with get_liquidation_waves, showing exactly when this tool fits relative to others. While it doesn't explicitly say 'when not to use,' the after X language makes the appropriate context clear.

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