Server has 6 well-named tools with complete input schemas and descriptions. Naming follows verb_noun pattern (flag_eval, flag_list, flag_create, etc.). All tools have descriptions 50-150 chars, meeting the 10-1024 char baseline. Input schemas are properly typed with required fields and descriptions. However, output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal (no recovery guidance, no actionable error messages). Parameters lack constraints (e.g., flag_key has no length/format limits, targeting_rules references README instead of inline schema). No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Missing parameter descriptions for 'default_value' in flag_create/flag_update (type is inferred but not stated). Overall solid naming and basic schema coverage, but incomplete output documentation and weak error guidance.

• Add explicit output schema documentation for each tool. Example: flag_eval returns {ok: boolean, value: any, matched_rule: string|null, evaluation_id: string}. Include this in tool description or as a separate outputSchema field.
• Inline targeting_rules schema in inputSchema with examples. Replace 'See README for shape' with: 'Array of rule objects: [{did_pattern?: string, percentage?: 0-100, value: any}]. Rules evaluated in order; first match wins.'
• Add tool annotations to inputSchema: readOnlyHint for flag_list/flag_describe/flag_eval (read-only), destructiveHint for flag_delete, idempotentHint for flag_describe.
• Enhance error messages with recovery guidance. E.g., 'flag_key_already_exists: Use flag_describe to inspect the existing flag, or choose a different flag_key.' and 'payment_invalid: Verify tx_hash is a valid Base USDC transfer to 0x15184bf50b3d3f52b60434f8942b7d52f2eb436e for the required amount.'
• Document parameter constraints in descriptions. Add to flag_key: '2-64 alphanumeric + underscore'. Add to default_value: 'Type must match the flag type enum (boolean, string, number, or valid JSON for json type).'