On-chain DEX aggregator quotes, phantom-liquidity scanning, and live proof-of-solvency across Base, Ethereum, Optimism, Arbitrum, and Robinhood Chain. Keyless, no auth.
Scored across 2 tools
check_solvency and get_quote address clearly different concerns: one inspects staking protocol solvency, the other returns swap quotes with safety verdicts. There is no realistic overlap or ambiguity between them.
Both tool names follow the same lowercase verb_noun pattern: check_solvency and get_quote. The naming convention is fully consistent.
With only two tools, the server feels thin for the apparent staking and DEX quoting scope. However, both tools are purposeful and a narrow read-only safety/quote focus could partially justify the small surface.
The server covers read-only solvency checking and quote generation but lacks action tools such as stake/unstake or swap execution, and there is no obvious way to act on the signable calldata. For a staking plus DEX domain, this leaves significant lifecycle gaps.
Read the BlazePhoenix staking engine's live proof-of-solvency from the chain: isSolvent(), collateral ratio and reserve figures. Zero trust required — the numbers are re-read from contract storage on every call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the transparency burden. It discloses that data is re-read from contract storage on every call, implying freshness and trustlessness, which goes beyond the empty schema. It does not mention failure modes or edge cases, but for a parameterless read operation, this is adequate.
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 action and resource, and every word earns its place. It conveys the key behavior and return values 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 zero parameters, no output schema, and no annotations, the description effectively explains what the tool does and what it returns. It is self-contained and complete for a simple read-only check, with no unexplained 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 tool has zero parameters, so the input schema is empty. The description adds context about what data is returned (isSolvent, collateral ratio, reserves), which is useful despite the absence of parameters. Baseline for 0 params is 4, and the description does not detract from this.
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 reads live proof-of-solvency data from the BlazePhoenix staking engine, naming specific elements (isSolvent(), collateral ratio, reserve figures). This distinguishes it from sibling tools like get_quote and xray_scan by resource and action.
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 for obtaining solvency information and emphasizes 'zero trust required', but it does not explicitly state when to use this tool vs alternatives or provide exclusions. No comparison to sibling tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an on-chain DEX aggregator quote (computed by the Quoter contract, not an off-chain API). Returns route, expected output, price impact and the enforced minimum. The checks object carries the Phoenix Check verdicts — priceImpact (against a 20% hard line), the on-chain Iron Law floor, and a cross-check note — with an overall verdict that fails closed (blocked/danger/caution/ok): quote these when a user asks whether a swap is safe. Add recipient to also receive signable transaction calldata.
| Name | Required | Description | Default |
|---|---|---|---|
| in | Yes | input token — symbol (ETH, USDC, BZPX…) or 0x address | |
| out | Yes | output token — symbol or 0x address | |
| rpc | No | optional https RPC endpoint of YOUR OWN node — when set, the read is made through it instead of our shared pool. The service stays free either way; this simply keeps your volume off our quota (and off everyone else's). | |
| chain | Yes | base | eth | optimism | arbitrum | robinhood (or a chain id) | |
| exact | No | true → execution-grade re-quote (previewPlanExact, slower) | |
| amountIn | Yes | input amount in the token's smallest units (wei-style integer string) | |
| recipient | No | optional 0x address; when set, the response includes signable tx calldata | |
| deadlineSec | No | tx deadline horizon in seconds, 10–3600 (default 120) | |
| slippageBps | No | 0–5000; minOut = netOut − slippage (default: the protocol floor) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers: it discloses the computation source (on-chain Quoter vs off-chain API), the conditional output extension ('Add recipient to also receive signable transaction calldata'), and the fails-closed verdict semantics (blocked/danger/caution/ok against a 20% hard line and Iron Law floor). No contradiction 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?
Four sentences, front-loaded with the core purpose before any detail. The densest sentence (the checks object) earns its length because it defines verdict semantics the agent must surface to users, and no sentence is wasted.
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?
With no output schema and no annotations, the description covers the return shape (route, expected output, price impact, enforced minimum, checks verdicts) and the conditional calldata behavior. It omits failure/error behavior and the practical action implied by each verdict tier, but 100% parameter coverage in the schema keeps the gap small.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds only marginal parameter meaning: it ties slippageBps to the 'enforced minimum' concept and restates recipient's calldata behavior that the schema already documents. It does not meaningfully compensate beyond that.
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?
States a specific verb and resource — 'Get an on-chain DEX aggregator quote' — and adds a distinguishing method detail ('computed by the Quoter contract, not an off-chain API'). It also frames its purpose as swap-safety ('quote these when a user asks whether a swap is safe'), which separates it from the sibling check_solvency even without naming it.
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?
Gives an explicit trigger condition: 'quote these when a user asks whether a swap is safe.' This is clear context for when the tool applies. It falls short of a 5 because it does not name check_solvency as the alternative nor provide when-not-to-use exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_quote3 fields changedInput schema / properties / deadlineSecAdded value: +{
+ "description": "tx deadline horizon in seconds, 10–3600 (default 120)",
+ "type": "integer"
+}Input schema / properties / exactAdded value: +{
+ "description": "true → execution-grade re-quote (previewPlanExact, slower)",
+ "type": "boolean"
+}Input schema / properties / slippageBpsAdded value: +{
+ "description": "0–5000; minOut = netOut − slippage (default: the protocol floor)",
+ "type": "integer"
+}xray_scanget_quote1 field changedInput schema / properties / rpcAdded value: +{
+ "description": "optional https RPC endpoint of YOUR OWN node — when set, the read is made through it instead of our shared pool. The service stays free either way; this simply keeps your volume off our quota (and off everyone else's).",
+ "type": "string"
+}xray_scan1 field changedInput schema / properties / rpcAdded value: +{
+ "description": "optional https RPC endpoint of YOUR OWN node — when set, the read is made through it instead of our shared pool. The service stays free either way; this simply keeps your volume off our quota (and off everyone else's).",
+ "type": "string"
+}check_solvencyget_quotexray_scan
Add one secure layer between your agents and this server.