BART MCP demonstrates solid fundamentals: all 4 tools have clear, action-oriented names (bart_departures, bart_stations, bart_trip_planner, bart_advisories) and substantive descriptions (150 - 250 chars each). Input schemas are present with typed properties and descriptions. However, output schemas are entirely undocumented, LLMs cannot predict response structure or plan downstream calls. Parameter descriptions are good but lack explicit constraints (e.g., no enum for station codes, no min/max for trip count). Error handling is absent from tool definitions. The _apiKey parameter pattern is reasonable but exposes API key as a parameter (though BART's is public). Overall: above-average naming and descriptions, but missing output documentation and error guidance that would push this to 80+.

• Document output schema for each tool. Example for bart_departures: 'Returns {station: string, departures: [{destination: string, minutes: number|'Leaving', platform: string, direction: string, cars: number, line: string, delay: boolean, bikes: boolean}]}'.
• Add min/max constraints to numeric parameters. Change 'trips' description to: 'How many upcoming trips to return (1 - 4, default 4)'. Add to schema: {"minimum": 1, "maximum": 4}.
• Formalize station parameter as enum or pattern. Document: 'Station code (4-letter BART code like EMBR, SFIA) or common name (Embarcadero, SFO, Downtown Berkeley). Aliases: SFO→SFIA, OAK→OAKL.'
• Add error recovery guidance to descriptions. E.g., bart_departures: 'If station not found, call bart_stations() to list valid codes or filter by city.'
• Remove _apiKey parameter or move to server config. If users must provide their own key, document it in the server README and inject via environment variable, not tool parameter.