MEV Intelligence

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

Annotations declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds behavioral context: it's a live recommendation based on real-time metrics, and returns specific output fields. It also discloses the alternative paid endpoint, which is helpful beyond annotations.

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 consists of two clear, front-loaded sentences with no wasted words. It efficiently conveys the tool's purpose, mechanism, and alternative resource.

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 zero parameters and no output schema, the description adequately covers the tool's function, output, and related resource. It could mention response format or edge cases, but for a simple tool it is sufficient.

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?

There are no parameters, so the schema coverage is 100%. According to the rubric, zero parameters yields a baseline of 4, and no additional description is needed for parameter semantics.

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 specifies the tool returns the best Ethereum block builder for MEV bundle submission based on live relay acceptance rate and submission volume, including the output (top builder name and acceptance percentage). It distinguishes itself from siblings like 'recommend_bundle_submission' and 'get_mev_feed' by focusing on live builder recommendation.

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 states to use it 'RIGHT NOW' for live recommendations and mentions an alternative endpoint for a full list with payment, providing some context on when to use this tool versus alternatives. However, it lacks explicit when-not or comparative guidance against all siblings.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, covering safety traits. The description adds minimal behavioral context beyond the annotations (e.g., the report summarizes activity and includes a link to an accuracy archive). It does not contradict annotations or add significant new behavioral disclosure.

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 extremely concise: two sentences. The first sentence lists key report contents, the second provides usage guidance and a pointer to an accuracy archive. No extraneous words, front-loaded with essential 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?

For a simple read-only tool with one parameter and no output schema, the description covers the report contents, usage context, and a reference for accuracy metrics. It could optionally describe the output format, but the information provided is sufficient for the agent to decide when to call the tool.

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?

The only parameter (window_hours) is fully described in the schema with a clear description and constraints. The tool description does not add any extra meaning beyond what the schema provides, so baseline score of 3 is appropriate given 100% schema coverage.

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 defines the tool as a 'daily intelligence report' for liquidation market activity, enumerating specific metrics (competitor count, funnel stages, top candidate). It explicitly brands itself as the 'morning briefing' tool, distinguishing it from sibling tools like get_builder_recommendation or get_liquidation_waves.

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 provides explicit guidance: 'call it once per session to understand market state before executing.' This tells the agent when to use the tool and implies it should precede actions. However, it lacks explicit exclusions or direct comparisons to sibling tools for when not to use it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's mention of returning top 10 positions aligns well. It adds context about protocols and chains but does not disclose additional behaviors like rate limits or data freshness.

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 four sentences, front-loaded with the core purpose, followed by immediate next steps and an alternative. Every sentence adds value without redundancy.

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 simplicity (1 param, no output schema, annotations present), the description adequately covers functionality, return fields, and workflow. The lack of explicit output format details is mitigated by listing fields; however, no pagination info is given.

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?

The schema already provides full coverage (100%) for the single parameter 'limit', with a clear description. The tool description does not add new semantics beyond restating the default limit, so a baseline score of 3 is appropriate.

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 tool's function: retrieving near-liquidation borrowers ranked by health factor, specifying protocols (Aave V3, Spark, Morpho), chains (L1, Base), and return fields. It distinguishes from sibling tools through specificity.

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 provides an explicit usage workflow: after obtaining targets, sign a liquidation transaction and call submit_bundle. It also advises when to use the paid API for profit estimates, guiding the agent's decision.

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

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

Annotations already indicate read-only and non-destructive behavior. The description adds context about the output (10 positions, risk tags) and exposes a paid endpoint for more data, which is beyond what annotations provide.

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 three concise sentences with no wasted words. It front-loads the purpose, then details output and a paid alternative, and ends with a sibling reference. Every sentence adds value.

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 simple tool with one optional parameter and no output schema, the description covers purpose, output characteristics (10 positions, risk info), and how to get more data. It also links to a sibling for action, making it complete for its complexity.

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% for the single optional parameter min_net_usd, with a description already present. The tool description does not add further meaning or examples, so it meets baseline expectations.

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 it retrieves a risk-enriched MEV opportunity stream, specifies it returns 10 positions with fields like chain, protocol, health factor, and risk tags, and distinguishes itself from siblings like submit_bundle.

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?

It explains when to use the tool (to get MEV opportunities), mentions a paid alternative for a full stream, and directs users to submit_bundle for acting on opportunities. It lacks explicit 'when not to use' but provides sufficient context.

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

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

Annotations already indicate this is a safe read operation (readOnlyHint=true, destructiveHint=false). The description adds useful behavioral details: it only returns top 5 entries, and mentions a full 25-entry leaderboard available elsewhere with payment. This sets appropriate expectations.

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 two sentences, front-loaded with the main action, and free of fluff. Every sentence adds value: the first states the core function and timeframe, the second details the output and additional resource.

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 no output schema, the description adequately describes the return values (addresses, counts, percentages) and scope (top 5). It also mentions an alternative for full data. It doesn't specify data types or format, but for a simple list tool, this is sufficient.

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?

There are no parameters in the input schema, so schema coverage is 100%. The description does not need to add parameter information, and it doesn't. Baselines at 3 are appropriate since the schema already fully covers the lack of parameters.

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 it gets top MEV searchers ranked by landed liquidation fires in the last 4 hours, specifying it returns top 5 searchers with full addresses, landed count, total submissions, and land rate percentage. This is distinct from all sibling tools, which focus on different aspects like builder recommendations, liquidation reports, or bundle submissions.

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 provides clear context for when to use this tool: to get a quick snapshot of top searchers. It doesn't explicitly exclude other tools or mention alternatives, but the unique leaderboard purpose makes usage fairly obvious. No misleading guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds context about the real-time nature ('next price move'), sorting by cross probability, and that it yields a priority list, which enhances behavioral understanding beyond annotations.

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?

Two sentences plus a clear action hint, all essential. Front-loaded with purpose and actionable guidance. No redundant words.

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?

Despite no output schema, description specifies exactly what each candidate includes (health factor, cross probability, estimated net profit, protocol). Also provides business context and the follow-up action, making it fully informative for the agent.

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?

Input schema already covers both parameters (limit, min_cross_prob) with clear descriptions. Description does not add additional parameter details beyond restating cross probability range, so it meets the baseline 3 for high schema coverage.

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?

Clearly states the tool gets highest-priority liquidation candidates sorted by cross probability, listing included fields (health factor, cross probability, etc.). Differentiates from siblings by describing its role in pre-building bundles and referencing submit_bundle.

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?

Explicitly says to use it to prioritize positions for pre-building bundles and instructs to call submit_bundle when HF=1.0. This provides clear when-to-use and when-not-to-use guidance relative to siblings.

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

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

Annotations already provide readOnlyHint and openWorldHint. The description adds no behavioral traits beyond what annotations convey. It does not disclose any side effects, auth needs, or rate limits, so the description carries minimal extra value for transparency.

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?

Every sentence is concise and informative. It front-loads purpose, lists return fields, states importance, gives usage context, and mentions an alternative—all in a few sentences without redundancy.

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 tool has 2 optional params and no output schema. The description fully explains default behavior (top 5 candidates), return structure (health_factor, cross_probability, etc.), and integration context (call before submit_bundle). No gaps given the complexity.

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% with good descriptions. The description adds significant value by explaining default behavior (top 5 candidates when borrower omitted) and the meaning of return fields, going beyond the schema.

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 it 'Get a structured liquidation probability prediction' and specifies the resource (borrower or top candidates). It lists return fields and distinguishes itself as the core moat tool that drives bundle decisions, differentiating from siblings.

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?

Explicitly says 'Call this before submit_bundle to confirm the opportunity is still live and to size your bribe correctly.' It also mentions an alternative endpoint for full probability model, providing clear when-to-use and when-not-to-use guidance.

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

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

Annotations (readOnlyHint=true, destructiveHint=false) declare it safe. The description adds that it uses live relay telemetry and returns actionable info, consistent with annotations. No contradictions.

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?

Two sentences with no wasted words. First sentence covers purpose and outputs; second gives usage guidance. Front-loaded and efficient.

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 single-parameter, read-only tool without output schema, the description sufficiently explains inputs, outputs, and integration with siblings. Lack of output format detail is acceptable given simplicity.

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% with one optional borrower parameter. The description adds value by explaining that omitting borrower gives market-level recommendation, providing behavioral context beyond the schema's 'Optional' label.

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 retrieves a bundle submission recommendation for a borrower or market conditions, specifying the returns (builder, probability, reason). It distinguishes from siblings like monitor_crossing_candidates and submit_bundle.

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 provides explicit usage pairing: 'Pair with monitor_crossing_candidates — identify a hot candidate, then call this to decide WHERE to submit your bundle.' This gives clear context, though it doesn't mention when not to use or alternatives.

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

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

Description discloses that bundles are forwarded to multiple relays (rbuilder, Flashbots, Titan, etc.) and claims a 100% acceptance rate. It mentions it's free with API key attribution and returns a tracking_id. Annotations already indicate it's not read-only, not open-world, not destructive, so description adds useful behavioral context beyond annotations.

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 a single paragraph with front-loaded purpose. Each sentence adds value, though it could be slightly more concise. It is well-structured for rapid comprehension.

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 no output schema, the description covers prerequisites, parameters, behavior, and returns. It explains the workflow (pair with get_liquidation_waves) and outcome (tracking_id). It is sufficiently complete for a tool of this complexity.

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% with descriptions for all 4 parameters. The description adds extra context: 'Max 10 per bundle' for txs, 'Bundle will only be included in this exact block' for blockNumber, and explains the api_key purpose. This goes beyond the schema descriptions, improving clarity.

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 submits signed Ethereum bundles to MEV SearcherNet rbuilder for inclusion. It specifies the verb 'submit' and resource 'signed Ethereum bundle', and distinguishes from siblings by indicating it's for acting on liquidation opportunities after using get_liquidation_waves or get_mev_feed.

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 explicitly says 'Use this after get_liquidation_waves or get_mev_feed' and provides a tip for pairing with get_liquidation_waves. It gives clear context for when to use, though it doesn't explicitly state when not to use.

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