This is an example repository demonstrating Koko Finance API usage, not a production MCP server. Tool definitions are present with schemas and descriptions, but lack depth. All 7 tools have basic descriptions (avg ~80 chars) and input schemas with type definitions. However, descriptions are generic and lack LLM-optimization guidance (e.g., 'when to use', 'prerequisites', 'what it returns'). No output schemas documented. Error handling is absent, no guidance on retryability, user-fixable errors, or recovery paths. Parameter descriptions are minimal; several lack context (e.g., 'benefit_selections' array items are strings but no enum or format guidance). No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Naming is verb-forward (compare_, recommend_, check_, analyze_, which_, merchant_, get_) but some are vague ('which_card_at_merchant' vs 'recommend_card_at_merchant'). This reads as a reference implementation, not a hardened production tool.

• Add output schemas to all tools. Document return types, field names, and structure. Example: 'Returns {cards: [{name, annual_fee, rewards_rate, benefits}], comparison_summary: string}'.
• Expand descriptions to 150 - 250 chars. Include: what the tool does, when to call it (vs similar tools), and what it returns. Example: 'Compare 2 - 3 credit cards side-by-side. Use this to help users choose between options. Returns rewards rates, annual fees, and key benefits for each card.'
• Add enum constraints to 'benefit_selections' and 'category' parameters. Call get_benefit_categories first to discover valid values, or hardcode the enum in the schema.
• Document error cases and recovery guidance. Example: 'If card not found, try search_cards() with a partial name. If benefit_selections is invalid, call get_benefit_categories() to see valid keys.'
• Add tool annotations to schema. Mark all tools with 'readOnlyHint: true' since they do not modify state. This signals to agents that these calls are safe to retry.