cosmos-mcp demonstrates solid definition quality with 36 well-named, read-only tools covering Cosmos blockchain queries. All tools have descriptions (avg ~80 chars) and input schemas with typed parameters. Naming follows verb_noun convention (get_*, search_*). However, parameter descriptions are minimal (often just type restating), output schemas are not documented, and error handling lacks recovery guidance. No pagination metadata (next_cursor, total) visible in responses. Tool composition is sound, each tool has one responsibility, but descriptions could be more LLM-optimized per the 50-200 char baseline.

• Document output schemas for all tools. Include field names, types, and pagination metadata (next_cursor, total count). Example: get_validators should document that it returns {validators: [{address, moniker, power, ...}], pagination: {next_key, total}}.
• Expand parameter descriptions to 50-150 characters. Explain WHEN to use optional parameters and what the default behavior is. E.g., 'height: optional past block height (decimal string); omit to query current state. Useful for historical analysis or when the node has pruned recent blocks.'
• Document pagination object structure explicitly. Add a shared definition or example: 'pagination: {limit: number (1-100, default 20), offset: number (0+), key: string (continuation token from previous response)}'.
• Add input validation and error recovery guidance to rpc_query, lcd_query, grpc_query. Document which methods are allowlisted, what 404/501 errors mean, and suggest fallback endpoints or alternative methods.
• Add tool annotations (readOnlyHint: true) to all tools in the MCP server registration to signal to clients that these are safe to cache and retry without side effects.

Inferred effective spec: 2025-06-18+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry