This server is a travel-agent MCP that helps agents and travelers plan trips, compare airports and routes, get timing and currency context, and run paid x402 services for day trips, weekends, creator experiences, weather-aware planning, transit options, and penny-priced Travel Pulse disruption checks.
Free discovery & utilities: list travel categories, get airport details, compare airport routes, plan flight routes, create booking links, get timing advice, convert currency, and request local coverage.
Paid x402 planning services: plan day trips, weekend getaways, weather-aware trips, find transit options, and get creator experience itineraries.
Travel Pulse: run a $0.01 per-call disruption and emergency-awareness check before or during a trip for weather alerts, natural events, water/flood context, and destination disruptions.
Agent-friendly workflow: start with free calls to orient, then call paid services only when richer trip-shaped guidance or live awareness is needed.
Flexible input: tools accept destinations, coordinates, dates, budgets, mobility preferences, interests, and route pairs, with live server output or x402 request metadata for clients that can pay.
Supports Hermes as an MCP client, enabling travel agent capabilities such as category discovery, day trip planning, and travel pulse disruption checks.
Canonical travel-agent MCP server for Glama, Claude Desktop, Codex-style agent workflows, Hermes, and other MCP clients.
It helps answer the travel questions people keep coming back to: where should I go, which airport makes sense, when should I book, what is worth doing nearby, and what should I check before or during the trip?
Agents can start with free travel tools, then call live x402 services when the traveler needs deeper planning or a trip disruption check that is cheap enough to run whenever awareness matters.
Start free: category discovery, airport checks, timing advice, currency conversion, and local coverage requests.
Then add paid travel intelligence when it matters: penny-priced Travel Pulse disruption checks, day-trip and weekend planning, creator experiences, transit options, weather-aware planning, flight-route comparisons, and external booking links.
Free calls make the first useful answer easy: discover categories, check airports, estimate currency, explain timing, or request new local coverage.
Travel Pulse is the high-importance, low-cost paid call: $0.01 for one disruption and emergency-awareness check. The user or their agent can run it before departure, then run another check during the trip whenever they want updated awareness.
Paid planning services return trip-shaped guidance agents can use immediately: day trips, weekends, creator stories, weather-aware planning, and mobility options.
x402 is live on the hosted backend: fixed-price USDC on Base, Bazaar discovery metadata, retry-safe payment identifiers, signed offer/receipt support, and builder-code attribution.
The MCP does not hold payment keys. It returns live request URLs and x402 metadata for clients that can pay with x402.
Related MCP server: autonomad-travel
Pull the FREE live category guide from the ForgeMesh travel-agent backend
Give agents useful free starting points: airport checks, timing context, currency conversion, and coverage requests
Connect x402-capable clients to creator experience planning for shareable day trips, weekends, layovers, and destination stories
Connect x402-capable clients to Travel Pulse for a $0.01 check before a trip, with optional follow-up checks during the trip when the user or agent asks
Connect x402-capable clients to day-trip, weekend getaway, weather-aware, and mobility-option planning services
Give insurers, travel apps, assistance providers, and concierge agents a simple way to add penny-priced trip awareness without building a full travel-risk desk
Submit free coverage requests for local rituals, sunset spots, water walks, free experiences, and places worth watching
Look up airport metadata by IATA code
Compare alternate origin and destination airport routes
Explain booking windows, airport arrival timing, layovers, and seasonal travel factors
Build external booking links for selected routes
Keep public responses generic and traveler-ready, with no exposed internals
Run locally with no account setup
Disclose commission-eligible links in tool output
Use this MCP when an agent needs a travel conversation that can keep going:
Start with list_travel_categories to see what is available.
Use convert_currency, get_airport_details, and get_travel_timing_advice as free utility calls.
Use request_local_coverage when a town, ritual, route, or creator angle should be watched or added.
Use check_trip_disruptions before departure, then have the user or their agent call it again during the trip if they want hourly or event-driven updates.
Use paid planning tools when the traveler needs a richer answer than a web search can comfortably assemble.
Travel Pulse gives an app, policy workflow, concierge desk, or agentic travel assistant a penny-priced check for the question that matters before and during a trip: should this traveler know something right now?
It is not a staffed rescue operation, emergency dispatch, insurance product, or replacement for official instructions. Results can be incomplete, delayed, or wrong. Travelers and agents should verify important safety decisions with official government, weather, transportation, venue, and emergency sources. In an emergency, contact local emergency services immediately.
It is a practical awareness layer that an AI or client app can call before departure and during the trip to look for disruption, emergency, weather, water, route, or destination concerns.
That makes it easy to package as a feature: "we check your trip before you leave, and your assistant can check again while you travel." The partner controls when to call it, how often to call it, and what to do with the result.
This is built for practical travel awareness, not booking hype:
Check whether a trip has weather or disruption concerns.
Compare airports and route options before committing.
Shape a day trip or weekend around movement, timing, food, weather, and backup ideas.
Build creator-friendly trip arcs around visuals, pacing, and moments worth saving.
Ask for local coverage when a place deserves better future answers.
This repo is tuned for public discovery and agent selection:
Canonical package name: @forgemeshlabs/travel-agent-mcp
Canonical server name: travel-agent
Canonical backend: https://travel-agent.forgemesh.io
Primary use cases: Travel Pulse disruption checks, day trips, weekend getaways, weather-aware planning, transit options, creator experiences, coverage requests, timing advice, and free currency conversion
Highlight service: Travel Pulse, a $0.01 disruption and emergency-awareness check agents can run before departure, then call again during the trip when the user wants another check
Glama build metadata lives in glama.json and GLAMA.md
Search-facing documentation should stay crawlable, concise, and consistent with the package description and keywords
npm install -g @forgemeshlabs/travel-agent-mcpAdd this to your Claude Desktop claude_desktop_config.json:
{
"mcpServers": {
"travel-agent": {
"command": "npx",
"args": ["-y", "@forgemeshlabs/travel-agent-mcp"]
}
}
}Restart Claude Desktop after saving the config, then ask Claude to plan or compare travel routes.
Codex, Hermes, and other MCP-capable agent runtimes can use the same server command:
npx -y @forgemeshlabs/travel-agent-mcpnpm run build
node dist/index.jsThe MCP works as a local planning tool and connects to the ForgeMesh travel-agent backend for free discovery, free coverage requests, and paid x402 planning services.
TRAVEL_AGENT_SERVER_URL=https://travel-agent.forgemesh.io npx -y @forgemeshlabs/travel-agent-mcpIf the backend is unavailable, local airport, route, timing, and booking-link tools still work. Backend-powered tools return the request URL and x402 metadata so clients that can pay with x402 can retry directly.
For the companion docs or site that renders this package:
Keep the package title, description, and backend URL consistent everywhere.
Publish a robots.txt that allows public documentation to be crawled and points at the sitemap.
Provide a sitemap for the public docs site and keep canonical URLs stable.
Avoid noindex on the public README, docs landing page, or endpoint summary pages.
If the site sits behind Cloudflare, make sure bot rules and content-signal settings do not block search crawlers from the public docs.
Keep pages fast, readable on mobile, and focused on plain-language summaries of what the tools do.
See docs/discovery.md for the maintainer-facing checklist.
list_travel_categories
plan_flight_route
get_airport_details
compare_airport_routes
create_booking_link
get_travel_timing_advice
creator_experiences
plan_day_trip
plan_weekend_getaway
plan_weather_aware_trip
find_transit_options
check_trip_disruptions
convert_currency
request_local_coverage
Use list_travel_categories first when an agent wants the lay of the land. It is the free map of what the backend can do next:
Day trips
Weekend getaways
Weather-aware planning
Transit and mobility options
Request coverage
Creator experiences
Timing and weather
Currency exchange
Travel Pulse
The category guide is free, fast, and useful when an agent needs the next travel step: ask a better follow-up, request new coverage, or hand the traveler to a paid x402 service when the moment is worth it.
These calls make the package easy to try and useful enough to keep installed:
list_travel_categories for discovery
get_airport_details for quick validation
get_travel_timing_advice for timing context
convert_currency for free reference-rate spending context
request_local_coverage for adding towns, rituals, source sets, and creator angles
The free calls let agents validate a place, price a rough spend, collect intent, and come back later with richer day-trip, weekend, creator, weather, mobility, and disruption guidance.
check_trip_disruptions is the simple paid check for an important travel question: what should this traveler know before they go, or before they make the next move?
Each call is one on-demand check. Use it before departure, then have the user or their agent call it again during the trip if they want hourly, daily, or event-driven updates. An agent can check for weather alerts, natural events, water or flood context, and destination disruptions, then decide whether to reassure the traveler, suggest a calm backup, or check again later.
At $0.01 per call, it is cheap enough for the moments where travel-risk awareness used to feel too expensive to automate: before departure, after a storm shifts, when a route changes, or while a traveler is already moving.
It is not emergency services and it does not replace official instructions. Results can be incomplete, delayed, or wrong. Verify important safety decisions with official government, weather, transportation, venue, and emergency sources. In an emergency, contact local emergency services immediately.
Its job is practical perception of safety: keep the agent aware enough to notice when something may deserve a second look.
Travel Pulse and the other travel tools provide informational travel awareness and planning support only. They do not provide emergency response, evacuation, rescue, medical advice, legal advice, insurance coverage, or official government guidance.
Outputs may be incomplete, delayed, inaccurate, or unavailable. Travelers, agents, partners, and apps should verify safety-critical decisions with official sources, local authorities, carriers, venues, and emergency services. In an emergency, call the appropriate local emergency number immediately.
The MCP sends paid planning requests to the live ForgeMesh x402 server:
plan_day_trip -> GET https://travel-agent.forgemesh.io/api/day-trip-plan
plan_weekend_getaway -> GET https://travel-agent.forgemesh.io/api/weekend-getaway
creator_experiences -> GET https://travel-agent.forgemesh.io/api/creator-experiences
check_trip_disruptions -> GET https://travel-agent.forgemesh.io/api/travel-pulse
plan_weather_aware_trip -> GET https://travel-agent.forgemesh.io/api/weather-aware-plan
find_transit_options -> GET https://travel-agent.forgemesh.io/api/transit-providers
The paid services are where the answer gets richer: trip-shaped briefs, weather and movement awareness, creator-ready story arcs, practical tradeoffs, and useful next checks.
The hosted backend advertises its protocol details at https://travel-agent.forgemesh.io/.well-known/x402.json and /openapi.json.
Current live implementation highlights:
Fixed-price exact payments in USDC on Base
Bazaar discovery metadata for live paid routes
Optional payment-identifier support for retry-safe client requests
Signed offer/receipt support after settlement, verified with a live paid call
Builder-code attribution enabled on the live server
This package uses generic language for provider integrations. Tool responses may include external booking links and commission-eligible links. Booking completion happens with booking partners outside this MCP server. Paid planning is provided by the public ForgeMesh x402 travel-agent backend.
Check for travel disruptions before departure or during a trip with the live paid x402 Travel Pulse service. Each $0.01 call is one on-demand disruption and emergency-awareness check: an agent can run it before the traveler leaves, then call it again during the trip if the user wants hourly, daily, or event-driven updates. Use for weather alerts, natural events, water/flood context, route or destination disruption awareness, travel-risk awareness, and calm backup considerations. Informational only: results can be incomplete, delayed, or incorrect. Not emergency services, not staffed monitoring, and not a substitute for official instructions or local emergency authorities.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude for a point-specific pulse check. | |
| lon | No | Longitude for a point-specific pulse check. | |
| origin | No | Optional origin or route start. | |
| trip_date | No | Trip date in YYYY-MM-DD format, if known. | |
| water_site | No | Optional water gauge/site id when the traveler cares about flood or river context. | |
| destination | No | Destination, city, region, route, airport area, or place to check. | |
| time_window | No | Relevant window, such as before departure, next 3 hours, today, overnight, or during trip. | |
| check_reason | No | Why the agent is checking, such as pre_trip, repeat_trip_check, weather_shift, event_day, or traveler_check_in. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true (safe read), idempotentHint=true (same result), destructiveHint=false. Description adds important behavioral context: results may be incomplete/delayed/incorrect, informational only, and not emergency services. This exceeds minimal annotation value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and usage, then adds limitations. It is relatively long but each sentence adds value (use cases, limitations, payment detail). Minor redundancy (e.g., 'Informational only' appears twice in spirit) but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain return values or structure. It covers usage, limitations, and purpose well but lacks output format details. For a tool with 8 parameters and no required fields, more guidance on what the agent receives would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 8 parameters. The description provides overall context for the parameters (destination, origin, lat, lon, etc.) but does not add specific meaning beyond what the schema already explains. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks for travel disruptions using a paid service, with specific verb 'Check' and resource 'travel disruptions' (result of x402 Travel Pulse). It distinguishes itself from sibling planning tools like plan_day_trip or find_transit_options by focusing on disruption awareness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: before departure or during a trip, with recurring updates on demand. Lists use cases (weather alerts, natural events, water/flood context) and exclusions (not emergency services, not substitute for official instructions). Provides clear alternative contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two or more airport route pairs side by side. Use when a traveler is choosing between alternate origins, destinations, or nearby airports; use plan_flight_route for one dated route and get_airport_details for a single airport lookup. Read-only, no account setup, no booking side effects. Responses may include commission-eligible external booking links for each route.
| Name | Required | Description | Default |
|---|---|---|---|
| routes | Yes | Array of route pairs to compare. Minimum 1, typically 2-5. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds context such as 'Read-only, no account setup, no booking side effects' and notes that responses may include commission-eligible external booking links, which aligns with and supplements the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four concise sentences, front-loaded with the main purpose. Each sentence adds unique value: purpose, usage context, behavioral traits, and booking link disclosure. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 param, no output schema, rich annotations), the description covers purpose, usage guidelines, and behavioral traits. It mentions booking links but could be more explicit about the comparison output format (e.g., what data is compared). However, with openWorldHint=true, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the single 'routes' parameter fully described (array of objects with origin/destination). The description adds no extra detail beyond the schema, merely restating 'two or more airport route pairs.' Baseline 3 is appropriate since parameter semantics are fully covered by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Compare two or more airport route pairs side by side,' clearly defining the verb (compare) and resource (airport route pairs). It also distinguishes from sibling tools by naming plan_flight_route for single dated routes and get_airport_details for single airport lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use ('when a traveler is choosing between alternate origins, destinations, or nearby airports') and when not to (by naming alternative tools). It also clarifies that it is read-only with no account setup or booking side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE live reference-rate currency conversion from the ForgeMesh travel-agent backend. Use when a traveler or agent needs quick spending context before deciding whether to ask for richer x402 trip guidance. Read-only, no account setup, no payment, and not a transaction quote.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Target ISO 4217 currency code, such as EUR. | |
| date | No | Optional reference date in YYYY-MM-DD format when supported by the backend. | |
| from | Yes | Source ISO 4217 currency code, such as USD. | |
| amount | No | Amount to convert. Default: 1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds that it is free, no account setup, no payment, and not a transaction quote, enriching transparency without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key purpose and usage context, no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given rich annotations and fully described parameters, the description provides all necessary context: it is a free, read-only reference conversion, not a quote. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description does not need to add parameter details. It adds minimal semantic value beyond stating 'live reference-rate' but does not elaborate on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs currency conversion using live reference rates from ForgeMesh. Among siblings, no other tool does currency conversion, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (quick spending context before richer guidance) and what not to use for (not a transaction quote), providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an external booking link for an already chosen route. Use after route details are known or after compare_airport_routes or plan_flight_route; use another planning tool first when the traveler still needs help choosing. Read-only, no account setup, no booking completion, and no reservation side effects. The returned link may be commission-eligible and is disclosed in output.
| Name | Required | Description | Default |
|---|---|---|---|
| origin | No | Origin IATA code (e.g. 'IAH'). Case-insensitive. | |
| currency | No | ISO 4217 currency code (default: USD). | |
| destination | No | Destination IATA code (e.g. 'CDG'). Case-insensitive. | |
| return_date | No | Return date in YYYY-MM-DD format. Optional — omit for one-way. | |
| departure_date | No | Departure date in YYYY-MM-DD format. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true, destructiveHint=false, but description adds 'Read-only, no account setup, no booking completion, and no reservation side effects' plus 'link may be commission-eligible and is disclosed in output' – valuable context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states core purpose, second provides usage guidelines and behavioral caveats. No redundant information, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers purpose, usage, behavioral traits, and hints at output (commission-eligible link). No output schema exists, but the description provides relevant output context. Slight gap: does not specify if link is returned as a URL string or object, but sufficient for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% – all parameters have descriptions. Description does not add additional meaning beyond what's already in the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create an external booking link for an already chosen route' – specific verb+resource. Distinguishes from sibling planning tools by emphasizing the route must already be selected.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('after route details are known or after compare_airport_routes or plan_flight_route') and when-not-to-use ('use another planning tool first when traveler still needs help choosing'). Also clarifies no booking completion, no reservation side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to the live paid x402 creator-experience service for travelers, creators, influencers, and agents planning a shareable day trip, weekend, layover, or destination story. Use when the traveler cares about visuals, story, timing, food stops, scenic movement, weather-aware backups, or content moments. The MCP can return live server output or x402 request metadata for clients that can pay with x402.
| Name | Required | Description | Default |
|---|---|---|---|
| avoid | No | Optional list of things to avoid. | |
| budget | No | Budget preference, such as free, low-cost, mid-range, luxury, or a specific amount. | |
| season | No | Season, month, weather context, or event timing. | |
| audience | No | Who the content should speak to, such as couples, solo travelers, families, students, food lovers, or weekend explorers. | |
| mobility | No | Mobility or pace preference, such as easy walking, stroller-friendly, low stairs, car-free, or relaxed. | |
| destination | Yes | Destination, city, region, route, or place the influencer experience should be built around. | |
| trip_length | No | Trip length, such as day trip, 24 hours, weekend, layover, or 3 days. Default: day trip. | |
| must_include | No | Optional list of moments or constraints to include. | |
| content_style | No | Desired style, such as cinematic, cozy, budget, food-focused, outdoorsy, romantic, luxury, hidden-gem, or short-form video. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only (readOnlyHint=true) and idempotent. The description adds key behavioral context: it's a paid service (x402), returns live server output or x402 metadata, and requires client payment capability. This goes beyond annotations but could detail output format more.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three sentences, front-loading the main purpose and then usage context. No unnecessary words, but could be slightly more concise by combining 'Connect to...' and 'Use when...' into a single sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description only vaguely mentions 'live server output or x402 request metadata' without explaining the response structure or content. For a complex planning tool with 9 parameters, this is insufficient for an agent to fully understand the return value semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions. The tool description does not add additional parameter-level details beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it connects to a live paid x402 creator-experience service for travel planning focused on visuals and story. It distinguishes from sibling tools by specifying the target audience (creators, influencers) and the paid nature, which no other sibling tool mentions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use when the traveler cares about visuals, story, timing, food stops, scenic movement, weather-aware backups, or content moments', providing clear context. However, it does not explicitly list when not to use or suggest alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to the live paid x402 mobility-options service for a location and transportation type. Use when the traveler wants transit, rail, ferry, trails, bike/scooter options, or a location-filtered short list before planning the rest of the trip.
| Name | Required | Description | Default |
|---|---|---|---|
| origin | No | ||
| location | No | ||
| trip_style | No | ||
| destination | No | ||
| transportation_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, covering safety and idempotency. The description adds value by mentioning the tool connects to a 'live paid' service, implying external dependency and cost. However, it does not elaborate on rate limits, authentication, or return behavior, which would be beneficial beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, no fluff. The first sentence states the action, the second provides usage guidance. It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 optional parameters with zero schema descriptions and no output schema, the description lacks completeness. It does not explain parameters beyond location/transport type, nor describes what the tool returns. The openWorldHint suggests unknown output structure, but the description offers no further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% description coverage. The description only hints at 'location' and 'transportation_type' as key parameters, ignoring 'trip_style', 'origin', and 'destination'. With nearly no schema descriptions, the description fails to compensate, leaving agent uncertain about parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'connect' and identifies the resource as a 'live paid x402 mobility-options service'. It clearly states when to use it: for transit, rail, ferry, trails, bike/scooter options, or a location-filtered short list. While it doesn't explicitly differentiate from sibling tools, the purpose is distinct and clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: 'Use when the traveler wants transit, rail, ferry, trails, bike/scooter options, or a location-filtered short list before planning the rest of the trip.' It does not state when not to use or mention alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE look up details for one airport by IATA code. Use to validate or explain a single airport before route planning; use plan_flight_route for an actual trip route and compare_airport_routes for multiple origin-destination pairs. Read-only, no account setup, no external booking links, and no booking side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Three-letter IATA airport code (e.g. 'SFO'). Case-insensitive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds 'no account setup, no external booking links, no booking side effects' which reinforces read-only nature and provides extra detail, but adds limited new behavioral insight beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states core purpose, second provides usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter lookup tool with comprehensive annotations, the description covers purpose, usage, and behavioral traits adequately. No output schema but not necessary for this type of tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (code) with 100% schema description coverage. Description does not add meaning beyond the schema's own description; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'look up details for one airport by IATA code' (verb+resource+identifier) and distinguishes from siblings by referencing plan_flight_route and compare_airport_routes for different use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use to validate or explain a single airport before route planning' and contrasts with plan_flight_route and compare_airport_routes for trip routes and multiple pairs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE practical travel timing advice, including booking windows, airport arrival timing, layovers, and seasonal considerations. Use for questions like when to book or how early to arrive; use plan_flight_route when the traveler wants route planning. Read-only, no account setup, no external booking link, and no booking side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| origin | No | Origin IATA code. Optional — used to determine if route is international. | |
| destination | No | Destination IATA code. Optional — used to determine if route is international. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, destructive=false, idempotent. Description adds value: 'FREE', 'no account setup, no external booking link, no booking side effects' which are beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and examples, second gives usage and side-effect info. No redundant words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description gives reasonable context for a free advice tool. Could mention result format but not missing critical info for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. Description does not add parameter-specific guidance beyond schema, meeting baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'practical travel timing advice' with specific examples (booking windows, airport arrival etc.) and distinguishes from sibling tool 'plan_flight_route'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use for questions like when to book or how early to arrive' and 'use plan_flight_route when the traveler wants route planning', providing clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE live category guide from the ForgeMesh travel-agent backend. Use this first to see the available travel flows and choose the next useful call: free airport/timing/coverage tools or paid x402 planning services. Read-only, no account setup, no booking side effects.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that it is 'FREE', 'no account setup, no booking side effects', and 'live', which provides useful behavioral context beyond the annotations, though the core safety profile is already covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with key purpose ('FREE live category guide'). Every sentence adds value: purpose, usage guidance, and safety. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool without output schema, the description completely covers what the tool does, when to use it, and its safety profile. No additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema coverage (empty schema). Description correctly omits parameter details as none exist. Baseline 4 for no parameters applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available travel flows/categories, specifying it's a 'FREE live category guide from the ForgeMesh travel-agent backend'. It distinguishes itself from siblings by positioning it as the first call to see available flows before choosing other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this first to see the available travel flows and choose the next useful call', and categorizes subsequent tools into free airport/timing/coverage vs paid planning services. This provides clear when-to-use guidance and differentiates from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to the live paid x402 day-trip service for a destination, route, or origin-based ask. Use when a traveler wants a relaxed day out with timing, water, food, transit, weather, and backup options. The MCP can return live server output or x402 request metadata for clients that can pay with x402.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lon | No | ||
| date | No | ||
| theme | No | ||
| budget | No | ||
| origin | No | ||
| interests | No | ||
| destination | No | ||
| time_window | No | ||
| radius_miles | No | ||
| content_style | No | ||
| transportation_modes | No | ||
| include_local_context | No | ||
| max_distance_or_travel_time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, openWorldHint. The description adds value by disclosing it's a paid x402 service, returns live output or metadata, and covers timing, water, food, transit, weather, and backup. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, approximately 50 words, every sentence provides essential information. Front-loaded with the core purpose, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters, no output schema, and no parameter descriptions, the description is insufficient for correct invocation. It lacks details on parameter formats, how to combine them, and expected return structure. Agents would struggle to fill in parameters appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 14 parameters and 0% schema description coverage, the description does not explain individual parameter meanings. It only gives high-level hints about content (e.g., timing, water, food), but agents cannot infer how to set origin, destination, interests, etc. from this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it connects to a paid day-trip service for destination/route/origin asks, specifying it's for relaxed day out with various aspects. It distinguishes from siblings like plan_weekend_getaway by focusing on day trips, but lacks explicit differentiation from plan_weather_aware_trip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context for when to use ('relaxed day out') and mentions output options, but does not explicitly state when not to use or compare with alternatives such as plan_weekend_getaway or plan_weather_aware_trip.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plan one flight route between two airports. Use when a traveler wants a clear starting point for a specific origin and destination; use compare_airport_routes for multiple route choices, create_booking_link only when route details are already known, and get_airport_details only to validate one airport. Read-only, no account setup, no booking side effects. return_date is optional; omit it for one-way trips. Responses include route metadata and may include commission-eligible external booking links.
| Name | Required | Description | Default |
|---|---|---|---|
| origin | Yes | Origin airport IATA code (e.g. 'LAX', 'JFK'). Case-insensitive. | |
| currency | No | ISO 4217 currency code (default: USD). Used in booking link parameters. | |
| destination | Yes | Destination airport IATA code (e.g. 'LHR', 'NRT'). Case-insensitive. | |
| return_date | No | Return date in YYYY-MM-DD format. Omit for one-way trips. | |
| departure_date | No | Departure date in YYYY-MM-DD format. Optional — omit for open date searches. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, etc. The description adds context: 'Read-only, no account setup, no booking side effects' and mentions response content (metadata and booking links), which adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three sentences with no redundancy. Purpose is front-loaded, followed by usage guidelines, behavioral notes, and a param note. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, behavior, and param hint. Lacks detailed output structure, but mentions response includes route metadata and booking links. Annotations partially compensate for missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description repeats some schema info (e.g., return_date optional) but adds no new parameter-level details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Plan one flight route between two airports' with a specific verb and resource. It effectively distinguishes from sibling tools like compare_airport_routes, create_booking_link, and get_airport_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use ('when a traveler wants a clear starting point') and when not to, naming specific alternative tools for different scenarios. Also clarifies optionality of return_date for one-way trips.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to the live paid x402 weather-aware planning service for a destination or coordinate pair. Use when the traveler wants rain, heat, wind, and indoor backup awareness before committing to outdoor time.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lon | No | ||
| date | No | ||
| plan_type | No | ||
| destination | No | ||
| time_window | No | ||
| transportation_modes | No | ||
| max_distance_or_travel_time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds that the service is live and paid, and that it provides specific weather awareness (rain, heat, wind, indoor backup). This adds some behavioral context beyond annotations but not extensively; no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and usage scenario. Every sentence is meaningful; no wasted words. The description is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no required fields, no output schema, the description is too brief. It does not explain what the output provides, how to use parameters effectively, the meaning of 'x402', or that the service is paid (cost consideration). The tool's completeness is insufficient for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It hints at destination/coordinate pair and weather factors, but it fails to explain how parameters like date, time_window, plan_type, transportation_modes, or max_distance_or_travel_time map to inputs. The brief mention provides minimal guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool connects to a specific live paid weather-aware planning service for a destination or coordinate pair. It uses a specific verb ('connect') and resource ('x402 weather-aware planning service'), and it distinguishes from siblings like plan_day_trip or plan_weekend_getaway by focusing on weather awareness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use the tool when the traveler wants rain, heat, wind, and indoor backup awareness before committing to outdoor time. This provides clear context for when to use it, though it does not mention when not to use it or provide direct alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to the live paid x402 weekend-getaway service for a short overnight escape. Use when the traveler wants a calmer planning brief with lodging posture, water/weather fit, transportation, and easy backup ideas. The MCP can return live server output or x402 request metadata for clients that can pay with x402.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lon | No | ||
| budget | No | ||
| origin | No | ||
| end_date | No | ||
| start_date | No | ||
| trip_style | No | ||
| destination | No | ||
| lodging_style | No | ||
| destination_currency | No | ||
| transportation_modes | No | ||
| max_distance_or_travel_time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, openWorld. Description adds critical behavioral detail: it requires payment via x402 and can return live server output or x402 metadata. This goes beyond the annotations and is valuable for agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences front-load purpose and usage. No fluff, but could be slightly more direct about parameter expectations. Still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no output schema, and no parameter descriptions, the description covers purpose and usage context but leaves significant gaps about input specifics and expected output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with 12 parameters all optional. The description mentions some concepts (lodging, water/weather, transportation) that loosely map to parameters but provides no explicit semantic meaning or format guidance for any parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool connects to a paid weekend-getaway service for short overnight escapes. It distinguishes from siblings like plan_day_trip by specifying it's for weekend getaways. However, the phrasing 'live paid x402 weekend-getaway service' is slightly opaque.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage context: 'Use when the traveler wants a calmer planning brief with lodging, water/weather, transportation, and backup ideas.' It also mentions payment via x402. But it does not explicitly state when not to use or compare to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE live backend call for requesting coverage for a town, neighborhood, local ritual, free experience, or source set. Use this when you want the system to remember a place worth watching: local vibe, freebie list, sunset walk, opening-soon pattern, or creator angle.
| Name | Required | Description | Default |
|---|---|---|---|
| town | No | ||
| notes | No | ||
| state | No | ||
| county | No | ||
| contact | No | ||
| country | No | ||
| location | No | ||
| destination | No | ||
| neighborhood | No | ||
| recheck_days | No | ||
| signal_types | No | ||
| source_links | No | ||
| content_style | No | ||
| creator_angle | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'requesting coverage' and 'remember' which imply a write operation, but the annotations declare readOnlyHint=true (no state change) and idempotentHint=true (read-only). This is a clear contradiction, undermining trust. The descriptions of 'FREE live backend call' add no behavioral clarity beyond the annotations. Score is 1 due to the contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and front-loaded with the purpose and usage guidance. The word 'FREE' is slightly redundant but does not significantly detract. It earns high marks for economy, though the single structure could be more formal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 14 optional parameters and no output schema, the description is insufficiently complete. It fails to explain what the request returns, which parameters are necessary for common use cases, or how the backend processes it. Annotations provide some context but the description adds little beyond purpose and use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It only lists examples of what to request in general terms but does not define any of the 14 parameters (e.g., town, location, signal_types). This provides negligible help in understanding how to fill the schema, resulting in a very low score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb (requesting coverage) and the resources (town, neighborhood, local ritual, etc.), making the purpose clear. It is distinctly different from sibling tools like plan_flight_route or convert_currency, which are travel planning focused. The informal tone does not obscure the function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific scenarios (local vibe, freebie list, etc.) indicating when to use this tool, but it does not explicitly mention when not to use it or compare it to alternative tools. The sibling tools are quite different, so confusion is unlikely, but the lack of explicit exclusions drops the score from 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0check_trip_disruptionscompare_airport_routesconvert_currencycreate_booking_linkcreator_experiencesfind_transit_optionsget_airport_detailsget_travel_timing_advicelist_travel_categoriesplan_day_tripplan_flight_routeplan_weather_aware_tripplan_weekend_getawayrequest_local_coverageEach tool targets a distinct travel task: disruptions, routes, currency, booking, airport details, timing, categories, various planning scopes (day trip, weekend, weather-aware, flight route), transit, creator experiences, and local coverage. Even the multiple 'plan' tools are clearly differentiated by domain (day vs weekend vs weather vs flight). No two tools serve the same purpose.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., check_trip_disruptions, plan_flight_route, convert_currency). The verbs are imperative and descriptive, and there is no mixing of casing styles or unconventional naming.
14 tools is well within the ideal 3-15 range for a travel domain server. The number is sufficient to cover a broad set of travel agent functionalities without being overwhelming or sparse. Each tool earns its place.
The tool set covers the major travel agent workflow: discovery (list_travel_categories), airport lookup (get_airport_details), route planning (plan_flight_route, compare_airport_routes), timing advice (get_travel_timing_advice), currency conversion (convert_currency), booking links (create_booking_link), disruptions (check_trip_disruptions), transit (find_transit_options), and specialized planning (day trip, weekend, weather-aware, creator experiences). There are no obvious gaps for the stated purpose.
Your personal AI travel concierge — flights, hotels, 116M+ POIs, visas, weather & more
x402-gated weather and FX exchange rate data endpoints for AI agents.
Pay-per-call change-intelligence feeds for AI agents over x402 (deps, security, regs, tariffs)
Personal AI travel agent. Points optimization, live flight/hotel/award search, trip planning.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/forgemeshlabs/travel-agent-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server