What can you do with this server?

This server is an agentic travel orchestration and payment layer enabling AI agents to autonomously search, budget-check, pay, and book travel. * Search Hotels (travel_search_stays): Search 2.2M+ hotels by city and date range, with optional price cap and guest count filters. Returns quotes with a quoteId for booking. * Search Flights (travel_search_flights): Search flights by origin/destination IATA codes and date. Supports live real-time offers via Duffel (300+ airlines) when a Duffel API key is configured. * Set Agent Budget (travel_set_agent_budget): Cap an AI agent's autonomous USDC travel spending to prevent overspending. * Authorize a Booking (travel_authorize_booking): Pay for a booking via two routes: * Crypto-native (Travala): Uses x402/USDC on Base (gasless, ~$0.01/tx), earning a 10% cbBTC developer rebate (7% to developer, 3% to treasury). * Legacy Web2: Issues a single-use, MCC-locked Visa virtual card (VCN) limited to the booking total, usable with merchants like Airbnb or Skyscanner. * Confirm a Booking (travel_confirm_booking): Finalize an authorized booking post-verification. * Cancel a Booking (travel_cancel_booking): Cancel a booking and void its payment authorization. * List Rebates (travel_list_rebates): Track accumulated cbBTC developer rebates from Travala-routed bookings. * Demo Mode: Without API keys, simulates search and payment end-to-end for offline testing.

Which integrations are available for this server?

Allows AI agents to book travel on Airbnb by issuing a single-use MCC-locked Visa virtual card, limited to the booking total. Integrates with Visa payment network by issuing single-use MCC-locked virtual card numbers for legacy travel merchants, enabling automated travel bookings.

How do I use @furlpay/travel-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@furlpay/travel-mcp Find hotels in Paris from June 10 to June 15 under $200 per night" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

@furlpay/travel-mcp

Official

by FurlPay

Overview Schema Related Servers Score Discussions

TypeScript

Remote

@furlpay/travel-mcp — FurlPay Travels

The payment & orchestration layer for agentic travel. This MCP server composes Travala's Travel MCP (search 2.2M+ hotels + flights) with FurlPay's payment rails (pay), so an AI agent can search, budget-check, pay, and book travel autonomously.

Two payment routes, chosen per booking:

Travala / crypto-native → an x402 payment proof, settled in gasless USDC on Base. Accrues the 10% cbBTC developer rebate Travala pays on MCP-driven bookings.
Legacy Web2 merchant (Airbnb, Skyscanner…) → a single-use Visa virtual card, MCC-locked to travel and limited to the booking total.

Clone-and-run: with no keys, search and payment simulate end-to-end (no network) so you can drive the whole loop offline. Zero runtime dependencies.

Maintained by FurlPay · MIT licensed.

Use as an MCP server

{
  "mcpServers": {
    "furlpay-travels": {
      "command": "npx",
      "args": ["-y", "@furlpay/travel-mcp"],
      "env": {
        "FURLPAY_API_KEY": "fp_live_sk_...",     // omit for demo mode
        "TRAVALA_API_KEY": "...",                // omit for demo inventory
        "DUFFEL_API_KEY": "duffel_test_...",     // live flight offers (free test token, duffel.com)
        "FURLPAY_DEVELOPER_WALLET": "0xYourWallet" // receives the 7% cbBTC split
      }
    }
  }
}

Tools

Tool	What it does
`travel_search_stays`	Search Travala hotels for a city + date range
`travel_search_flights`	Search flights for a route + date
`travel_set_agent_budget`	Cap an agent's USDC travel spend
`travel_authorize_booking`	Pay a booking — x402/USDC (Travala) or single-use MCC-locked Visa VCN (legacy)
`travel_confirm_booking`	Confirm after passkey step-up
`travel_cancel_booking`	Cancel & void the authorization
`travel_list_rebates`	Accumulated 10% cbBTC rebates (7% dev / 3% treasury)

Related MCP server: remit.md MCP Server

Trusted-agent mode (new in 0.2.0)

Visa's Trusted Agent Protocol went production-live in July 2026: agent-initiated payments carry cryptographic proof of agent identity and user consent. This server supports the same model via @furlpay/agent-trust — configure a MandateVerifier and every travel_authorize_booking call must present a mandateToken: an agent-signed intent under a user-signed spend mandate (budget cap, MCC allowlist, expiry, single-use, replay-safe).

import { TravelClient } from "@furlpay/travel-mcp";
import { AgentTrust, generateKeypair, issueMandate, createBookingToken } from "@furlpay/agent-trust";

const trust = new AgentTrust();
trust.registerUser(user.publicKeyPem);
trust.registerAgent(agent.publicKeyPem);

const travel = new TravelClient({ trust }); // bookings now REQUIRE a valid mandateToken

const mandate = issueMandate({ /* user signs: $500 cap, MCC 7011+4511, 7-day expiry */ });
const mandateToken = createBookingToken({ mandate, /* agent signs THIS exact intent */
  intent: { amountUsd: 320, source: "legacy", mcc: "7011" } });

const booking = await travel.authorizeBooking({ amountUsd: 320, source: "legacy", mandateToken });
// booking.trust = { agentKeyId, mandateId, remainingUsd }

The verifier checks the full chain — user signed the mandate, mandate names this agent, agent signed this exact amount/mcc/source, constraints hold, nonce never seen — before any x402 proof or virtual card is issued. Without a verifier configured, behavior is unchanged (back-compat).

Use as a library

import { TravelClient, MCC } from "@furlpay/travel-mcp";

const travel = new TravelClient({ developerWallet: "0xDev" });

const stays = await travel.searchStays({
  city: "London", checkIn: "2026-08-01", checkOut: "2026-08-04", maxNightlyUsd: 200,
});

travel.setAgentBudget("agent_1", 1000);

// Crypto-native route → x402/USDC on Base + 10% cbBTC rebate
const booking = await travel.authorizeBooking({
  amountUsd: stays[0].totalUsd, source: "travala", agentId: "agent_1", reference: stays[0].quoteId,
});
// booking.authorization.x402  ·  booking.rebate.developerUsd

// Legacy merchant route → single-use MCC-locked Visa VCN
const legacy = await travel.authorizeBooking({ amountUsd: 130, source: "legacy", mcc: MCC.LODGING });
// legacy.authorization.card = { last4, mccWhitelist, singleUse, limitUsd }

travel.listRebates();   // { developerTotalUsd, treasuryTotalUsd, accruals }

Live flight data (new in 0.3.0)

Set DUFFEL_API_KEY and travel_search_flights returns live real-time offers — NDC + GDS + LCC content from 300+ airlines via Duffel, cheapest first. Free test tokens (duffel_test_…) work out of the box against Duffel's sandbox inventory. Any Duffel failure falls back to Travala/demo, so the agent loop never breaks.

Why Duffel in mid-2026: Amadeus Self-Service shuts down July 17 2026, Kiwi's Tequila is closed to new partners, and Expedia/Booking gate API access behind commercial review — Duffel is the one top-1% supplier a developer can start on today with no contract.

How the routes map to reality

Route	Rail	Why
`travala`	x402 → gasless USDC on Base, ~$0.01/booking	The rail Travala's protocol accepts directly; earns the cbBTC rebate
`legacy`	Single-use Visa VCN, MCC-locked (7011 lodging, 4511 airlines, 7512 car rental)	Reaches Web2 travel merchants Travala doesn't cover; card can only spend on travel, up to the booking total

FurlPay's value here is the layer Travala doesn't provide: agent spend budgets, multi-token funding, VCN issuing for legacy merchants, and rebate accounting.

Run the demo

npm run example        # full search → pay → book → rebate flow, demo mode
npm start              # run the MCP server on stdio

Test

npm test               # tsc build + node --test (demo mode, no network)

The suite pins the contract: deterministic search, the x402 route's proof + exact 10%/(7/3) rebate math, the legacy route's single-use MCC-locked VCN, budget enforcement, the confirm/cancel lifecycle, rebate aggregation (excluding cancellations), and well-formed MCP tools.

Scope

This server orchestrates Travala search and FurlPay payments — it does not custody funds or settle on-chain itself; x402 settlement and card issuing happen in the FurlPay API, and inventory/fulfilment in Travala. Point it at your own accounts and it books on your behalf. Issuing travel cards and handling refunds carries money-transmission/merchant-compliance obligations — wire in FurlPay's compliance engine before going live.

License

MIT

Available Tools

7 tools

travel_authorize_bookingA

Authorize payment for a booking within the agent's budget. source='travala' pays via x402/USDC on Base and accrues the 10% cbBTC rebate; source='legacy' issues a single-use, MCC-locked Visa virtual card for Web2 merchants (Airbnb, Skyscanner).

ParametersJSON Schema

Name	Required	Description
`mcc`	No	Merchant Category Code lock for the legacy route, e.g. 7011 (lodging)
`source`	Yes
`agentId`	No
`currency`	No	Default USDC
`amountUsd`	Yes
`reference`	No	Quote/booking reference

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses payment mechanisms, rebates, and card type for each source. However, it omits behavior on budget insufficiency, side effects (e.g., fund locking), idempotency, or required parameters like agentId. Provides some value but incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences front-load the action and then detail the two source routes. No wasted words, efficiently structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex payment authorization tool with 6 parameters, no output schema, and no annotations, the description covers basics but lacks explanation of return values, error conditions, or parameter dependencies (e.g., mcc required for legacy). Adequate but not fully self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% (3 of 6 parameters documented). The description adds meaning for 'source' (explains enum values) and 'mcc' (reinforces MCC-locked for legacy). But no extra details for 'amountUsd', 'currency', 'agentId', or 'reference'. Baseline 3 with marginal enhancement.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Authorize payment for a booking within the agent's budget,' which is a specific verb-resource combination. It differentiates from siblings like travel_confirm_booking or travel_set_agent_budget by focusing on payment authorization. The two source routes further refine the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage after booking and within budget, and guides on choosing between 'travala' and 'legacy' sources. However, it lacks explicit when-not-to-use or ordering relative to siblings (e.g., before confirmation). Clear context but no exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

travel_cancel_bookingC

Cancel a booking and void its authorization.

ParametersJSON Schema

Name	Required	Description	Default
`bookingId`	Yes

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It states the action is destructive (cancellation and voiding), but omits details such as irreversibility, refund implications, or side effects on related bookings.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that efficiently conveys the tool's primary action. It is front-loaded with the key verb and noun.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one required parameter, no output schema), the description covers the basic action but lacks context on return values, error conditions, or state changes after cancellation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not elaborate on the bookingId parameter. No format, source, or constraints are provided, leaving the agent without necessary context to populate the parameter correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Cancel a booking and void its authorization') with a specific verb and resource. However, it does not differentiate from sibling tools like travel_confirm_booking, which share the 'travel_' prefix and similar booking context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when cancellation is appropriate, or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

travel_confirm_bookingB

Confirm an authorized booking (after passkey step-up in a real flow).

ParametersJSON Schema

Name	Required	Description	Default
`bookingId`	Yes

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the burden. It mentions 'authorized booking' and 'passkey step-up' implying security, but does not disclose side effects, idempotency, rate limits, or whether the action is irreversible. The verb 'confirm' suggests a state change but details are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no wasted words. The core action and timing are front-loaded, achieving maximal clarity with minimal text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple structure (1 param, no nested objects, no output schema) and no annotations, the description provides the essential purpose and usage context. However, it lacks information about return values or error conditions, which would be needed for a complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema coverage is 0% and the description does not explain the 'bookingId' parameter's meaning, format, or constraints. The schema only provides the type, so the description adds no value for parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'confirm' and resource 'authorized booking', clearly distinguishing it from sibling tools like travel_authorize_booking (authorization step) and travel_cancel_booking (cancellation). The phrase 'after passkey step-up' adds precision.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description explicitly states 'after passkey step-up in a real flow', providing clear context for when to use. However, it does not mention when not to use or direct alternatives beyond the implicit sequence.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

travel_list_rebatesA

List accumulated 10% cbBTC developer rebates from Travala-routed bookings (7% developer / 3% treasury split).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full disclosure burden. It only states 'List', implying a read operation, but does not disclose behavioral traits such as authentication needs, rate limits, data freshness, or whether the operation is non-modifying.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the key action and resource without any extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and no output schema, the description covers the basic purpose. However, it lacks explanation of what 'accumulated' entails (e.g., time frame, reset policy) and does not specify return structure, leaving gaps for a complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so schema coverage is 100% by default. The description does not need to add parameter meaning, and the baseline of 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'List' and clearly identifies the resource as 'accumulated 10% cbBTC developer rebates from Travala-routed bookings' with the split details. It distinctly separates from sibling tools that handle booking operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for reading rebate information but provides no explicit guidance on when to use this tool versus alternatives. Context from sibling tools indicates different functions, but no when-not-to-use or alternatives are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

travel_search_flightsA

Search flights via Travala for a route and date. Returns quotes with a quoteId.

ParametersJSON Schema

Name	Required	Description
`to`	Yes	Destination IATA code
`date`	Yes	YYYY-MM-DD
`from`	Yes	Origin IATA code

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must cover behavioral traits. It mentions returning quotes but does not disclose whether it is read-only, any authorization requirements, rate limits, or side effects. This is minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence with no wasted words. It front-loads the key action and result effectively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that there are three simple parameters, no enums, and no output schema, the description covers the basic purpose and return value. However, it lacks details on pagination, error handling, or additional constraints (e.g., date range limits) that could be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% coverage, with good descriptions for each parameter. The description adds no extra meaning beyond what the schema already provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (Search), resource (flights), platform (via Travala), and return value (quotes with quoteId). It is distinct from sibling tools like travel_search_stays, which are for stays.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for flight searches by naming the resource and platform. It does not explicitly exclude alternatives or provide when-not guidance, but the context is sufficiently clear to differentiate from search_stays.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

travel_search_staysA

Search Travala's 2.2M+ hotels (Marriott, Hilton, IHG, …) for a city and date range. Returns quotes with a quoteId to book.

ParametersJSON Schema

Name	Required	Description
`city`	Yes
`guests`	No
`checkIn`	Yes	YYYY-MM-DD
`checkOut`	Yes	YYYY-MM-DD
`maxNightlyUsd`	No	Optional nightly price cap in USD

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It states the tool returns quotes with a quoteId, implying a read operation, but does not explicitly confirm non-destructive nature or disclose any behavioral traits like rate limits or authentication needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the key action and resource, and contains no unnecessary words. It efficiently conveys the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters, no output schema, and no annotations, the description could provide more detail about return value structure (beyond quoteId), pagination, or error handling. However, for a simple search tool, it is minimally adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 60% with descriptions for checkIn, checkOut, and maxNightlyUsd. The description adds context for city and date range but does not explain 'guests' or compensate for the missing schema descriptions for city and guests.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Search Travala's 2.2M+ hotels' with specific verb and resource, and distinguishes from sibling tools like travel_search_flights and booking actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives, but the purpose is clear enough that an agent would infer usage for hotel search. No exclusions or alternative suggestions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

travel_set_agent_budgetC

Set a USDC spend cap for an agent before it books autonomously.

ParametersJSON Schema

Name	Required	Description	Default
`agentId`	Yes
`limitUsd`	Yes

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It only states a write operation (set) without disclosing behavioral traits like overwrite behavior, authorization needs, rate limits, or side effects. Significant gaps remain.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The single sentence is concise, but the extreme brevity omits critical information. It is not a model of effectiveness; it sacrifices completeness for shortness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and only two parameters with zero coverage, the description is severely incomplete. It fails to address return values, prerequisites, error conditions, or confirmation of the set action.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage and no parameter explanation in the description, the agent receives no semantic context for 'agentId' or 'limitUsd'. The description does not compensate for the missing schema details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: setting a USDC spend cap for an agent before autonomous booking. The verb 'set' and resource 'agent budget' are specific, and the context distinguishes it from sibling tools (authorize, cancel, confirm bookings, etc.).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'before it books autonomously' implies a usage timing, but no explicit guidance on when not to use or alternatives is provided. Given no sibling tools for budget management, the guidance is minimal but not misleading.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: searching flights/stays, authorizing/confirming/canceling bookings, listing rebates, and setting budget. No overlap.

Naming Consistency5/5

All tool names follow a consistent travel_verb_noun pattern in snake_case, e.g., travel_search_flights, travel_authorize_booking.

Tool Count5/5

7 tools is well-scoped for a travel booking agent, covering search, booking lifecycle, rebates, and budget without excess or deficiency.

Completeness4/5

Core booking workflow (search, authorize, confirm, cancel) is covered, plus rebates and budget. Missing a tool to retrieve booking details, but overall fairly complete.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

BoostedTravel A
com.boostedchat
Flight search & booking for AI agents. 400+ airlines, $20-50 cheaper than OTAs.
Travel & Transportation E-commerce & Retail Agent Orchestration
21,966
agentictrade A
io.github.miranttie
AI service marketplace — agents discover, call, and pay for API services automatically.
AI & Machine Learning Agent Orchestration Payments & Billing
522
mcp-server A
com.pricetik
Travel & commerce intelligence for AI agents: search, book & price-track hotels, events, retail.
Travel & Transportation E-commerce & Retail
2
agentorist A
com.agentorist
Booking gateway for AI agents — discover events, movies & hotels, hand off to partner checkout.
Travel & Transportation Entertainment & Media
72

Related MCP Servers

Armor Crypto MCP
Cryptocurrency Blockchain Web3 & Decentralized Tech
emmaThompson07
A
license
C
quality
D
maintenance
Enables AI agents to interact with cryptocurrency ecosystems through wallet management, trading operations (swaps, DCA, limit orders), staking, and multi-chain support starting with Solana.
Updated a year ago (2025-09-26 02:22 UTC)
37
GPL 3.0
remit.md MCP Server
Finance Autonomous Agents Blockchain
pay-skill
A
license
Not graded
quality
F
maintenance
Enables AI agents to perform financial transactions such as direct payments, escrows, and bounty management using natural language with zero code integration. It provides a comprehensive suite of tools for fund streaming, subscriptions, and reputation tracking to facilitate secure agent-to-agent commerce.
Updated 5 months ago (2026-04-07 19:51 UTC)
22
MIT
trip-planner-mcp
Travel & Transportation Search Autonomous Agents
idean3885
A
license
A
quality
B
maintenance
Enables AI agents to plan trips by searching flights, accommodations, and activities, and managing itineraries collaboratively with role-based permissions.
Updated 2 days ago (2026-09-01 10:04 UTC)
20
6
1
MIT
Travala Travel MCPofficial
Travel & Transportation Cryptocurrency Blockchain
travala
F
license
Not graded
quality
D
maintenance
Travala Travel MCP is the first end-to-end agentic AI travel protocol. It lets AI/ MCP clients search live hotel inventory on 2.2M+ properties, compare room packages and complete bookings, with payment settled on-chain in USDC on the Base network via x402 protocol. OAuth-secured; booking & cancellation are identity- & OTP-protected. Developers earn rewards on bookings driven through their agents.
Updated 3 months ago (2026-06-02 08:40 UTC)
4

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/FurlPay/furlpay-travel-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

@furlpay/travel-mcp — FurlPay Travels

Use as an MCP server

Tools

Trusted-agent mode (new in 0.2.0)

Use as a library

Live flight data (new in 0.3.0)

How the routes map to reality

Run the demo

Test

Scope

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Travala Travel MCPofficial

Latest Blog Posts

MCP directory API