Static source inference · medium confidence · evidence: Streamable HTTP
Current-spec patterns detected
Summary
The Conflux MCP Server registers 10 blockchain-focused read-only tools with consistent naming (verb_noun pattern: get_*, all starting with 'get'). All tools have descriptions and input schemas defined via Zod. However, descriptions are generic and lack actionable guidance for LLM selection; output schemas are not explicitly documented; and parameters lack constraint details (e.g., address format validation, network enum values). Error handling is present but basic. No tool annotations (readOnlyHint, etc.) despite all tools being READ_ONLY. Composition is clean, each tool has one responsibility, but parameter validation rules are implicit rather than explicit in descriptions.
Tools (10)
estimate_gasread onlysource verified67/100
Estimate the gas cost for a transaction
get_balanceread onlysource verified67/100
Get the native token balance (Conflux) for an address
Output schemas not documented. Tools return structured JSON but no schema is declared in the tool registration, forcing LLMs to infer output shape. This increases parsing errors and ambiguity.
Descriptions lack actionable guidance. Descriptions are generic ('Get X by Y') without explaining when to use this tool vs similar ones, prerequisites, or typical next steps. E.g., 'get_erc20_balance' vs 'get_token_balance' descriptions are nearly identical, forcing LLMs to reason about subtle differences.
Add explicit output schema documentation to all tools. Define the structure returned (e.g., 'Returns: { chainId: string, blockNumber: string, rpcUrl: string, network: string }'). This can be added as a comment or formal schema field.
Enhance descriptions with LLM decision-making guidance. Rewrite 'Get the balance of an ERC20 token for an address' as 'Fetch an ERC20 token balance for a specific owner. Use when you need to check how many of a specific token contract an address holds. Returns a numeric balance string.'
Define network parameter as an enum or document valid values. Update description: 'Network name or chain ID. Valid: conflux, conflux-testnet, conflux-devnet, or numeric chain IDs (1029 for mainnet, 71 for testnet, 999 for devnet). Defaults to 'conflux' (mainnet).'
Specify address format constraints in parameter descriptions. Change 'The wallet address' to 'The wallet address (0x-prefixed 42-character hex string, e.g., 0x1234...abcd). Checksummed addresses optional but recommended.'
Add tool annotations to all definitions. Use server.tool() with a fourth parameter for annotations: { readOnlyHint: true, idempotentHint: true } for all 10 tools. This enables client-side safety filtering.
Differentiate or consolidate get_erc20_balance vs get_token_balance. Either merge them into one (parameterized by token standard) or rename one to clarify (e.g., 'get_cip20_balance' if CIP-20 is specific to Conflux).
Improve error handling with categorization. Wrap errors: { content: [...], isError: true, retryable: true/false, fixableByUser: true/false, suggestion: 'If network is invalid, call get_supported_networks()' }. This guides agent recovery.
Score history
Overall score trend
↑ 23 points across a rubric change (v1 → v2)
69/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
C
69
2026-07-28+
v2
2026-03-09
F
46
-
v1
65/100
Get the balance of an ERC20 token for an address
get_transactionread onlysource verified68/100
Get detailed information about a specific transaction by its hash. Includes sender, recipient, value, data, and more.
Network parameter validation rules not explicit. The 'network' parameter accepts 'network name (e.g., conflux, conflux-testnet)' or 'chain ID' but does not enumerate valid values or constraints. LLMs may hallucinate invalid network names. Should use an enum or explicit pattern.
Address and tokenAddress format not documented. Parameters like 'address' and 'tokenAddress' lack format constraints (e.g., '0x' prefix, hex length, checksum rules). LLMs may pass invalid formats. Should specify '0x-prefixed 42-character hex string'.
Tool annotations missing. All 10 tools are READ_ONLY but none declare readOnlyHint=true in their definition. This prevents clients from filtering read-only tools or enforcing write safety. Missing idempotentHint on all tools despite being idempotent.
Error messages are generic. Error responses in catch blocks return '[action] error: [message]' but do not guide the LLM on recovery or categorize errors as retryable vs user-fixable. E.g., a network timeout should differ from an invalid address.
Duplicate tool purpose: get_erc20_balance and get_token_balance both fetch ERC20 token balances but with slightly different parameter names (tokenAddress+address vs tokenAddress+ownerAddress). LLMs will be confused about which to call. Should consolidate or clearly differentiate.
estimate_gas has optional/unclear parameters. The 'to', 'value', and 'data' fields lack indication of which are required vs optional, and 'data' lacks encoding format (hex vs plaintext). Should clarify 'data' is optional calldata in 0x-prefixed hex format.
estimate_gas
Document estimate_gas parameter dependencies. Clarify: 'to: recipient address (required), value: amount in CFX or 0x-hex (optional, defaults to 0), data: calldata in 0x-prefixed hex (optional, defaults to empty for transfers).'
Add pagination guidance if any tool might return large result sets. E.g., if get_transaction is called with a filter, cap results and document: 'Returns up to 100 most recent transactions. Implement pagination client-side if more are needed.'
Include dependency hints in descriptions. E.g., 'If you only have a token symbol, call get_supported_networks() first to find its contract address, then call get_token_balance().'
Return IDs and references that enable chaining. Ensure get_block_by_number returns blockHash, so get_transaction can filter by block; ensure get_transaction returns full txHash for get_transaction_receipt.