Fact copy: MCP for travel and expense management: from data access to controlled action

Factual summary

An MCP server for business travel and spend is not merely a new search interface. Its value depends on authoritative sources, temporal accuracy, role enforcement and a strict boundary between analysis and consequential action.

Why travel spend is a demanding MCP domain

Booking, payment, receipt capture, policy checking and accounting look like one journey to a user but usually span several systems of record. MCP can expose task-oriented capabilities without teaching every assistant each underlying API. It cannot remove the need for identity, accounting semantics or data reconciliation.

A useful response must preserve provenance. Cost, policy status and trip association are incomplete without source identifiers, currency, data timestamp and the rule version used for evaluation.

What the current Perk example actually documents

Perk introduced a remote MCP server in July 2026. Its developer and help documentation list read capabilities for trips, expenses, invoices, reporting, policies, events, cards and users, connected through OAuth and existing account roles.

The same help material says booking or changing travel, creating or submitting expenses and approvals are not current capabilities. They have been announced for the future. Product state and roadmap must remain separate factual categories.

Architecture and system boundaries

The host, MCP client, authorization server, MCP server and systems of record have distinct responsibilities. The MCP server may normalize data but should preserve stable trip, transaction, expense and invoice references instead of creating an untraceable second truth.

Interactive questions are a suitable MCP pattern; scheduled and high-volume transfers remain better served by APIs, exports or data pipelines. The two integration modes complement each other.

Read first, then introduce a write-risk ladder

Read tools can reconcile missing receipts, policy exceptions or unmatched invoice lines with limited side effects. A tool must still enforce tenant and role boundaries server-side and return data freshness and provenance.

Writes should be decomposed into draft, validate, request approval and execute. Binding operations require revalidation, explicit user consent, idempotency and an audit trail that records identity, tool version, source references and backend outcome.

Security is layered

OAuth establishes client access to a protected resource and scopes. Business roles determine which records a user may see. Tool policy and user confirmation determine what the assistant may do in a particular interaction. None of these controls replaces the others.

Invoices, receipts and travel documents are untrusted input and may contain prompt-injection text. Hosts and servers must separate content from instructions, minimize sensitive fields and avoid retaining short-lived download links in chat or telemetry.

A measurable pilot

A useful pilot evaluates source completeness, exception accuracy, time to resolution, unnecessary data access and authorization failures. Write pilots add revalidation failures, prevented duplicates and audit reconstruction.

The wider lesson is vendor-independent: teams should publish fewer capabilities with precise semantics, bounded authority and verifiable provenance rather than maximizing tool count.

FAQ

Primary sources and specifications

• Perk MCP – Entwicklerdokumentation
• Perk Help Center – aktueller Funktionsumfang
• Perk Help Center – Verbindung und OAuth
• Perk – Produktankündigung vom 13. Juli 2026
• MCP Authorization Specification 2025-11-25
• MCP Security Best Practices