Concur MCP server

SAP Concur MCP

A Model Context Protocol server that connects Claude to SAP Concur: your expense reports, the expenses on them, available (unassigned) expenses, receipts, and Concur Travel trips — read and write, with every write confirmation-gated.

[!WARNING]

AI-developed project. This codebase was entirely built and is actively maintained by Claude. No human has audited the implementation. Review all code and tool permissions before use.

[!CAUTION]

Unofficial and unsupported. This server does not use Concur's documented partner API. It calls the internal GraphQL API the Concur web app itself uses, authenticated with your own signed-in browser session. It may break without notice, and automated use may conflict with SAP Concur's or your employer's terms. Use it only for your own account, at your own discretion.

What you can do

Ask Claude things like:

• "Which of my Concur reports are still unsubmitted, and what's blocking them?"
• "Show me the card transactions that aren't on a report yet."
• "Create a report called 'Austin offsite' and move last week's Uber and hotel charges onto it."
• "Upload ~/Downloads/dinner.pdf and attach it to the dinner expense."
• "When does my next trip leave, and what hotel am I in?"

Requirements

• Claude Desktop, Claude Code, or any MCP host
• Node.js 22.5 or later
• The ContextMint Bridge browser extension and a signed-in Concur tab (https://.concursolutions.com/…)

Installation

Claude Code plugin

claude plugin marketplace add chrischall/concur-mcp
claude plugin install concur@chrischall

Any MCP host (npx)

{
  "mcpServers": {
    "concur": {
      "command": "npx",
      "args": ["-y", "@chrischall/concur-mcp"],
      "env": { "CONCUR_DC": "us2" }
    }
  }
}

Claude Desktop (.mcpb)

Install the .mcpb bundle from the latest release. The installer asks for your datacenter (default us2).

How it authenticates

Concur's web app authenticates its API calls with an HttpOnly JWT cookie that the page itself cannot read. This server uses the fetchproxy bridge only to read three session cookies from your signed-in Concur tab: JWT, plus Concur's legacy session cookies OTSESSIONAABQRD and OTSESSIONAABQRN. Every API call is then made from Node with Authorization: Bearer and a Cookie header carrying whichever OTSESSION cookies the tab had — the parts of Concur still served by its legacy services (report keys, currencies, available receipts, permissions) answer an error without them. The cookies are held in memory only and never appear in an error or a log; the only thing written under your home directory is the bridge's pairing identity.

The token lives 60 minutes. The server re-reads the cookies (all together) from your tab when the token is within two minutes of expiry, or once on a 401 (one re-read and one retry per call, never a loop). A read that fails the way a stale OTSESSION cookie fails gets the same single re-read and retry. Concur keeps the cookies fresh while a tab is open, so keep a signed-in Concur tab open while you use the tools. concur_healthcheck reports which source supplied the token, how many minutes it has left and whether the legacy session cookie was found — never a cookie value.

Shortened. The full README is on GitHub.