SEPTA MCP has well-structured tool names (verb_noun pattern: septa_rail_arrivals, septa_next_to_arrive, septa_train_view, septa_bus_positions, septa_alerts) and clear, actionable descriptions (avg ~60 chars, all 10-100 range). Input schemas are present with type declarations and descriptions for all parameters. However, OUTPUT schemas are completely undocumented, no tool specifies what fields it returns, forcing LLMs to guess at response structure. Parameter descriptions are minimal (e.g., 'Regional Rail station name' lacks format/constraint details). No error handling guidance visible, tools throw errors but don't guide recovery. Fuzzy resolution logic is sophisticated but not exposed to the LLM via parameter constraints or enums. Missing: pagination info, result limits, field mappings for chaining tools.

• Document output schemas for all tools. Example for septa_rail_arrivals: 'Returns {trains: [{line: string, destination: string, departure_time: string, status: string}], station: string, timestamp: ISO8601}'. This enables LLMs to extract and chain data.
• Enhance parameter descriptions with format/constraint details. E.g., 'Regional Rail station name (e.g., Suburban Station, Ardmore, 30th Street). Accepts fuzzy input; resolved against canonical SEPTA station list. Case-insensitive.'
• Add error handling guidance to tool descriptions. E.g., 'If station not found, returns error with suggestions. Try search_stations() or provide exact canonical name.'
• Document result limits and pagination. E.g., 'septa_train_view returns up to 500 live trains. For large result sets, implement pagination or filtering by line/status.'
• Expose station/route enums or provide a discovery tool (e.g., list_stations, list_routes) so LLMs can discover valid inputs without external lookup.