The Starknet MCP server defines 11 read-only tools with explicit input schemas and descriptions. All tools follow a clear verb_noun naming convention (get_*, list_*) appropriate for their actions. Descriptions are present and moderately detailed (avg ~120 chars), explaining what each tool does and when to use it. However, there are systematic gaps: (1) most parameter descriptions lack format constraints or range guidance (e.g., 'address' says '0x...' but doesn't validate format or explain what constitutes a valid Starknet address); (2) output schemas are not documented, callers must infer structure from code or trial; (3) error handling provides no recovery guidance, failures return raw error strings without actionable next steps; (4) no tool annotations (readOnlyHint, idempotentHint) are declared despite all tools being read-only and idempotent; (5) parameter naming occasionally conflates types (e.g., 'block_id' can be 'latest'|'pending'|number|hash, but this is only hinted in description, not enforced via schema). These gaps are typical for community servers (C-grade territory) but prevent production-grade LLM interaction. The good: schemas are properly typed JSON Schema, all 11 tools are registered explicitly, naming is clear and consistent.

• Add output schema documentation to each tool. In the index.ts tool registration or in a separate schema file, document the structure of responses. Example for get_balances: 'Returns {address: string, is_contract: boolean, nonce: number, balances: [{token: string, amount: string, token_address: string}]}'.
• Enhance parameter descriptions with format rules. Replace 'Starknet address (0x...)' with 'Starknet address (0x-prefixed hex string, 66 characters total including 0x prefix, e.g. 0x1234567890abcdef...)'. Add similar guidance for token_address, tx_hash, contract_address.
• Declare tool annotations in the TOOLS array. Add 'readOnlyHint: true' and 'idempotentHint: true' to each tool definition (if using MCP SDK v1.3+). This enables agents to cache and parallelize read-only calls.
• Improve error messages with recovery paths. Wrap errors with context: instead of 'Error: Contract not found', return 'Contract not found at this address. Verify the address with get_chain_info or try a different contract_address.'
• Add enum constraints for fixed-value parameters. In get_block inputSchema, change block_id to accept an enum or use oneOf to clarify that 'latest', 'pending', hex hashes, or numbers are valid.
• Document pagination and result limits in descriptions. If call_contract or get_transaction returns large results, add 'Results are limited to N items; use offset/limit for pagination' (if applicable).
• Add examples of valid parameter values to descriptions. Include a valid Starknet address example (anonymized) and tx_hash format in parameter descriptions so LLMs understand the expected format.