With Forest Admin MCP Server, give AI agents access to your operations securely

Forest Admin is now an MCP Server.

That sentence is worth sitting with for a moment, right?

Your AI agents, whether they run on Dust, Claude Desktop, a specialized agent provider, or your own internal stack, can now connect directly to your Forest Admin instance. They can read records. Surface operational data. Trigger workflows and actions. All through a standard protocol. All within the permission model and audit trail you already rely on.

Forest Admin has always been where your team goes to do operations, what we call the “backoffice”. But in the agentic era, it needed to evolve. Forest Admin is becoming the secure layer your AI agents can work through: with the right permissions, the right governance, human overight, and no workarounds.

That's a new kind of power. Here's what it looks like in practice.

Why the AI-agent wave needs a new layer to bring in promised efficiency gains

An analyst opens their AI assistant. They ask a question about a customer. The assistant doesn't know: of course, it only has what it was trained on, or what was manually pasted into the conversation. So the analyst switches to the backoffice, pulls the data, copies it back. The AI helps. The human bridges the gap.

That workflow is functional. It's also slow, error-prone, and doesn't scale.

With a MCP Server on top of your backoffice, this changes the architecture and process entirely.

From internal tool to full operational layer for humans and AI

When Forest Admin operates as an MCP Server, it exposes the foundation of your operations: the collections and records from your database, but also your workflows or actions. Your operational context is shared to any AI agent that speaks MCP. Of course, with all the security, and RBAC you have already set in place.

This means an AI agent no longer needs a human to fetch and relay information. It connects directly to Forest Admin. It reads the data it has permission to read. It can trigger the actions its role allows. And every interaction is logged, governed by the permission model already in place.

This is the paradigm shift: it's not the human navigating the backoffice and handing data to the AI. It's the AI agent operating within the backoffice, safely, with the right guardrails. Forest Admin is now a system AI agents can actually interact with.

How the Forest Admin team is using the MCP server

Perhaps the best way to explain this is to tell you how we use it internally.

Internally, we have been using an agent platform called Dust, for a couple of months. It’s connected to our own Forest (which we call FoF, Forest of Forest) through the Forest MCP Server.

Our business team has created a set of Dust agents, like @CustomerOverview, @DealSnapshot, @PipelineSnapshot, that connect directly to our own Forest Admin instance. When a team member needs to understand a customer's situation, they don't open the backoffice, navigate to the record, and copy fields into a chat window. They ask the Dust agent.

The agent queries the Forest Admin MCP Server, retrieves the relevant data (like customer status, recent activity, feature adoption or usage) and surfaces it directly in the conversation or exploits it for an analysis or a summary. Real-time. Structured. No manual bridging.

It's not a proof-of-concept we run for demos. It’s us using our own product as a true operational intelligence layer… We eat our own dog food. It's how our team operates every day.

Here is a quick overview of me calling our Forest instance through MCP with the generic Forest agent.

If you're a CTO or Head of Ops thinking about how to give your internal AI agents genuine operational reach, this is the model.

How Forest MCP becomes the central ops layer at scale for AI

Consider a company running multiple specialized AI agents, even from different vendors: a KYC agent, a fraud investigation agent, a support triage agent. Each operates in its domain, with specific data access and specific capabilities.

Today, connecting each of those agents to the operational system they need means custom development with dedicated endpoints, auth flows, or one-off integrations that need to be maintained as the underlying stack evolves.

With Forest Admin as an MCP Server, the architecture simplifies significantly because Forest acts as the trusted layer between your systems of records and your agentic workforce:

• Each AI agent connects to Forest Admin through MCP

• Access is governed by Forest Admin's permission model (e.g. a KYC agent sees KYC records, not payment data)

• Every action triggered through an agent is logged in Forest Admin's audit trail

• There is one central operational layer; the agents go through it

And this isn't just about convenience. For regulated companies, fintechs, compliance-heavy operations, this architecture matters because governance isn't optional. You need to know which agent accessed which data, when, and with what result. Forest Admin's audit trail provides exactly that, regardless of which AI agent initiated the action.

Access the Forest MCP Server from any MCP client

The Forest Admin MCP Server is live and compatible with any MCP-compatible tool. That means tools your teams are probably already using and agentic platforms you’ve deployed or are planning to adopt this year.

Claude Desktop: connect your Claude Desktop session to a Forest Admin project, and you can query records, read workflow states, and surface operational data directly in conversation — without leaving the Claude interface.

Dust: build agents on Dust that connect to Forest Admin as a data and action source. The @CustomerOverview pattern we use internally for instance is replicable for any team running Dust with an operational need.

OAuth authentication and API bearer tokens are supported, which means connecting to Forest Admin as an MCP Server follows a standard, secure authorization flow.

Setup documentation and a walkthrough guideflow are available to get your first connection running.

The evolution to a full AI operational platform

The current implementation is the foundation. What's being built on top of it extends the model further.

AI Users / service accounts: agents will have their own identities inside Forest Admin, with their own role assignments, their own audit trail, their own permission scopes. An agent is no longer borrowing a human user's session. It has its own governed presence in the system.

Orchestration layer: as agent use cases multiply, the need to coordinate between them grows. Forest Admin's role as the operational hub extends naturally to coordination: which agent can handle which action, in which context, within which governance framework.

Nicolas Devillard, CRO of Forest Admin, sums it best: "Forest is where regulated companies run their operations, the workflows, the rules, the governance, regardless of which suppliers or AI agents they use."

The MCP Server is the first technical brick of that vision.

In Conclusion

Forest Admin has always been the system where operational data and logic lives: who can access and so what, what triggers what, what gets dispatched. The MCP Server opens that system to agents, keeping the governance layer, and standardizing it for AI (no need to rebuild it from scratch every time a new AI tool enters the stack).

Your current and future AI agents get genuine operational reach. Your operations team keeps the control they need. And Forest Admin becomes the layer they all trust, that keeps everything coherent, logged and overseeable.

We have a full series of article on MCP. Give them a read too!
MCP: the standard that lets AI agents take action in your systems

With its MCP Client, Forest Workflows integrates with any tool, without a line of code