CTA MCP defines 4 read-only transit tools with reasonable naming (verb_noun pattern: cta_train_arrivals, cta_bus_predictions) and moderate descriptions (80 - 180 chars). All tools have input schemas with typed parameters and descriptions. However, output schemas are completely undocumented, LLMs cannot predict what fields to expect from responses. Parameter descriptions lack format constraints (e.g., 'station' accepts name or mapid but doesn't specify the format or length). Error handling is absent, no guidance on what happens when a station is not found or the API times out. The embedded station table is a strength (disambiguates ambiguous names), but this complexity is not surfaced in tool descriptions.

• Document output schemas for all 4 tools. Specify field names, types, and nesting. Example: cta_train_arrivals returns [{arrT: string (ISO 8601), minutes_away: number, line: string, destination: string}].
• Add format constraints to parameter descriptions. For 'station': '5-digit mapid (e.g., 40830) or station name (e.g., Belmont, Clark/Lake)'. For 'lines': 'Array of line codes (Red, Blue, Brown, etc.) or comma-separated string'.
• Document error cases and recovery paths. E.g., 'If station not found, try search_stations() or use a 5-digit mapid. If API times out, retry after 2 seconds.'
• Explain station name disambiguation in cta_train_arrivals description: 'Station names may match multiple lines (e.g., Western). Use the optional line filter to disambiguate, or pass a 5-digit mapid for exact match.'
• Add limit/pagination guidance to all tools. Specify max results, default limit, and whether pagination is supported. E.g., 'Returns up to 50 results; use offset/limit for pagination (if supported)' or 'Returns all matching results; consider filtering by line to reduce volume.'