Orchestrate MCP servers with Code Mode - let LLMs write TypeScript code for complex workflows. Supports multi-server coordination, secure VM sandboxing, and 60-75% token savings.
Static source inference · medium confidence · detected: Sampling
Deprecated protocol patterns detected
Summary
This server presents 19 tools across a travel-planning orchestrator. While schemas are present for all tools with proper JSON Schema structure, the quality is uneven. Tool naming follows verb_noun convention (getCalendarAvailability, searchFlights, createItinerary), which is good. However, descriptions are minimal, most are 15-40 characters, falling well below the 50-200 char baseline for LLM-optimized descriptions. Several tools lack critical context about when to use them vs similar tools (e.g., analyzeFlights vs searchFlights is never explained). Parameters have types and basic descriptions, but many lack constraints, valid value guidance, or format specifications. Error handling is not visible in the schemas. Output schemas are not documented. The mock server tests (list_directory, read_file, write_file) are simplistic stub implementations.
Tools (19)
analyzeFlightsread onlyauthsource verified60/100
Analyze flight options using LLM to find the best value
bookHotelwritesource verified63/100
Find and book hotels within budget
checkWeatherread onlysource verified63/100
Get weather forecast for a destination and date range
Tool descriptions are critically short (median 33 chars vs 194 char baseline). Examples: 'Check calendar availability for date range' (39 chars), 'Send an email message' (21 chars), 'Get weather forecast for a destination and date range' (53 chars). Descriptions under 50 chars lack context for LLM selection and omit when/why guidance.
No output schemas documented. Tools return complex nested objects (flights array, hotels array, activities in createItinerary; multiple calendar events in getCalendarAvailability). Without documented return schemas, LLMs cannot plan what fields to extract or chain downstream calls. Example: createItinerary returns an itinerary but no schema shows what fields are present (id? status? booking_reference?).
Expand all tool descriptions to 50 - 150 characters, following the LLM-optimized baseline (194 char median). Example for sendEmail: 'Send an email message. Use to notify recipients about bookings, confirmations, or itinerary updates. Returns success status and message ID. Requires active email account.' (instead of 'Send an email message').
Document output schemas for all tools, especially complex ones like createItinerary. Define what fields are returned, their types, and which are guaranteed vs optional. Example: 'Returns { id: string, status: "draft"|"confirmed"|"completed", flights: FlightBooking[], hotels: HotelBooking[], createdAt: ISO8601 string }'.
Add format and constraint fields to JSON Schema for date parameters: use 'format: "date-time"' for ISO dates, add minLength/maxLength for strings, add minimum/maximum for numeric ranges (e.g., travelers: { type: number, minimum: 1, maximum: 99 }).
Convert free-form string parameters to enums. Replace 'criteria' in analyzeFlights with an enum: criteria: { type: string, enum: ["cheapest", "fastest", "best_value", "eco_friendly"] }. Add description: 'Optimization criteria for flight selection. cheapest = lowest total fare. fastest = shortest flight time. best_value = rating/fare ratio. eco_friendly = lowest emissions.'
Clarify overlapping tool pairs with explicit distinction statements. Example for searchFlights vs analyzeFlights: 'searchFlights: Query available flights by date/route. Use this to discover options. analyzeFlights: Use LLM to compare flights by user criteria (value, speed, eco impact). Call this AFTER searchFlights to narrow choices.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Sampling (deprecated) - integrate directly with the LLM provider API
Parameter constraints missing or underspecified. Examples: 'startDate' and 'endDate' in getCalendarAvailability have no format declared ('ISO format' is in description, not schema format field); 'travelers' in searchFlights is number with no min/max bounds; 'budget' in bookHotel has no range or currency specified; 'reminderDays' in scheduleTripReminders is array with no item type or range declared.
No enum constraints for categorical fields. 'criteria' parameter in analyzeFlights is free-form string ('cheapest, fastest, best value' mentioned in description only). Without enum, LLM may hallucinate values like 'luxury', 'eco-friendly', or 'by-date'. Same for 'status' fields, priority levels, and calendar types.
Ambiguous tool names and lack of distinction. 'searchFlights' and 'analyzeFlights' both deal with flights; descriptions do not explain when to use each (one queries availability, other uses LLM for analysis, but this is not stated). 'getCalendarAvailability' vs 'getAvailableCalendars' naming is confusingly similar, first checks time slots, second lists calendars.
Complex tool `createItinerary` combines multiple concerns: accepts flights array, hotels array, and activities array as inputs, then creates a single itinerary. No schema shows what fields are expected in each array element, no error handling for malformed input, no guidance on what happens if booking details are incomplete.
No error handling or recovery guidance. Tools lack descriptions of failure modes (e.g., what if calendar is read-only? what if flight dates are in the past? what if hotel booking fails?). No guidance on retryability, user-fixable errors, or escalation paths.
Mock tools (list_directory, read_file, write_file) have trivial descriptions ('List directory contents', 'Read file', 'Write file'), under 20 chars, failing baseline. These appear to be stub implementations for testing, not production tools. If they are meant to be part of the public API, they need proper documentation.
No composition guidance between tools. 'getTravelPreferences' and 'getPastTrips' both provide context, but there is no explicit statement of which should be called first, or how their outputs feed into booking decisions. 'searchFlights' → 'analyzeFlights' → 'bookHotel' flow is implicit, not documented.
Natural identifiers missing. 'sendEmail' requires 'emailAccount' parameter (ID-based). LLMs likely have user's email address ('user@gmail.com') but not the internal ID ('email://gmail/personal'). Forcing opaque IDs means a discovery call to getAvailableEmailAccounts is needed first, wasting a round-trip.
sendEmailgetAvailableEmailAccounts
Split createItinerary into smaller, composable tools: confirmFlights(flightIds[]), confirmHotels(hotelIds[]), addActivities(itineraryId, activities[]). This allows agents to interleave decision-making instead of building a complete package upfront.
Add error-handling guidance to write/state-change tools (createCalendarEvent, sendEmail, bookHotel, createItinerary, scheduleTripReminders). Example for bookHotel: 'Returns { success: true, bookingId: string } on success. On failure, returns { success: false, error: string, retryable: boolean, suggestion?: string }. Common errors: budget_exceeded (increase budget or lower star rating), date_unavailable (try adjacent dates), location_not_found (use search_locations first).'
Replace opaque IDs with human-friendly names where possible. For sendEmail, accept either emailAccount (ID) OR senderEmail (email address) as an alternative. Internally, resolve the email address to the account ID. This matches how users think ('send from my Gmail' not 'send from email://gmail/personal').
Add composition links in descriptions. Example for searchFlights: 'Returns array of flights with id, price, duration, emissions. Pass flight IDs to analyzeFlights(criteria) to rank by user preferences, then bookFlight(flightId) to reserve.'
Document pagination limits for list tools. Even though mock data is small, state: 'getAvailableCalendars returns all available calendars (typically 3-10). If count exceeds 50, implement pagination with limit and offset parameters.'
Remove or properly specify mock/test tools (list_directory, read_file, write_file). If these are for testing only, move them out of the main tool export. If they are part of the public API, expand descriptions: 'read_file: Read and return contents of a file at the given path. Returns { path, content: string, size_bytes: number }. Supports .txt, .json, .csv, .md. Max file size: 10 MB. Access limited to /data directory.'
Add tool annotations (readOnlyHint, destructiveHint) to the schema for each tool. Example: sendEmail should have destructiveHint: true (cannot be undone; confirmation recommended). getCalendarAvailability should have readOnlyHint: true (no side effects).