Single-tool server with a clear, well-documented tool definition. The get_new_pools tool has a descriptive docstring and properly typed input schema with enums. However, the output is returned as plain text (string) rather than structured JSON, which limits the LLM's ability to parse and compose results downstream. Error handling is basic, the tool catches exceptions and returns error strings rather than providing structured error guidance. The schema is present and complete, but the return type being a formatted string instead of structured objects is a significant limitation for agent reasoning and chaining.

• Return a structured list of objects instead of a formatted string. Each pool should be a JSON object with fields: pool_address, token0_symbol, token1_symbol, created_at_timestamp, block_number, tx_count, volume_usd, tvl_usd. This enables agents to filter, sort, and chain results.
• Add structured error responses with error codes and recovery hints. For example: {"error": "invalid_chain", "message": "Chain 'eth' not recognized", "valid_chains": ["ethereum", "base", "optimism", ...]}
• Implement pagination by returning {"pools": [...], "total_count": N, "next_cursor": "..."}. Allow agents to request subsequent pages without re-querying with a different limit.
• Add optional filters for minimum TVL, volume, or transaction count. Agents often need to narrow results by business metrics, and doing this server-side is more efficient than post-processing large lists.
• Document the returned pool object structure explicitly in the tool description or as a JSON Schema output property. Include field descriptions and formats (e.g. volume_usd as float with 2 decimal places, timestamp as ISO 8601).
• Consider adding a get_pool_details(pool_address: str) tool to retrieve deeper liquidity, swap history, and fee tier information for a specific pool after discovery with get_new_pools.