MEV Intelligence
Server Details
Real-time Ethereum liquidation intelligence for AI agents and MEV bots.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 10 of 10 tools scored.
Each tool has a clearly distinct purpose: building calldata, getting builder recommendations, daily reports, listing borrowers, grabbing an opportunity stream, viewing leaderboards, monitoring crossing candidates, predicting probabilities, recommending submission, and submitting bundles. No overlapping functionality.
All tool names follow a consistent verb_noun pattern in lower_snake_case (e.g., build_liquidation_tx, get_builder_recommendation, submit_bundle), making it easy to predict tool behavior from names.
With 10 tools, the set is well-scoped for an MEV intelligence server. It covers the full workflow from opportunity discovery to bundle submission without being bloated or sparse.
The tool set covers the core liquidation workflow comprehensively (identify, predict, build, recommend, submit). A minor gap is the lack of a dedicated tool to check submission status, relying on an external endpoint instead.
Available Tools
10 toolsbuild_liquidation_txARead-onlyInspect
Build agent-ready calldata for a liquidation transaction. Returns the target protocol contract address, ABI-encoded calldata, suggested gas limit, value, and chain — everything an agent needs to sign and submit via submit_bundle. Supports Aave V3 (L1 + Base), Spark (L1), and Morpho Blue (L1). Returns calldata only — the agent signs and submits separately. This tool does NOT touch funds and does NOT submit anything; it is a calldata builder.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Chain to build calldata for. base only supported for aave-v3. | |
| borrower | Yes | 0x-prefixed address of the borrower being liquidated. | |
| protocol | Yes | Lending protocol. aave-v3 supported on ethereum + base. spark and morpho on ethereum only. | |
| debt_asset | Yes | 0x-prefixed address of the debt token to repay. For Morpho, this field is ignored. | |
| debt_to_cover | Yes | Amount of debt token to repay in wei (string to avoid precision loss). Use "max" or the uint256 max value 0xff..ff to liquidate as much as possible (Aave V3 close factor applies). | |
| receive_a_token | No | Aave V3 only. If true, receive collateral as aToken (saves gas, no unwrap). If false, receive underlying. Default false. | |
| collateral_asset | Yes | 0x-prefixed address of the collateral token to seize. For Morpho, this field is ignored (market ID supplies it). | |
| morpho_market_id | No | Morpho Blue market id (bytes32). Required when protocol=morpho. | |
| morpho_repaid_shares | No | Morpho Blue only. Amount of debt shares to repay. Mutually exclusive with morpho_seized_assets. | |
| morpho_seized_assets | No | Morpho Blue only. Amount of collateral to seize in wei. Mutually exclusive with morpho_repaid_shares. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description reinforces that the tool does not touch funds or submit anything, only builds calldata. This fully discloses the non-destructive, read-only nature.
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?
Three sentences with clear front-loading: main purpose, supported protocols, and critical caveat about not submitting. Every sentence adds distinct 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?
The description explains what the tool returns (contract, calldata, gas, value, chain) and its purpose within the ecosystem. While no output schema is provided, the description covers the needed contextual cues for an agent to use it correctly.
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%, and the description adds valuable context for several parameters (e.g., 'max' for debt_to_cover, mutual exclusivity of Morpho parameters, and chain/protocol restrictions).
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 'Build agent-ready calldata for a liquidation transaction' and lists supported protocols and chains, distinguishing it from siblings like submit_bundle that submit the calldata.
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 advises using this tool before submit_bundle and specifies supported protocols/chains. It doesn't explicitly exclude other use cases, but the context of sibling tools and the phrase 'agent-ready' make usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_builder_recommendationARead-onlyInspect
Get the best Ethereum block builder for MEV bundle submission RIGHT NOW based on live relay acceptance rate and submission volume. Returns the top recommended builder name and acceptance percentage. Full ranked builder list with telemetry available at /intelligence/builder-recommendation with x402 payment ($0.25).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
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.
get_daily_liquidation_reportARead-onlyInspect
Get a daily intelligence report summarizing liquidation market activity: competitor count, positions we would have fired on, funnel metrics (PRE→SIM→HOTFIRE→SUBMIT→LANDED), and the top candidate right now. This is the "morning briefing" tool — call it once per session to understand market state before executing. Full accuracy archive with precision/recall metrics available at /intelligence/accuracy-archive.
| Name | Required | Description | Default |
|---|---|---|---|
| window_hours | No | Lookback window in hours (default 24, max 48). |
Tool Definition Quality
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.
get_liquidation_wavesARead-onlyInspect
Get near-liquidation borrowers ranked by health factor proximity across Aave V3, Spark, and Morpho on L1 and Base. Returns top 10 positions with full borrower addresses, health factor, debt USD, and collateral USD. Once you have a target, sign a liquidation transaction and call submit_bundle to execute atomically. For net profit estimates and the full borrower universe, call /intelligence/liquidation-waves with x402 USDC payment ($0.50).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10, preview max 10) |
Tool Definition Quality
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.
get_mev_feedARead-onlyInspect
Get a risk-enriched MEV opportunity stream. Returns 10 positions with chain, protocol, health factor, and risk tags. Full stream with borrower addresses and expected profit available at /intelligence/feed with x402 payment ($0.10). Use submit_bundle to act on opportunities directly from this feed.
| Name | Required | Description | Default |
|---|---|---|---|
| min_net_usd | No | Minimum estimated net USD profit to include |
Tool Definition Quality
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.
get_searcher_leaderboardARead-onlyInspect
Get top MEV searchers ranked by landed liquidation fires in the last 4 hours. Returns top 5 searchers with full addresses, landed count, total submissions, and land rate percentage. Full 25-entry leaderboard available at /intelligence/searcher-leaderboard with x402 payment ($0.25).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
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.
monitor_crossing_candidatesARead-onlyInspect
Get the highest-priority liquidation candidates sorted by cross probability — borrowers most likely to become liquidatable in the next price move. Each candidate includes health factor, cross probability (0–1), estimated net profit, and protocol. Use this to prioritize which positions to pre-build bundles for. Call submit_bundle when a candidate crosses HF=1.0.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max candidates to return (default 10, max 20). | |
| min_cross_prob | No | Minimum cross probability (0–1) to include. Default 0.05. |
Tool Definition Quality
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.
predict_liquidation_probabilityARead-onlyInspect
Get a structured liquidation probability prediction for a specific borrower or the top candidates. Returns: health_factor, cross_probability (0–1), estimated_ev_usd, lead_time_estimate_s (how long until crossing at current oracle velocity), oracle_velocity (|Δprice|/min on collateral asset), and a human-readable verdict. This is the core moat tool — it exposes the prediction layer that drives bundle decisions. Call this before submit_bundle to confirm the opportunity is still live and to size your bribe correctly. Full probability model with confidence intervals available at /intelligence/liquidation-waves with x402 payment ($0.50).
| Name | Required | Description | Default |
|---|---|---|---|
| borrower | No | Borrower address to get prediction for. If omitted, returns top 5 candidates by cross probability. | |
| protocol | No | Optional protocol filter when borrower is not specified. |
Tool Definition Quality
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.
recommend_bundle_submissionARead-onlyInspect
Get an actionable bundle submission recommendation for a specific borrower or current market conditions. Returns the best builder to target, expected inclusion probability, and a human-readable reason based on live relay telemetry. Pair with monitor_crossing_candidates — identify a hot candidate, then call this to decide WHERE to submit your bundle.
| Name | Required | Description | Default |
|---|---|---|---|
| borrower | No | Optional. Borrower address to get a position-specific recommendation for. |
Tool Definition Quality
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.
submit_bundleAInspect
Submit a signed Ethereum bundle directly to MEV SearcherNet rbuilder for inclusion. Use this after get_liquidation_waves or get_mev_feed to act on a liquidation opportunity. Bundles are forwarded to rbuilder and fanned out to Flashbots, Titan, Beaver, BuilderNet, and bloXroute relays. Free with API key attribution (X-Api-Key header). Inclusion rate, sim pass rate, and per-builder acceptance available at /orderflow/analytics with provenance. Returns a tracking_id you can use to check submission status at /orderflow/submissions/{tracking_id}. Tip: pair with get_liquidation_waves — identify a borrower near liquidation, construct the liquidation tx, sign it, then call this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| txs | Yes | Array of hex-encoded signed transactions (0x-prefixed RLP). Max 10 per bundle. | |
| api_key | No | Optional. API key for attribution and leaderboard tracking. Assign at mev.advalorem.io. | |
| blockNumber | Yes | Target block number as hex string (e.g. "0x1400000"). Bundle will only be included in this exact block. | |
| revertingTxHashes | No | Optional. Tx hashes that are allowed to revert without invalidating the bundle. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, destructiveHint=false) are already provided. The description adds context: bundles are forwarded to multiple relays, inclusion rate and analytics are available via separate endpoints, and returns a tracking_id for status checking. No contradictions with 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 but efficiently packs information: main purpose first, then forwarding behavior, cost, analytics, return value, and usage tip. Every sentence adds value, though it could be more structured with bullet points.
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?
No output schema, but the description mentions returning a tracking_id and how to check status via a separate endpoint. Covers input constraints (max 10 txs, exact block), usage tip, and post-submission actions. Adequate for the tool's 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 description coverage is 100%, so baseline is 3. The description adds value beyond schema: mentions max 10 per bundle for txs, explains blockNumber must be exact block, and describes revertingTxHashes as allowed to revert. Also mentions API key header usage.
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 a signed Ethereum bundle to MEV SearcherNet rbuilder, distinguishing it from sibling tools by positioning it as the follow-up after get_liquidation_waves or get_mev_feed. Specific verb+resource: 'Submit a signed Ethereum bundle directly to MEV SearcherNet rbuilder for inclusion.'
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 after get_liquidation_waves or get_mev_feed, and provides a tip pairing with get_liquidation_waves. Does not explicitly state when not to use, but the context is clear. Also mentions free with API key attribution, which is a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!