Why Your Business SaaS Needs an MCP Server (and What Happens When It Has One)

MCP (Model Context Protocol) is everywhere right now, but most of the conversation is about developer tools: code editors, documentation servers, GitHub integrations. There is a use case nobody is talking about enough: connecting AI assistants to the operational data that actually runs a business.

I work at Enlivy, a commercial operations platform for service businesses. We recently shipped an MCP server that lets Claude, ChatGPT, and other AI assistants read and act on business data: invoices, contracts, proposals, bank transactions, and client records. This post is about what we learned, why it matters, and what it looks like in practice.

The problem with business data silos

Service businesses (agencies, consultancies, freelancers) generate a lot of structured data: invoices with line items, contracts with signing status, proposals with acceptance timestamps, bank transactions matched to their corresponding invoices.

This data sits in a dashboard. When someone asks "how much did client X pay us in Q2?" or "which contracts expire this month?", a human has to log in, navigate, filter, and export. An AI assistant could answer these questions instantly, if it had access to the data.

That is where MCP comes in.

What MCP actually does here

MCP gives an AI assistant a structured way to discover and call tools on your server. Instead of the assistant guessing what your API looks like, it asks the MCP server "what can you do?" and gets back a typed list of tools with input schemas and descriptions.

For a business operations platform, this means the assistant can:

• Look up a client's open invoices and total outstanding balance
• Check which contracts are pending signature
• List proposals sent this month and their acceptance status
• Pull bank transaction data for reconciliation questions
• Create a draft invoice from a conversation

The key difference from a regular REST API: the AI discovers the tools at runtime. You do not write integration code per model. One MCP server works with Claude Desktop, ChatGPT, Cursor, or any MCP-compatible client.

What the architecture looks like

The pattern is simple:

AI Assistant (Claude, ChatGPT)
        │
        ▼
   MCP Client
        │
        ▼
   MCP Server (your app)
        │
        ▼
   REST API / Database

The MCP server is a thin layer that translates between the MCP protocol and your existing API. If you already have a REST API (which you should), the MCP server mostly wraps existing endpoints with typed schemas and human-readable descriptions.

In our case, Enlivy is API-first: every action in the dashboard has a corresponding REST endpoint. The MCP server wraps a subset of these endpoints, the ones that make sense for an AI to use.

What we did NOT expose

This is the part most MCP tutorials skip. Not every endpoint should be an MCP tool.

We deliberately left out:

• Destructive operations without confirmation. An AI should not be able to delete a signed contract in one step. Anything destructive goes through a draft/confirm pattern or is simply not exposed.
• Bulk operations. Letting an AI loop through hundreds of invoices and modify them is a recipe for expensive mistakes.
• Authentication management. User roles, permissions, and API keys stay in the dashboard.

The general rule: if a human would want to review the result before committing, the MCP tool should create a draft, not a final record.

What surprised us

People use it for reporting, not automation. We expected users to create invoices through Claude. Instead, most MCP usage is read-heavy: "what's my outstanding revenue?", "which proposals are still pending?", "show me all invoices for this client." The AI becomes a conversational reporting layer on top of the operational data.

Tool descriptions matter more than schemas. The LLM decides which tool to call based on the description, not just the input schema. A vague description like "get invoices" performs worse than "retrieve a list of invoices for a specific client, filtered by status (draft, sent, paid, overdue) and date range." We rewrote every tool description three times before they worked reliably.

Token efficiency matters. Early versions returned full invoice objects with every field. LLMs choke on that. We trimmed responses to essential fields and added a separate "get invoice detail" tool for when the assistant needs the full record. Fewer tokens, better reasoning.

How to add MCP to your own SaaS

If your product has a REST API, adding MCP is straightforward:

1. Pick 10-15 endpoints that make sense for conversational use. Start with read operations.
2. Write clear tool descriptions. Think of them as instructions for a new employee who has never seen your product.
3. Trim response payloads. Return only what the LLM needs to answer the question. Add a detail endpoint for full records.
4. Add a draft pattern for any write operation. The AI creates a draft; the human confirms.
5. Test with real questions, not unit tests. Ask Claude "what invoices are overdue?" and see if it picks the right tool with the right parameters.

The MCP SDK (Python or TypeScript) handles the protocol. You write the tool handlers. For a product with an existing REST API, the initial implementation is a few days of work, not weeks.

The bigger picture

EU e-invoicing mandates (PEPPOL, ANAF eFactura in Romania) are making structured invoice data the norm, not the exception. When every invoice is machine-readable by regulation, connecting that data to an AI assistant becomes trivially useful.

At Enlivy we handle the full flow from proposal to paid invoice to bank reconciliation, with e-invoicing built in. Adding MCP was the natural next step: all that structured data was already there, it just needed an interface that AI assistants could use.

If you are building a B2B SaaS with financial or operational data, your users are going to ask for this. Better to ship it before they ask.

---

Enlivy is an API-first commercial operations platform for service businesses. It connects proposals, contracts, invoicing, payments, and bank reconciliation in one system, with EU e-invoicing through PEPPOL and ANAF eFactura built in. Free plan available, no card required.