Server has 10 tools with complete input schemas and descriptions. Naming follows verb_noun pattern (bridge_*). Descriptions are present but generic (avg ~60 chars, below 194-char baseline). All parameters have type definitions and descriptions. Critical gap: no output schemas documented, LLMs cannot predict response structure for chaining. Error handling exists but lacks recovery guidance. Security concern: private_key exposed as parameter (should use server-side injection). Idempotency via client_operation_id is well-designed.

• Document output schemas for all tools. Example for bridge_eth: {tx_hash: string, operation_id: string, status: 'pending'|'confirmed', block_number: number}. This enables LLMs to chain tools and extract required IDs.
• Move private_key to server-side injection. Accept only client_operation_id and RPC endpoints as parameters. Load private key from environment or vault inside the handler. Prevents credential leakage into logs.
• Expand tool descriptions to 100-200 chars. Include: what it does, when to use it vs similar tools, what it returns, and any prerequisites. Example: 'Bridge ERC20 tokens from L1 to Taiko L2. Call bridge_check_ready first to verify readiness. Returns operation_id for status tracking via bridge_status.'
• Add error categorization to responses. Return {success: bool, error_category: 'retryable'|'user_fixable'|'fatal', error_message: string, recovery_hint: string}. Example: {success: false, error_category: 'retryable', error_message: 'RPC timeout', recovery_hint: 'Retry with longer timeout_seconds or different src_rpc endpoint'}.
• Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) to schema. Mark bridge_eth/bridge_claim as destructiveHint=true, bridge_check_ready/bridge_status as readOnlyHint=true, and all as idempotentHint=true (via client_operation_id).

Inferred effective spec: <=2025-11-25.

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