MEV Intelligence
Server Details
Derived MEV intelligence — liquidation waves, searcher leaderboards, and builder routing. Pay-per-call via x402 USDC on Base.
- 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 9 of 9 tools scored.
Most tools have distinct purposes (e.g., builder recommendation vs. bundle submission recommendation, liquidation waves vs. risk-enriched feed). However, a few pairs like `get_builder_recommendation` and `recommend_bundle_submission` could be confused, though descriptions differentiate them.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., `get_liquidation_waves`, `submit_bundle`, `predict_liquidation_probability`). No mixing of styles.
9 tools is appropriate for the MEV intelligence domain, covering opportunity discovery, prediction, builder recommendation, and submission without being excessive or too few.
The tool set covers the full workflow from monitoring to execution, including reporting and leaderboard. A minor gap is the lack of a direct tool to check submission status, though a tracking ID is provided for external query.
Available Tools
9 toolsget_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 already indicate read-only and open-world behavior. The description adds value by specifying that the recommendation is based on live relay acceptance rate and submission volume, and mentions an alternative full list with payment (x402). 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 concise (two sentences) and front-loaded with the main action. The second sentence adds useful return value and alternate access info. Could be slightly more streamlined, but efficient overall.
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 parameterless tool, the description adequately explains what it returns and the basis for the recommendation. The lack of an output schema is compensated by describing the output. Mention of the full ranked list adds completeness. No major gaps.
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 input schema has zero parameters and 100% coverage, so parameter documentation burden is minimal. The description does not need to add parameter details, but could hint at the lack of parameters. Baseline 4 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 states the tool's purpose: to get the best Ethereum block builder for MEV bundle submission in real-time based on live relay acceptance rate and submission volume. It specifies the output (top builder name and acceptance percentage) and distinguishes itself from siblings by focusing on builder recommendation rather than bundle submission.
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 implies usage context (MEV bundle submission, live data) but provides no explicit when-to-use or when-not-to-use guidance. A sibling tool 'recommend_bundle_submission' exists, but the description does not differentiate or offer exclusion criteria.
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 indicate readOnlyHint=true and destructiveHint=false. The description adds context about daily intelligence report and funnel metrics, but does not reveal significant behavioral traits beyond what annotations already provide. It references an accuracy archive, which is minor additional context.
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, front-loaded with essential information: first sentence states purpose and outputs, second provides usage guidance and resource reference. No wasted 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?
Given the simple parameter schema (one optional param), good annotations, and no output schema, the description fully covers what the tool does and its expected usage, including reference to an accuracy archive for further details.
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 clear description of window_hours parameter. The tool description does not add further meaning beyond the schema's description ('Lookback window in hours (default 24, max 48)'), so 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 states it gets a daily intelligence report summarizing liquidation market activity, listing specific metrics (competitor count, funnel stages, top candidate) and explicitly calls it the 'morning briefing' tool, distinguishing it from sibling tools like 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?
Explicitly states 'call it once per session to understand market state before executing', providing clear when-to-use guidance. Does not explicitly mention when not to use, but the context is sufficient for the agent to decide.
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. Description adds context by specifying the tool returns positions and is a read-only step before actual execution, with no contradictory information.
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 sentences, efficiently covering purpose, scope, return content, next steps, and alternative usage. Slightly front-loaded, but additional structure could improve skimmability.
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 sufficiently explains what is returned (top 10 positions with detailed fields) and how to proceed, covering all essential context.
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 parameter 'limit' described as 'Max results (default 10, preview max 10).' The description mentions 'Returns top 10 positions' but does not elaborate further, so it adds minimal value 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 the tool retrieves near-liquidation borrowers ranked by health factor across specific protocols (Aave V3, Spark, Morpho) and chains (L1 and Base), distinguishing it from sibling tools like monitor_crossing_candidates or get_daily_liquidation_report.
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 states when to use: after receiving targets, sign a liquidation transaction and call submit_bundle. Also advises to use a paid endpoint for net profit estimates and the full universe, providing clear context and alternatives.
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 mark the tool as read-only, and the description adds behavioral details: it returns exactly 10 positions and mentions the full stream is available elsewhere with a payment mechanism. This is useful 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?
Three efficient sentences: first states purpose, second details output, third provides alternative and action. No wasted 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?
For a simple one-parameter read tool, the description covers key aspects: purpose, output structure, data limitation, and integration with an alternative endpoint and sibling tool. No gaps given the low 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?
The schema has 100% description coverage for the single optional parameter, so the description does not need to add more. No extra meaning is provided beyond what the schema already specifies.
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 returns a risk-enriched MEV opportunity stream with specific fields (chain, protocol, health factor, risk tags) and a fixed count of 10 positions, distinguishing 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?
The description explicitly recommends using submit_bundle to act on opportunities, providing clear guidance on the next step. However, it lacks explicit 'when not to use' or differentiation from other analytical sibling tools like get_liquidation_waves.
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 readOnly, openWorld, and non-destructive behavior. The description adds that it returns top 5 with specific fields and a time window, but does not disclose additional behavioral traits like rate limits or authentication requirements. Minimal added value 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 efficiently convey purpose, return content, and a reference to the full leaderboard. No extraneous information. Front-loaded with the most critical 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?
The tool is simple with no parameters and no output schema, yet the description fully covers what it returns (top 5 searchers, specific fields) and its scope (last 4 hours). It also mentions a fuller alternative, making it self-contained for an 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?
With zero parameters and 100% schema coverage, the description does not need to add parameter details. The description adds context about the return fields and time window, which is useful. Baseline for no parameters is 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 retrieves top MEV searchers ranked by landed liquidation fires in the last 4 hours, specifying the resource, metric, and time window. It distinguishes itself from siblings which focus on different aspects like builder recommendations or liquidation reports.
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 context for use (top 5 searchers, last 4 hours) but does not explicitly state when to use this tool versus alternatives. It mentions the full leaderboard as an alternative with payment, offering some guidance, but lacks explicit when-not-to-use instructions.
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 indicate readOnlyHint=true and destructiveHint=false. The description adds that it returns sorted candidates with specific fields, providing context beyond annotations without contradiction.
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. The purpose is front-loaded, and each sentence serves a clear function.
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 read-only tool with two optional parameters and no output schema, the description sufficiently explains the return fields and how to use the result, making it 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 the schema already documents both parameters. The description adds no additional semantics beyond what the schema provides, meeting the baseline for high 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 states the tool gets the highest-priority liquidation candidates sorted by cross probability, specifying verb, resource, and criteria. It distinguishes from siblings by listing specific fields returned and its use case.
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 guidance on when to use (prioritize pre-building bundles) and what to do next (call submit_bundle when HF=1.0). This helps select this tool over alternatives like get_daily_liquidation_report.
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 mark it as read-only, open-world, non-destructive. The description adds behavioral context by detailing the return fields and stating it is the prediction layer driving bundle decisions. 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?
Two concise sentences front-loaded with the purpose and output, followed by a critical usage note and a reference to an extended model. No superfluous 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 prediction tool with two optional params and no output schema, the description thoroughly explains inputs, outputs, usage context, and even points to an extended version. All relevant aspects are covered.
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 covers both parameters fully. Description adds value by explaining that omitting borrower returns top 5 candidates and that protocol is an optional filter when borrower is not specified, enhancing parameter meaning 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 the tool returns a structured liquidation probability prediction for a specific borrower or top candidates, listing exact output fields. It distinguishes itself from siblings by being the 'core moat tool' and explicitly positioning it as a prerequisite to 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 explicitly instructs to call this tool before submit_bundle to confirm opportunity liveness and size bribes. It also notes that omitting borrower returns top 5 candidates, and references a more detailed external endpoint, giving clear when-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 already declare readOnlyHint=true, but description adds value by detailing returned fields (builder, probability, reason) and data source (live relay telemetry). No contradiction.
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, no fluff. First sentence states purpose, second provides usage guidance. Efficient and front-loaded.
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 explains return values. Context of live telemetry and pairing with sibling tool make it fully self-contained.
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?
Single optional parameter 'borrower' with schema description. Description adds no new semantic info beyond the schema, but schema coverage is 100%, so baseline 3.
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?
Description clearly states the tool returns an actionable bundle submission recommendation for a borrower or market conditions. It distinguishes from sibling monitor_crossing_candidates by specifying this tool decides WHERE to submit.
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 suggests pairing with monitor_crossing_candidates and explains the workflow. No explicit when-not, but context is clear.
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. 100% acceptance rate. Free with API key attribution (X-Api-Key header). 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?
The description adds behavioral context beyond annotations: 100% acceptance rate, free with API key attribution, forwarding to multiple relays, and returns a tracking_id. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).
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 concise (~100 words) and well-structured: primary action first, then context, details, and a tip. No redundant 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 4 parameters and no output schema, the description fully explains the return value (tracking_id), how to use it, and integrates with sibling tools. It covers all necessary information for an AI agent to use the tool 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%, but the description adds a useful constraint ('Max 10 per bundle') for the 'txs' parameter that is not in the schema description. Other parameters are adequately described.
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 states a specific verb ('Submit') and resource ('signed Ethereum bundle to MEV SearcherNet rbuilder'), clearly distinguishing it from sibling informational tools like get_liquidation_waves or recommend_bundle_submission.
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 states when to use the tool: 'Use this after get_liquidation_waves or get_mev_feed'. It provides a concrete usage tip but does not mention when not to use it or alternative tools.
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!