Single tool 'get-next-bus' has critical definition gaps. Tool description contains a typo ('but stop' instead of 'bus stop') and is only 37 characters, below the 50-char minimum for LLM clarity. Input schema is present with proper Zod typing (stopId: string), but the parameter description is generic ('The ID of the bus stop') and lacks format guidance (what constitutes a valid stop ID?). No output schema is documented, LLMs cannot predict the response structure. Error handling returns plain text without actionable recovery guidance. The tool name 'get-next-bus' is acceptable (verb_noun pattern), but lacks specificity about what 'next' means (next departure? next arrival?). No pagination, no result limits documented, no field descriptions for the formatted response.

• Expand tool description to 80-150 chars: 'Retrieve the next 3 departing buses from a FOLI transit stop. Provide the numeric stop ID (e.g., 1234). Returns line number, destination, and departure time. Call this to help users plan transit routes.'
• Document output schema explicitly: { buses: [{ lineRef: string, destination: string, departureTime: string (ISO 8601), isVehicleAtStop: boolean }], stopId: string, fetchedAt: string }
• Add stopId parameter constraints: 'The numeric FOLI stop ID (1-5 digits, e.g., 1234). Find stop IDs at foli.fi or via the transit app.'
• Implement structured error responses: { error: 'stop_not_found', message: 'Stop 9999 not found.', suggestion: 'Verify the stop ID at foli.fi or search for nearby stops.' } instead of plain text.
• Document result limit in description: 'Returns up to 3 next departures. For more results, call the tool again after the first bus departs.' Add optional limit parameter (1-10) to schema.