Build on Frihet's MCP Server: A Developer's 2026 Guide

Most posts about Frihet’s MCP server explain that it exists. This one is for the people who want to build on it: developers, AI engineers, and founders wiring agents into their stack. If you have searched for an honest answer on MCP server ERP developer integration, this is the missing how-to — config, auth, a first working workflow, and the agentic patterns that earn their keep. Real tool counts, real endpoints, real config blocks you can paste.

What an MCP server is — and why a business platform exposing one matters

MCP (Model Context Protocol) is an open standard from Anthropic. It defines a common way for an AI assistant to discover and call external tools. If your agent speaks MCP and a system speaks MCP, they can work together with no bespoke glue code.

That standardization is the point. Before MCP, every “connect the AI to my business data” project meant a custom integration: hand-rolled function definitions, an auth layer, response parsing, and maintenance every time the API moved. MCP collapses that into a protocol the agent already understands.

A business platform exposes consequential records: invoices, expenses, clients, and reporting data. MCP gives a compatible client a documented way to request operations against those records, but the protocol does not remove authorization, validation, or review. Treat every write as an explicit user action and inspect the result before it becomes part of an operational or fiscal process.

Frihet’s public MCP catalog complements its developer API. The useful question is not whether an agent can run the business on its own, but whether a client can call a documented operation with scoped credentials, predictable input, structured output, and a clear approval boundary. That is also the practical thesis behind our developer-first ERP API guide.

Frihet’s MCP server: 157 tools for your agent

The current server (v1.16.6, verified on 28 August 2026) exposes 157 tools grouped across tool categories, plus 11 resources and 10 guided prompts. It is published on npm as @frihet/mcp-server, available as a remote endpoint at mcp.frihet.io/mcp, and MIT-licensed — read the source, fork it, audit it.

The tool categories map onto Frihet itself: invoices (create, send, credit notes, late fees, deposits, e-invoice XML export), expenses, clients & CRM (pipeline stages, profitability, health scoring), products & quotes (including quote-to-invoice conversion), banking, fiscal models (Modelo 303, 130, 390, 180, 347), compliance (VeriFactu, TicketBAI), the Stay and POS verticals, plus time entries, recurring invoices, and webhooks.

Two MCP concepts are worth understanding before you build, because they change how an agent behaves:

• Resources are read-only reference data a client can request, such as published tax context and API schema information. They are context for a user-reviewed workflow, not a substitute for validating the applicable tax treatment.
• Prompts are guided multi-step workflows. Instead of improvising a sequence, a prompt like monthly-close walks the agent through the steps in order. We covered these when v1.2 added resources, prompts, and structured output — and structured output is the unsung hero: every tool returns a defined schema, so responses are deterministically parseable instead of free text you have to regex.

Connecting Claude Desktop, Cursor, and custom agents

The whole point of MCP is that connection is configuration, not code. Here is the walkthrough for the three most common cases.

Claude Desktop

Open your claude_desktop_config.json and add Frihet under mcpServers:

{
  "mcpServers": {
    "frihet": {
      "command": "npx",
      "args": ["-y", "@frihet/mcp-server"],
      "env": {
        "FRIHET_API_KEY": "fri_<your_key>"
      }
    }
  }
}

Restart Claude Desktop. The 157 tools, 11 resources, and 10 prompts appear automatically. The server runs as a local subprocess over stdio — nothing is exposed to the network.

Cursor

Cursor reads mcp config from ~/.cursor/mcp.json (or the project-level .cursor/mcp.json). Same shape:

{
  "mcpServers": {
    "frihet": {
      "command": "npx",
      "args": ["-y", "@frihet/mcp-server"],
      "env": { "FRIHET_API_KEY": "fri_<your_key>" }
    }
  }
}

Now you can prompt Cursor’s agent to manage real business data while you code — useful when you are building an integration and want to test against your own account.

Custom agents and hosted clients

If you are building your own agent (Python, TypeScript, anything with an MCP client library) or running a hosted assistant, use the remote endpoint instead of spawning a subprocess:

https://mcp.frihet.io/mcp

Point your MCP client at that URL and pass your API key as a Bearer token (Authorization: Bearer fri_<your_key>). The same 157 tools are available over the network. This is the path for server-side agents, CI bots, and any environment where launching npx per session isn’t practical. Clients that support OAuth — Claude Desktop, Smithery, and others — can instead authenticate against the same endpoint via the OAuth 2.1 + PKCE browser flow, with no API key to manage. Note the path: the MCP endpoint is mcp.frihet.io/mcp, not the bare host.

The takeaway: whether your client is a desktop app, an IDE, or your own code, the integration surface is identical — a server name, a command or URL, and one secret.

Authentication, scopes, and keeping client data secure

For direct and npm usage there is one credential: your Frihet API key (it starts with fri_), generated in Settings → API. The hosted remote endpoint adds a second option — a first-class OAuth 2.1 + PKCE browser flow — so clients that support OAuth (Claude Desktop, Smithery) can log in without handling a key at all. A few principles:

The credential is part of the boundary. Use the documented API-key or OAuth 2.1 + PKCE flow supported by your client, protect the resulting credential, and verify its scope. Authentication does not replace authorization checks, data-handling review, or approval of consequential writes.

Scope per agent. Running a monthly-close bot and a dunning bot? Issue a separate key for each. You can revoke one without disrupting the other, and your audit trail tells you which agent did what. Least privilege is cheap here.

Keys live in env vars, never in code. Every config block above reads FRIHET_API_KEY from env, not a hardcoded string in a committed file. Follow the current Settings and security documentation to create, rotate, and revoke credentials; revoke a credential promptly if its environment may be compromised.

The MCP server doesn’t change your security model. It makes Frihet a well-scoped interface behind your key.

Building your first workflow: “create an invoice from this email”

Here is a controlled example of the calls a connected client can propose.

You receive an email:

“Hi — please invoice us €2,500 for the January consulting engagement. Our company is Acme Ltd, VAT ESB12345678, [email protected]. Net 30.”

Paste it into your connected client with: “Prepare the fields for a Frihet invoice from this email and ask me to confirm before creating it.”

The client can then walk through a bounded sequence:

1. Reads the frihet://tax/rates resource as reference context, while leaving the applicable tax treatment for review.
2. Calls client lookup to check whether Acme Ltd exists and presents any proposed new client fields for confirmation.
3. Prepares the invoice inputs — line item, tax, payment terms, and numbering series — and waits for user confirmation before the create call.
4. Returns the result in structured output — number, total, due date, and status — for a final check before any separate send action.

The client can reduce re-keying while keeping the important checkpoints visible. The user still verifies identity, tax treatment, amounts, terms, and the resulting record before moving to a separate send action.

This is a useful MCP pattern: interpret an unstructured request, call narrowly scoped tools, show structured output, and stop at an approval boundary.

Controlled patterns: monthly close, dunning, and expense triage

The interesting work is often a sequence of explicit calls. These three patterns remain useful when each consequential step is initiated and reviewed by a user:

Monthly close

Start the monthly-close prompt to assemble a review list: unpaid invoices, overdue items, expense records that need attention, and imported bank-statement transactions that still need matching. Frihet’s live banking boundary is user-initiated statement import in OFX, MT940, CAMT.053, or CSV; direct Open Banking connections, PSD2 feeds, and continuous bank sync are not available. Review and confirm each categorization or match before treating the close as complete.

Dunning

Ask the agent: “Who owes me money, and how overdue?” It queries invoices, buckets them by aging (1-30 / 31-60 / 61-90 / 90+), and drafts a reminder per debtor with the right tone for each bucket. You review and approve — the agent never sends money-touching messages to third parties without your sign-off. But the “who do I chase and what do I say” overhead is gone. Pair it with our six-step guide to collecting from late payers for the templates.

Expense triage

Capture receipts through Frihet’s app or inbound-email OCR first, then let the agent categorize the resulting expense data and flag anything off — a duplicate, a wrong VAT rate, or an expense that should be billable to a client. The MCP interface works with structured records; it does not accept receipt images or file uploads.

The examples in this guide are initiated from your MCP client. They do not describe a background Frihet agent or promise an included run quota. Check the current documentation and pricing source for availability, permissions, and usage limits before designing a production workflow.

If an external orchestrator starts these calls, keep authentication scoped and add explicit approval steps before creating, sending, matching, or filing anything. The same controls apply to the patterns in our Frihet, Claude, and n8n guide.

API + MCP together: when to call which

Frihet gives you two doors into the same building. Knowing which to use is most of the architecture decision.

Reach for the MCP server when:

• An MCP client is the caller, and the input is natural language or unstructured text such as an email body or chat request.
• You want guided workflows (the prompts) and free tax context (the resources).
• You are prototyping fast and don’t want to write API plumbing.

Reach for the REST API at api.frihet.io/v1 when:

• Your code is the caller and you control the exact inputs.
• You need deterministic, high-volume, repeatable automation, or you are integrating from a platform without an MCP client.
• You are building a product surface, not an agent.

The REST API ships an OpenAPI 3.1 spec at /openapi.yaml, API-key auth, cursor pagination, field selection, and action endpoints for e-invoice XML, credit notes, and late fees. There is also an official TypeScript SDK (@frihet/sdk) and a CLI (frihet) for typed clients or terminal scripting.

You can use both published contracts in one reviewed workflow. A common shape is for an MCP client to structure an email request and present proposed inputs, while deterministic application code performs a separately authorized REST call. Choose the interface by input and control requirements, not by an assumption that an agent can act without review.

Wrapping up

An MCP server is useful when its public catalog, authentication, inputs, outputs, and approval boundaries are clear. Frihet publishes the manifest-backed MCP package and remote endpoint for compatible clients. Connecting is configuration; using it safely means scoped credentials, explicit user initiation, structured results, and review before consequential writes.

After checking the current authentication documentation, connect a client and ask it to prepare invoice fields from an example email. Inspect the proposed client, tax, amounts, terms, and numbering before you authorize the create call.