Two tools with minimal definition quality. getJourneys has an empty input schema ({}), violating the requirement that every parameter needs a description. addJourney has three parameters with descriptions, but they lack type constraints (enums, ranges, formats). Descriptions are generic and under 50 chars on average. No output schemas documented. Error handling returns raw error objects instead of actionable guidance. Tool names lack clarity on what 'journey' means in domain context.

• Add output schema documentation. Define what fields getJourneys returns (e.g. id, title, distance, date, createdAt) and what addJourney returns (e.g. id, status, createdAt). Use JSON Schema or explicit field descriptions.
• Expand tool descriptions to 100-200 characters. Explain domain context: 'Retrieve all journeys (trips/routes) from the journey tracking API. Returns list of journeys with ID, title, distance in km, and timestamp. Call this to list available journeys before filtering or updating.'
• Add format constraints to addJourney parameters. Change distance from bare string to 'Distance in kilometers (numeric, 0-99999, e.g. "150.5")'. Change date to 'ISO 8601 datetime (YYYY-MM-DDTHH:mm:ss, e.g. "2024-01-15T14:30:00")' and validate server-side.
• Implement structured error responses. Return {"error": "not_found", "message": "Journey API unreachable at http://localhost:3000/journeys. Ensure the API is running.", "retryable": true} instead of raw error strings.
• Add parameter descriptions that guide LLM input. For title: 'Human-readable journey name or route description (1-200 characters, e.g. "San Francisco to Los Angeles")'. For date: 'When the journey occurred or will occur (ISO 8601 format, required).'.