Two read-only analytical tools with clear, domain-specific descriptions (145 - 180 chars each, within baseline 194 avg). Input schemas present with Zod validation and parameter descriptions. However, output schemas are NOT documented, responses are inferred from code (JSON text blobs, no typed field definitions visible). Error handling returns text status strings ('RED', 'AMBER', 'GREEN') but lacks actionable recovery guidance. Tool names use verb_noun pattern (fx_corridor_pulse, fx_arb_radar) but are domain-specific rather than generic action verbs (get_, search_), which is acceptable for specialized tools. No parameter validation constraints (enums, ranges) visible in schema definitions. Composition is sound, each tool has one responsibility.

• Document output schemas explicitly. Define typed response objects with fields like {status: 'GREEN'|'AMBER'|'RED', rate: number, spread_bps: number, depth: number, reason?: string} for fx_corridor_pulse and {opportunities: [{a: string, b: string, c: string, edge_bps: number}], count: number} for fx_arb_radar.
• Add numeric constraints to Zod schemas: z.number().positive().max(1_000_000) for notional; z.number().min(0).max(500) for min_edge_bps; z.array(z.string()).min(3).max(20) for currencies.
• Enhance error responses with actionable guidance: 'Unknown token USDC. Available tokens: [list]. Call fx_corridor_pulse with a valid symbol.' instead of bare status strings.
• Replace domain-specific names with action verbs where possible: 'get_fx_corridor_health' or 'scan_fx_arbitrage' to improve LLM discoverability and intent inference.
• Add per-parameter examples in descriptions (e.g., 'currencies: ["USD", "SGD", "MYR"], minimum 3, maximum 20') to guide LLM input generation.