Cloudflare Workers-based MCP server for DEX operations, AI analysis, database queries, and container execution with GraphQL-powered data fetching
Server has 40 tools spanning AI analysis, DEX operations, and cache management. However, significant definition quality gaps prevent higher scoring. While tool names generally follow verb-noun convention, many tools have incomplete or missing input schemas (10 tools have empty or near-empty input objects), vague descriptions lacking specificity about prerequisites and return behavior, and no visible output schema documentation. Parameter descriptions exist but are inconsistent in depth. Error handling guidance is absent. The server appears functional but lacks the rigor expected of production-grade MCP servers.
AI chat completion endpoint supporting streaming and non-streaming modes with configurable temperature and token limits
Code analysis tool that examines code for security vulnerabilities, performance issues, style problems, or bugs with streaming support
Smart contract security and optimization analysis for Solidity contracts, including vulnerability detection and gas optimization recommendations
Clear all cached data from Cloudflare KV storage
Delete cached data from Cloudflare KV storage
Retrieve cached data from Cloudflare KV storage by key
Store data in Cloudflare KV cache with optional TTL
Execute shell commands in a sandbox container with support for working directory context
10 tools have empty or near-empty input schemas (get-swaps, get-liquidity, get-fees, get-price, get-vaults, get-vaults-analytics, get-vaults-strategies, get-farms, cache-status, dex-health-check, subgraph-metadata, ai-health-check). This violates pattern:constrained-input which requires explicit parameter documentation.
Tool descriptions lack specificity about prerequisites, return structure, and when to call each tool. Many descriptions are generic (35-60 chars) falling below the production baseline of ~194 chars average. Descriptions do not explain what downstream data is returned for composition. Example: 'get-pools' says 'Retrieves list of liquidity pools' but does not mention pagination, filtering by fee tiers, or what fields are returned (pool ID, token addresses, etc.). Per pattern:tool-description, incomplete descriptions prevent LLMs from selecting tools confidently.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 11 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 34 | - | v1 |
Execute SQL queries against Cloudflare D1 database with support for parameterized queries and transactions
Generates DeFi investment strategy recommendations based on user profile, risk tolerance, investment amount, and market conditions
Fetch user's farming/vault positions with detailed TVL, APY, and reward information
Fetch DEX pool data from GraphQL including pair information, reserves, liquidity, volume, fees, and APR/APY metrics
Fetch user's liquidity positions and farming positions across DEX pools with detailed metrics
Fetch user reward information including claimable rewards, reward history, and merkle proofs for reward claims
Fetch vault information including strategy, risk level, TVL, APY, and fee structure
Delete files from Cloudflare R2 bucket storage
Download files from Cloudflare R2 bucket storage by key
Upload files to Cloudflare R2 bucket storage with support for metadata and content-type specification
No output schema documentation visible for any tool. The rubric requires documented return types for composition (pattern:tool and mxe:include-chaining-ids). Agents cannot plan downstream calls or extract necessary IDs (e.g., pool_id from get-pools, vault_id from get-vaults) without knowing what fields are returned. This breaks tool chaining and forces agents to guess at response structures.
No error handling guidance in tool descriptions. When get-user-bin-ids fails (user has no positions, pool not found, invalid address), there is no indication of what error code or message to expect, or what the agent should do next. Per pattern:recovery-guide, error responses must tell the LLM: 'Try search_users() with a partial name' or 'Invalid chain: valid options are arbitrum, bsc, ethereum'. Current design leaves agents stuck on failures.
run-sandbox-command allows arbitrary shell execution (IRREVERSIBLE risk). No confirmation step, no input sanitization visible, and descriptions do not warn about injection risks. Per pattern:confirmation-request, destructive/irreversible tools must support dry-run or confirmation. A malicious or confused agent could execute rm -rf / via this tool. Requires pattern:secret-injection to isolate environment and pattern:tool-gateway to sanitize input.
clear-all-cache (DESTRUCTIVE) lacks confirmation or dry-run. No description warning about irreversibility. Per pattern:confirmation-request, agents should never execute destructive operations without explicit confirmation or audit. One typo or context mix-up could nuke all cached DEX data.
Parameter naming inconsistency. Some tools use 'address' (get-user-farms), others use 'user_address' (get-user-bin-ids, get-user-pool-ids). Per pattern:tool-chain and rubric naming rule, when multiple tools operate on the same resource, naming must be consistent. LLMs will struggle to map outputs from one tool as inputs to another.
Pagination and result limiting not documented. No mention of limit, offset, page_size, or total_count in any tool description. Per pattern:paginated-result and mxe:enforce-result-limits, large result sets (e.g., get-pools, get-tokens across multiple chains) risk context window exhaustion. If get-pools returns 1000 pools, that alone could exhaust an agent's reasoning budget.
No idempotency or retry guidance. cache invalidation tools (invalidate-pool-cache, invalidate-user-cache, clear-all-cache) do not declare idempotency. If an agent retries an invalidation call, does it succeed twice (idempotent) or error on the second attempt? Per pattern:idempotent-operation, agents rely on idempotency to handle transient failures safely.
Batch variants missing for high-frequency operations. Per pattern:tool composition, agents calling add_labels in a loop waste tokens. This server lacks batch tools for operations like invalidating multiple cache keys or fetching multiple vault details in one call. Agents must make N separate calls instead of one batch call.