What is the Model Context Protocol?

MCP is an open protocol developed by Anthropic in late 2024 that standardizes how AI agents connect to external tools and data sources. Think of it as 'USB-C for AI tools' — one connector, many providers. Claude Desktop, Cursor, the OpenAI Apps SDK, Mastra, LangGraph all speak it.

Why use MCP for finance tools instead of custom RPC?

Three reasons: (1) any MCP-compliant client works — you're not locked into Claude or any specific vendor's agent runtime; (2) the protocol enforces a tool-listing + permissions surface that's easier to reason about than ad-hoc RPC; (3) the broader MCP ecosystem (registries, smithery installers, debugging tools) gets you for free.

Is MCP secure for production finance use?

MCP itself is just a protocol — security depends on what you build on top. closegate adds: per-actor identity bound to the transport (X-Actor-Id), server-side SoD enforcement via the policy gate, append-only audit log at the database layer, tier-routed tool authorization. The MCP server doesn't grant trust; it conveys tool calls. Trust comes from what the server does with them.

Deep dive

MCP servers for finance: what Model Context Protocol means for close + recon

The Model Context Protocol (MCP) is the emerging standard for AI agent tool surfaces. What an MCP server for finance close + reconciliation looks like, and why it beats custom RPC.

Dipankar Sarkar June 16, 2026 4 min read

MCP Model Context Protocol Claude Desktop AI agents finance

The Model Context Protocol (MCP) shipped in late 2024 and is the emerging standard for how AI agents connect to external tools. Think of it as USB-C for AI: one protocol, many providers; tool servers (closegate, plus thousands of others in the registry) speak the same shape, clients (Claude Desktop, Cursor, OpenAI Apps SDK, Mastra, LangGraph) speak the same shape.

For finance specifically, MCP is a better foundation than custom RPC because it standardizes the tool-listing + permissions surface that auditors specifically want to reason about. This article walks what an MCP server for finance close + reconciliation looks like, and the security shape that makes it production-ready.

What MCP gets you

Three concrete things:

Client interoperability. Your finance team uses Claude Desktop on macOS. Your AI architect prefers Cursor. Your security team is evaluating OpenAI Apps SDK. With MCP, the same server works for all three. Without MCP, you build three custom integrations.
Standardized tool listing. Every MCP server publishes list_tools() that returns names, descriptions, input schemas, and (in closegate’s case) tier annotations. Clients enumerate; users see exactly which tools are available; auditors enumerate the surface for a security review.
Ecosystem. The MCP registry at registry.modelcontextprotocol.io is the canonical discovery surface. Smithery (smithery.ai) offers one-line installers. There’s a growing set of debugging tools (mcp inspector, etc.). All of this comes for free.

What closegate’s MCP server looks like

19 tools, tier-routed by NIST AI RMF reversibility:

T0 (read-only / propose):
  run_recon_pass          investigate_exception   query_audit
  propose_match           list_pending_escalations
  generate_close_summary  ap_propose_invoice_coding
  ap_match_three_way

T1 (reversible + audit):
  reject_match            flag_exception
  escalate_match          resolve_escalation
  ap_confirm_invoice_coding

T2 (HITL + SoD):
  confirm_match
  ap_approve_invoice_for_payment
  ap_propose_payment_run
  ap_approve_payment_run

T3 (dual HITL + irreversible):
  ap_submit_payment_run

The tier is part of the tool’s published metadata. A client can show “this tool requires HITL approval” before the agent calls it.

Plus 4 MCP resources (read-only data):

recon://status     KPI snapshot for dashboard
recon://policy     parsed policy.yaml in JSON form
recon://exceptions open exception list
recon://audit      recent audit-log events

Resources are MCP’s read-only surface for data the agent should reference but not mutate. They’re cacheable client-side and don’t carry tier annotations.

Install paths

The same MCP server is installed three ways depending on client preference:

Claude Desktop

// ~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "closegate": {
      "command": "uvx",
      "args": ["closegate-engine", "mcp", "serve", "--transport", "stdio"],
      "env": {
        "CLOSEGATE_ACTOR_ID": "human:your-name",
        "CLOSEGATE_DB_PATH": "/Users/you/.closegate/recon.db"
      }
    }
  }
}

Cursor

// .cursor/mcp.json
{
  "mcpServers": {
    "closegate": {
      "command": "uvx",
      "args": ["closegate-engine", "mcp", "serve"],
      "env": { "CLOSEGATE_ACTOR_ID": "human:your-name" }
    }
  }
}

Smithery (one line)

npx -y @smithery/cli install closegate-engine --client claude

Smithery handles the config generation automatically; it’s the right path for non-technical end users.

HTTP transport (for non-stdio clients)

closegate-engine mcp serve --transport http --port 8001

The HTTP transport is what production deployments use. The OIDC + reverse-proxy auth backends sit in front of the HTTP server; stdio is for local single-user use.

Why MCP is the right foundation for finance

Three architectural reasons:

1. Identity binding via transport, not arguments

closegate’s MCP server reads X-Actor-Id from the HTTP transport (HTTP/SSE) or from the stdio environment (CLOSEGATE_ACTOR_ID). Tools never accept actor_id as a parameter. The LLM cannot claim to be a different actor because the LLM has no API surface to set the header.

If you built this on custom RPC, you’d have to enforce the same convention by hand — easy to weaken, easy to miss in the next refactor. MCP’s transport-bound metadata makes the convention enforceable.

2. Tier annotations on tool registration

@register_tool(tier=Tier.T2, name="confirm_match")
def confirm_match(match_id: str, rationale: str | None = None) -> Match:
    ...

The decorator fails at registration if you don’t specify a tier. The MCP server’s list_tools() response includes the tier. The runtime checks the tier on every invocation, routes T2/T3 through HITL automatically.

This is what makes the tier model executable rather than aspirational. Every tool, every call, every audit event — the tier is there.

3. Auditor-quotable tool surface

The MCP list_tools() response is the canonical contract. Your external auditor reads it; sees the 19 tools, their tiers, their argument schemas, and their descriptions. The audit narrative is straightforward: “these are the actions the agent can take; these are the controls on each.”

Custom RPC has the same information but it’s spread across handler files, route definitions, and OpenAPI specs. MCP is one document.

Common questions

Does MCP lock me into Anthropic? No. The protocol is open; the spec is public; implementations exist in Python, TypeScript, Go, Rust, more. closegate’s server speaks MCP; your client is whichever MCP-compliant agent you prefer.

What about authentication? MCP itself doesn’t prescribe auth; closegate adds two backends: header-trust (reverse proxy upstream) + native OIDC (authlib + JWKS caching, works with Entra/Okta/Workspace/Auth0/Google/Microsoft 365).

What about rate limiting? Not in MCP; not in closegate’s MCP layer. Rate-limit at the reverse proxy / API gateway in front of the MCP HTTP transport — same pattern as any other HTTP service.

What about audit logging? The MCP layer is thin — every tool call lands at the policy gate, which writes the audit row with the actor identity from the transport. The MCP layer itself doesn’t log; the gate does.

What this gives you

A tool surface that works across every MCP-compliant client
Standardized tier + identity + audit conventions enforceable by code
Ecosystem benefits (registry, Smithery, inspector tooling) for free
A canonical contract document your auditor can read