Loading ToolBench
MCP server for Phoenix Zero L2 health oracle — kernel-level network telemetry for AI agents
Two tools with reasonable descriptions but critical schema gaps. check_safety_free has a well-written description (156 chars) explaining the free tier, use case, and prevention benefit. preflight_network_health has an excellent description (287 chars) covering data sources and evidence types. However, both tools have incomplete input schemas: the 'chain' parameter lacks a type declaration (only enum values visible), and preflight_network_health's 'metric' parameter is missing from the visible schema definition. No output schemas are documented. Parameter descriptions are present but minimal. No error handling guidance visible. Tool names follow verb_noun pattern (check_, preflight_) which is good, but lack of complete schema definitions and missing output documentation significantly limits LLM usability.
FREE safety check for L2 networks — no payment required (100 calls/IP/day). Returns safe/unsafe verdict with reason code. Use this first to sample data before committing to paid x402 endpoints. Prevents $5-$15 gas loss on failed transactions during sequencer stalls.
Determine whether an L2 network is currently suitable for transaction execution using kernel-level network telemetry. Returns PASS, DEGRADED, or FAIL with RTT, packet-loss and timestamp evidence. Covers 12 L2 chains (Base, Arbitrum, Optimism, zkSync, Scroll, Mantle, Linea, Blast, Mode, Taiko, Polygon zkEVM, Casper). Data sourced from eBPF XDP probes with 2-second sampling interval, signed with BLAKE3+Ed25519.
Input schemas lack explicit type declarations. 'chain' parameter shows only enum values without 'type' field; 'metric' parameter missing entirely from schema definition despite being documented in description.
No output schemas documented. LLMs cannot plan downstream operations or extract return fields without knowing the response structure (e.g., what fields does 'safe/unsafe verdict' contain? What is the structure of RTT/packet-loss evidence?).
Parameter descriptions are minimal. 'chain' description is only 40 chars; 'metric' description lacks guidance on when to use each option or cost implications of paid metrics.
No error handling guidance. Descriptions mention '100 calls/IP/day' rate limit and '$5-$15 gas loss' but do not explain what happens when limits are exceeded or how to recover.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
Tool composition unclear. Both tools operate on L2 chains but relationship is not documented. When should an agent call check_safety_free vs preflight_network_health? What is the intended workflow?