22 tools with consistent verb-noun naming (get_, search_, find_) and clear descriptions (avg ~80 chars). All tools are READ_ONLY, reducing risk. However, output schemas are not documented in the provided source, only input schemas are visible. Parameter descriptions are present but minimal (10-30 chars typical). No error handling guidance, no recovery patterns, and no tool annotations (readOnlyHint, etc.). Tools follow a predictable pattern but lack depth for production LLM optimization.

• Document output schemas for all 22 tools. Specify response structure, field names, types, and which fields are required. Example: 'Returns an object with fields: {agency_id: string, name: string, timezone: string, phone: string, url: string}'. This enables LLMs to plan downstream calls and extract data correctly.
• Add error handling guidance to tool descriptions. Example: 'If stop_id is invalid, returns error 404 with message "Stop not found. Try search_stops() with a partial name." Retryable: no.' This teaches LLMs when to retry, ask the user, or try an alternative tool.
• Expand parameter descriptions to 50-100 chars and include constraints. Example: 'radius: Search radius in meters (optional, default 500, range 100-5000). Larger radii may return hundreds of results; use pagination.' This prevents invalid inputs and guides agent reasoning.
• Add tool annotations (readOnlyHint: true) to all tools via mcp-go's tool registration API. This signals to agents that these tools are safe to call without confirmation and do not modify state.
• For tools accepting max_results or returning lists (search_stops, search_routes, get_stops_for_agency, get_trips_for_route, get_vehicles_for_agency), document default limits and pagination. Example: 'Returns up to 20 results by default. Use max_results to override (max 100). If more results exist, include a next_cursor field for pagination.'

Inferred effective spec: 2025-06-18+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry