F
licenseNot graded
qualityD
maintenancePay-per-use AI security and research tools for autonomous agents on Base, enabling honeypot detection, risk assessment, wallet analysis, and yield optimization via the x402 protocol.
1
-
x402 Agent Tollbooth
Server Details
On-chain DeFi smart contract auditor, arbitrage scanner, and agent tollbooth via x402 on Base.
Ownership verified
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
- Status
- Unhealthy
- Uptime
- 91.5% over 20 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2024-11-05
- URL
- Repository
- ak10082247-max/x402-agent-tollbooth
- GitHub Stars
- 0
- Server Listing
- x402-agent-tollbooth
- ChatGPT
- –
- Claude
- –
TDQS
B3.3/5.0
Scored across 4 tools
Disambiguation3/5
arbitrage_scan and smart_router are distinguishable (finding opportunities vs. computing execution routes), but ai_intel and contract_audit overlap heavily — both claim to scan Base contracts for vulnerabilities, and only subtle wording ('logic vulnerabilities and exploits' vs. 'live auditor') plus a 20x cost difference separates them. An agent could easily pick the wrong one for a contract security check.
Naming Consistency4/5
All four names are lowercase snake_case two-token descriptive noun phrases (ai_intel, arbitrage_scan, contract_audit, smart_router), which is predictable and readable. However, there is no consistent verb_noun action pattern and the token ordering varies (noun_verb vs. noun_noun vs. adjective_noun), so the action each tool performs isn't encoded in the name.
Tool Count4/5
Four tools is a lean, well-scoped set for a paid micro-service tollbooth where each endpoint has a clear monetized function. Nothing feels padded, though it's on the thin side for an 'agent tollbooth' aggregator.
Completeness3/5
The surface covers scanning, arbitrage discovery, auditing, and route computation, but dead-ends after the compute step: there is no execution/swap tool, no balance or payment-status check despite every tool charging USDC, and no way to verify or retrieve prior scan results. Agents can work around this by using external execution, but key lifecycle pieces are missing.
Available Tools
4 toolsai_intelBRead-onlyInspect
Deep AI Vulnerability & Intelligence Engine. Scans contracts and code for logic vulnerabilities and exploits on Base. Cost: 0.001 USDC on Base & Solana (100% gasless).
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | No | Analysis prompt or contract source code to audit | |
| limited_review | No | Explicitly purchase only a limited source-pattern review at the quoted endpoint price; this mode does not provide an AI audit or patch | |
| contractAddress | No | Base smart contract address to audit |
Output Schema
| Name | Required | Description |
|---|---|---|
| limits | No | |
| method | No | |
| status | Yes | |
| service | Yes | |
| endpoint | Yes | |
| findings | No | |
| safety_proven | No |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavioral context the annotations lack – a 0.001 USDC charge on Base and Solana, gasless – but it never says how payment is triggered or settled, which is the key operational unknown for a paid call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the capability before the cost. 'Deep AI Vulnerability & Intelligence Engine' is marketing padding that does not earn its place, but the remainder is tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema, annotations, and zero required params, the definition covers purpose and price adequately. It is still incomplete on the two things an agent most needs for a paid, sibling-overlapping tool: how payment is executed and why to pick this over contract_audit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and all three parameters are documented in-schema, including the limited_review caveat. The description adds no parameter-level meaning beyond that, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: scans contracts and code for logic vulnerabilities and exploits on Base. The domain (Base contracts) is pinned down, but it never distinguishes itself from the sibling contract_audit, which reads as the same job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied – an agent can infer 'call this to audit a contract on Base' – but there is no explicit when-to-use, no when-not-to-use, and no routing to arbitrage_scan, contract_audit, or smart_router. The cost note informs a decision but does not guide tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
arbitrage_scanBRead-onlyInspect
Cross-DEX Arbitrage & Liquidity Scanner. Analyzes Uniswap, Aerodrome, and BaseSwap pools for profitable routing opportunities. Cost: 0.002 USDC on Base & Solana (100% gasless).
| Name | Required | Description | Default |
|---|---|---|---|
| pair | No | Token pair to scan, e.g. WETH/USDC | |
| chain | No | base | |
| amount | No | Human units of the first token, defaults to 1; exact raw units are derived from on-chain decimals | |
| slippage_bps | No | ||
| min_spread_bps | No | Minimum spread in basis points |
Output Schema
| Name | Required | Description |
|---|---|---|
| limits | No | |
| routes | No | |
| status | Yes | |
| service | Yes | |
| endpoint | Yes | |
| is_profitable | No | |
| pairs_scanned | No | |
| profitable_routes | No |
TDQS
B3.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety behavior is covered. The description adds useful context beyond annotations by disclosing the 0.002 USDC cost and that execution is gasless on Base and Solana, though it does not explain payment/auth mechanics or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with the core purpose front-loaded, followed by coverage and cost. Every sentence contributes useful information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and annotations cover the safety profile. However, the description lacks usage guidance versus siblings and adds no parameter semantics, leaving moderate gaps for a five-parameter scanner.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the five parameters, and schema description coverage is only 60%, leaving chain and slippage_bps without narrative descriptions. Since the description adds no parameter meaning beyond the schema, it does not compensate for the moderate coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: it analyzes Uniswap, Aerodrome, and BaseSwap pools for cross-DEX arbitrage and liquidity opportunities. It is clear what the tool does, though it does not explicitly differentiate itself from siblings like smart_router.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for finding arbitrage opportunities, but it gives no explicit conditions for when to use it versus alternatives such as smart_router. There are no prerequisites, exclusions, or alternative-tool guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contract_auditBRead-onlyInspect
Live Smart Contract AI Auditor. Analyzes Base contracts for vulnerabilities. Cost: 0.02 USDC via x402 protocol. Cost: 0.02 USDC on Base & Solana (100% gasless).
| Name | Required | Description | Default |
|---|---|---|---|
| isPatch | No | Whether to generate a patch | |
| limited_review | No | Explicitly purchase only a limited source-pattern review at the quoted endpoint price; this mode does not provide an AI audit or patch | |
| contractAddress | No | The Base network smart contract address to audit. |
Output Schema
| Name | Required | Description |
|---|---|---|
| limits | No | |
| status | Yes | |
| service | Yes | |
| endpoint | Yes | |
| findings | No | |
| safety_proven | No |
TDQS
B3.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds genuinely useful context beyond annotations: a 0.02 USDC cost via the x402 protocol, gasless payment, and Base/Solana support. However, the cost is stated twice in conflicting phrasing ('via x402 protocol' vs 'on Base & Solana (100% gasless)'), and there is no disclosure of latency, what happens if payment fails, or whether the x402 charge occurs before or after analysis.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence, but the duplicated and slightly contradictory cost sentences waste space and could confuse an agent about payment mechanics. The core content could be two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema and annotations cover return values and safety profile, so the description needn't explain those. But with zero required parameters yet a mandatory-sounding contractAddress audit, the definition never clarifies that an address must actually be supplied, nor what limited_review excludes in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented with defaults and intent. The description adds nothing about contractAddress, isPatch, or the limited_review trade-off beyond what the schema states, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and resource: audits Base smart contracts for vulnerabilities. Siblings (ai_intel, arbitrage_scan, smart_router) are clearly different domains, so no explicit disambiguation is required, though none is offered.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to invoke this vs. alternatives (e.g., when to prefer the limited_review mode or when an audit is overkill). The only conditional context is an implicit reference to a 'limited source-pattern review' parameter, with no usage conditions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
smart_routerBRead-onlyInspect
Optimal Execution Smart Router. Computes optimal gas and slippage routing paths for Base AI agents and automated executors. Cost: 0.001 USDC on Base & Solana (100% gasless).
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | base | |
| amount | No | Trade amount | |
| tokenIn | No | Input token address or symbol | |
| tokenOut | No | Output token address or symbol | |
| slippage_bps | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| limits | No | |
| status | Yes | |
| service | Yes | |
| endpoint | Yes | |
| optimal_routes | No |
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, and the description is consistent with a computation/quote tool. It adds useful non-obvious context about cost and gasless operation, but it does not explain payment/auth mechanics, rate limits, or whether the output is strictly a route/quote beyond what the readOnly annotation implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences and front-loads the core function before the cost note. 'Optimal Execution Smart Router' slightly repeats 'optimal' from the following sentence, but the overall text is efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and the annotations cover the safety profile, so return values and read-only behavior do not need heavy explanation. Still, for a five-parameter paid routing tool, the description omits required-input expectations, prerequisites, and alternatives, leaving meaningful gaps for an agent choosing how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 60%, and the description adds no meaning about amount units, token address/symbol formats, slippage_bps, or chain defaults. The schema itself documents the three main token/amount fields and slippage bounds, but the description does not compensate for the remaining gaps or clarify optionality despite zero required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Computes optimal gas and slippage routing paths' for Base AI agents and automated executors. It is clear what the tool does, but it does not explicitly differentiate itself from siblings such as arbitrage_scan or ai_intel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended audience and cost imply usage for optimal execution routing. However, there is no explicit when-to-use guidance, no when-not guidance, no prerequisites, and no named alternatives among ai_intel, arbitrage_scan, and contract_audit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
ai_intel1 field changed- added
Input schema / properties / limited_reviewAdded value: +{ + "default": false, + "description": "Explicitly purchase only a limited source-pattern review at the quoted endpoint price; this mode does not provide an AI audit or patch", + "type": "boolean" +}
- Changed
contract_audit1 field changed- added
Input schema / properties / limited_reviewAdded value: +{ + "default": false, + "description": "Explicitly purchase only a limited source-pattern review at the quoted endpoint price; this mode does not provide an AI audit or patch", + "type": "boolean" +}
4 tool updates
- Changed
ai_intel8 fields changed- added
Output schema / properties / findingsAdded value: +{ + "type": "array" +} - removed
Output schema / properties / intelRemoved value: -{ - "type": "string" -} - removed
Output schema / properties / latency_msRemoved value: -{ - "type": "integer" -} - added
Output schema / properties / limitsAdded value: +{ + "type": "array" +} - added
Output schema / properties / methodAdded value: +{ + "type": "string" +} - added
Output schema / properties / safety_provenAdded value: +{ + "type": "boolean" +} - removed
Output schema / properties / scoreRemoved value: -{ - "type": "integer" -} - removed
Output schema / properties / verified_byRemoved value: -{ - "type": "string" -}
- Changed
arbitrage_scan10 fields changed- added
Input schema / properties / amountAdded value: +{ + "description": "Human units of the first token, defaults to 1; exact raw units are derived from on-chain decimals", + "type": "string" +} - added
Input schema / properties / chainAdded value: +{ + "default": "base", + "enum": [ + "base", + "solana" + ], + "type": "string" +} - added
Input schema / properties / slippage_bpsAdded value: +{ + "default": 50, + "maximum": 1000, + "minimum": 1, + "type": "integer" +} - added
Output schema / properties / is_profitableAdded value: +{ + "type": "boolean" +} - removed
Output schema / properties / latency_msRemoved value: -{ - "type": "integer" -} - added
Output schema / properties / limitsAdded value: +{ + "type": "array" +} - removed
Output schema / properties / net_spread_bpsRemoved value: -{ - "type": "integer" -} - added
Output schema / properties / routesAdded value: +{ + "type": "array" +} - removed
Output schema / properties / top_routeRemoved value: -{ - "type": "string" -} - removed
Output schema / properties / verified_byRemoved value: -{ - "type": "string" -}
- Changed
contract_audit8 fields changed- removed
Output schema / properties / auditRemoved value: -{ - "type": "string" -} - added
Output schema / properties / findingsAdded value: +{ + "type": "array" +} - removed
Output schema / properties / latency_msRemoved value: -{ - "type": "integer" -} - added
Output schema / properties / limitsAdded value: +{ + "type": "array" +} - added
Output schema / properties / safety_provenAdded value: +{ + "type": "boolean" +} - removed
Output schema / properties / scoreRemoved value: -{ - "type": "integer" -} - removed
Output schema / properties / verified_byRemoved value: -{ - "type": "string" -} - removed
Output schema / properties / vulnerabilitiesRemoved value: -{ - "type": "array" -}
- Changed
smart_router9 fields changed- added
Input schema / properties / chainAdded value: +{ + "default": "base", + "enum": [ + "base", + "solana" + ], + "type": "string" +} - added
Input schema / properties / slippage_bpsAdded value: +{ + "default": 50, + "maximum": 1000, + "minimum": 1, + "type": "integer" +} - removed
Output schema / properties / expected_slippage_bpsRemoved value: -{ - "type": "integer" -} - removed
Output schema / properties / gas_estimate_gweiRemoved value: -{ - "type": "number" -} - removed
Output schema / properties / latency_msRemoved value: -{ - "type": "integer" -} - added
Output schema / properties / limitsAdded value: +{ + "type": "array" +} - removed
Output schema / properties / optimal_dexRemoved value: -{ - "type": "string" -} - added
Output schema / properties / optimal_routesAdded value: +{ + "type": "array" +} - removed
Output schema / properties / verified_byRemoved value: -{ - "type": "string" -}
4 tool updates
- Changed
ai_intel1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "endpoint": { + "type": "string" + }, + "intel": { + "type": "string" + }, + "latency_ms": { + "type": "integer" + }, + "score": { + "type": "integer" + }, + "service": { + "type": "string" + }, + "status": { + "type": "string" + }, + "verified_by": { + "type": "string" + } + }, + "required": [ + "status", + "service", + "endpoint" + ], + "type": "object" +}
- Changed
arbitrage_scan1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "endpoint": { + "type": "string" + }, + "latency_ms": { + "type": "integer" + }, + "net_spread_bps": { + "type": "integer" + }, + "pairs_scanned": { + "type": "integer" + }, + "profitable_routes": { + "type": "integer" + }, + "service": { + "type": "string" + }, + "status": { + "type": "string" + }, + "top_route": { + "type": "string" + }, + "verified_by": { + "type": "string" + } + }, + "required": [ + "status", + "service", + "endpoint" + ], + "type": "object" +}
- Changed
contract_audit1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "audit": { + "type": "string" + }, + "endpoint": { + "type": "string" + }, + "latency_ms": { + "type": "integer" + }, + "score": { + "type": "integer" + }, + "service": { + "type": "string" + }, + "status": { + "type": "string" + }, + "verified_by": { + "type": "string" + }, + "vulnerabilities": { + "type": "array" + } + }, + "required": [ + "status", + "service", + "endpoint" + ], + "type": "object" +}
- Changed
smart_router1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "endpoint": { + "type": "string" + }, + "expected_slippage_bps": { + "type": "integer" + }, + "gas_estimate_gwei": { + "type": "number" + }, + "latency_ms": { + "type": "integer" + }, + "optimal_dex": { + "type": "string" + }, + "service": { + "type": "string" + }, + "status": { + "type": "string" + }, + "verified_by": { + "type": "string" + } + }, + "required": [ + "status", + "service", + "endpoint" + ], + "type": "object" +}
4 tool updates
- First observed
ai_intel - First observed
arbitrage_scan - First observed
contract_audit - First observed
smart_router
Related MCP Connectors
Real-time token contract safety scanner and honeypot auditor via x402 on Base.
x402 contract tools and premium portfolio scans for AI agents on Base.
DeFi pool yield+security intelligence & token/contract risk scanner. USDC on Base via x402.
On-chain token security, honeypot simulation, KYA wallet trust, and x402 PreFlight audits on Base.
Related MCP Servers
AgentRiskofficial
FlicenseNot gradedqualityCmaintenancePre-Trade Security & Risk Analysis Layer for Autonomous DeFi Agents on Base using x402 protocol.-
hyperd-mcpofficial
AlicenseAqualityDmaintenancePre-trade DeFi intelligence for AI agents. 20 paid x402 endpoints, USDC on Base.23113 npm1MIT- AlicenseAqualityCmaintenanceEnables AI assistants and CLI users to run automated bytecode security audits of EVM smart contracts on Base Mainnet, detecting risky opcodes and interface signatures, scoring risk, and unlocking verified results via x402 USDC micropayments.3MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.