Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
Server provides 5 blockchain transaction lookup tools with reasonable naming and consistent schemas. However, descriptions are minimal (1-2 sentences), parameter descriptions lack depth, output schemas are entirely undocumented, and error handling guidance is absent. Tools follow a predictable pattern but lack the LLM-optimized clarity and composition guidance expected of production-grade tools. The server bridges multiple blockchains but does not guide agents on when to use each tool or how to chain results.
Tools (5)
transactions_data_evmread onlyauth50/100
Lookup EVM transaction details, internal transactions, token transfers, and logs
transactions_data_kasparead onlyauth50/100
Lookup Kaspa transaction details
transactions_data_solanaread onlyauth50/100
Lookup Solana transaction details
transactions_data_utxoread onlyauth50/100
Lookup UTXO transaction details and raw transaction data
Output schemas completely undocumented. Tools call external APIs and return responses via client.request<unknown>(), but nowhere in the source code are the response structures documented. LLMs cannot plan downstream tool calls or extract required fields (transaction IDs, amounts, timestamps) without schema knowledge.
Tool descriptions are extremely minimal (1-2 sentences, ~50 chars). Baseline for A+ tools is 194 chars (p10=34, p90=392). Example: 'Lookup EVM transaction details, internal transactions, token transfers, and logs' does not explain WHEN to use this tool vs others, what data it returns, or dependencies. LLMs cannot reliably select the right blockchain tool without richer context.
Expand tool descriptions to 100-200 characters, explaining: (1) What blockchain(s) it targets, (2) What data it returns, (3) When to use it instead of sibling tools. Example: 'Retrieve detailed transaction information from EVM blockchains (Ethereum, Polygon, Avalanche). Returns transaction status, gas fees, token transfers, and internal calls. Use this for on-chain transaction analysis; for UTXO blockchains (Bitcoin, Litecoin), use transactions_data_utxo instead.'
Document every parameter with type, format, and valid values. Example for 'blockchain': 'The blockchain network identifier (string, required). Valid values: ethereum, polygon, avalanche, arbitrum, optimism. Examples: ethereum, polygon. Do not include 'chain' suffix.'
Add output schema documentation via comments or separate schema files showing what each action returns. Example: 'get-transaction-details returns {transactionHash, status, gasUsed, gasPrice, blockNumber, from, to, value, timestamp, functionName}. list-internal-transactions returns array of {transactionHash, from, to, value, gasUsed, type}.' Include field types and whether fields are always present.
Standardize 'transactionHash' vs 'transactionId' naming. Choose one convention and apply it across all tools. Recommend 'transactionHash' since it matches the API parameter name in EVM / UTXO specs.
Add pagination parameters (limit, offset or cursor) to tools that list multiple items (list-internal-transactions, list-token-transfers, list-logs). Document max limits and default behavior. Example: 'limit (integer, 1-100, default 20): Maximum items to return. offset (integer, default 0): Starting position.'
Spec posture evidence
Inferred effective spec: 2026-07-28+.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Parameter descriptions are missing or generic. 'blockchain' and 'network' appear in all schemas but lack guidance on valid values, format, or examples. 'context' is documented as 'Optional context identifier for request tracking', vague and unhelpful. Agents cannot validate inputs or understand constraints without explicit descriptions.
No error handling guidance. Tools catch errors and log them but provide no recovery instructions. If a transaction hash is invalid or a blockchain is unavailable, the LLM receives only a generic error message with no actionable next steps (e.g., 'retry', 'try a different blockchain', or 'use search_transactions first').
No pagination or result limits documented. EVM tools list internal transactions, token transfers, and logs, potentially large datasets. No parameters (limit, offset, page) visible in schemas. If APIs return hundreds of items, the response could exhaust the context window. Baseline pattern requires pagination support with documented limits.
Inconsistent parameter naming: transactions_data_kaspa uses 'transactionId' while all other tools use 'transactionHash'. This forces LLMs to remember different parameter names for semantically identical inputs across tools, increasing error likelihood.
No tool composition guidance. When should an agent call transactions_data_evm vs transactions_data_utxo vs transactions_data_solana? Descriptions do not explain blockchain differences, use cases, or decision logic. LLMs must infer intent from tool names alone.
Enum constraints present but not documented in descriptions. Schemas include enums for 'action' (e.g., 'get-transaction-details', 'list-internal-transactions'), but descriptions do not explain when each action is useful or what data it returns. LLMs may not explore all available actions.
Include error recovery guidance in tool or parameter descriptions. Example: 'If transaction not found, verify the transactionHash is correct and matches the target blockchain. Try with a different blockchain if unsure.'
Add action-level descriptions explaining when each enum value is useful. Example: 'action (string, required, enum): The operation to perform. get-transaction-details: Fetch basic tx info (status, gas, block). list-internal-transactions: Enumerate sub-calls within the tx (e.g., contract interactions). list-token-transfers: Extract ERC-20/721 token movements. list-logs: Get event logs (useful for detecting contract events).'
Consider adding a discovery tool or resource listing valid blockchain/network combinations. Agents currently have no way to discover that 'ethereum/mainnet' is valid without trial and error.
Document response field naming conventions in the output schema so agents know which fields to extract for chaining to other tools. Example: 'Response includes transactionHash (string): The transaction hash echoed back from input, useful for correlating requests.'
Add dry-run or confirmation support for any future state-modifying tools, ensuring agents can preview results before committing.