How Spendesk Gave AI Agents Access to Financial Data (Without Rebuilding Its Security Model)

Financial data integrations demand zero tolerance for error. Spendesk ruled out generic MCP implementations from the start. AI clients must authenticate through the same OAuth system as all other clients, with no parallel authentication stack.

Every tool call enforces the same scopes, roles, and company boundaries as the rest of Spendesk’s platform. The initial release is retrieval-only by design. Assistants can answer questions about payables or suppliers, but cannot approve or pay until the write path earns production trust.

Platformatic’s Fastify-native MCP implementation enabled this without a rebuild. MCP requests connect directly to the same request context as the rest of Spendesk’s stack. The team reused existing OAuth tokens, roles, scopes, and operational tooling. No second authorization system was needed for AI traffic.

The result is a single, consistent pipeline running from API contract to AI tool call:

Tools like get_payables, get_suppliers, and create_purchase_order are registered with a name, description, input schema, and handler, and Platformatic exposes them automatically through the MCP protocol’s tools/list and tools/call.

Because the handlers call straight into Spendesk’s existing services, there’s no shadow version of the business logic living alongside the real one.

Every tool call must pass strict checks before reaching a handler. Only a valid OAuth token issued to an MCP-configured client is accepted. The token must carry the required scope. For example, payable:read can access get_payables, but anything needing payable:write is not visible.

Spendesk independently checks the authenticated user’s role, so even with the right scope, access can be denied if the role does not permit the action. Company or organization context is derived from the token, never from an argument passed by the AI. All input must pass JSON Schema validation before any handler runs.

That role check was a real gap Platformatic’s authorization hook had to close, it needs to inspect the full authenticated request context, not just the MCP payload, and the hook that makes it possible, canAccessTool, didn’t exist in the package until Spendesk needed it.

It’s one of a small set of features the team built against their own production requirements and then contributed upstream rather than keeping in a private fork: AJV-based JSON Schema validation for strict argument checking, transformRouteSchema for attaching Spendesk’s own OAuth requirements and scopes to the schemas MCP routes generate, and a trio of functions: mcpCallTool, mcpHasTool, mcpListToolNames, that let trusted internal workflows reuse the exact same handler, validation, and authorization pipeline as an external MCP call, without a loopback HTTP request in between.

Every one of those is now available to any team building a production MCP on Platformatic, not just Spendesk.

Each MCP tool is built on a Massimo-generated TypeScript client, produced directly from Spendesk’s OpenAPI specs. Any change to an operation’s name, parameters, or response shape triggers a TypeScript error in development or CI, not a broken tool call in production.

Massimo generates clients from a checked-in spec, a local development spec, or the authenticated canonical spec in Spendesk’s service catalogue. Developers can iterate locally and then regenerate against the source of truth before shipping. Spendesk wraps the generated clients in an inter-service client layer, adding request authentication, caching, tracing, and error handling.

This is critical for MCP, since Spendesk’s APIs have large schemas, many optional filters, and varying response shapes. An AI assistant calling a tool does not have a human to catch silent response changes.

AI assistants generate bursty, exploratory API traffic, with no human to notice subtle issues. Internal execution through mcpCallTool skips the network hop for trusted workflows. Redis-backed sessions allow a session started on one instance to continue on another, with a controlled memory fallback if Redis is unavailable. This is essential for distributed production setups like Spendesk’s.

Based on real production logs/metrics over a week, performance is typically fast, with long-tailed outliers only for very complex aggregated responses that aren't cached.

For the fastest results, when we hit the Redis cache (that we also use for the MCP sessions), tool calls take a few ms. The fastest tools are simple lookups:

All well under 100ms.

Write-action tools, such as creating or archiving a supplier, are already built and gated behind a security review before production. Once approved, Spendesk’s platform moves from answering questions to enabling agents to take action.