Model Context Protocol for enterprise agents: what CFOs and CIOs need to know

Model Context Protocol (MCP) is an open standard that lets an AI agent discover and call tools, read data sources, and use prompts exposed by any system that implements the protocol, through one common interface instead of a custom integration per system. For a CFO or CIO, MCP matters because it turns "which agents can touch which systems" from a per-vendor negotiation into a question of configuration, and that configuration can be governed, logged, and audited centrally.

MCP in plain terms

Think of MCP as a standard socket between agents and the systems they work on. Before a standard existed, every agent vendor wrote its own connector to every enterprise system, and every connector carried its own credentials, permissions, and logging. MCP separates the two sides. A system, or a thin service in front of it, runs an MCP server that publishes what it offers. An agent runs an MCP client that discovers those offerings and calls them. The two sides agree on message formats, so any compliant agent can work with any compliant server.

MCP was published as an open standard in November 2024 and has since moved to open, vendor-neutral governance. As of September 2026 it is the most widely implemented protocol for agent tool access, supported by the major model providers and by a large and growing set of enterprise software vendors.

What an MCP server exposes

An MCP server exposes three kinds of things:

• Tools: operations the agent can invoke, each with a name, a description, and a typed input schema, such as "get_employee_leave_balance" or "create_journal_entry_draft."
• Resources: data the agent can read, addressed by URI, such as a policy document or a reconciliation worksheet.
• Prompts: reusable instruction templates the server offers for common tasks.

The agent never receives a database connection string or an API key for the underlying system. It receives a list of tools it may call, and each call is a discrete, typed, loggable event.

Why this matters for HR and finance

HR and finance systems are exactly the systems where uncontrolled agent access is unacceptable. MCP's design has three properties that map directly onto financial controls.

1. Typed, enumerable operations. Because tools are declared with schemas, you can list every operation an agent can perform against the HR core or the ledger, review the list, and approve it. There is no "and anything else the API allows."
2. Discrete calls. Each tool call is a separate message with inputs and outputs, which is the granularity an audit trail needs. Compare this with an agent operating a browser session, where the unit of work is a click.
3. Server-side authority. The MCP server, not the agent, decides what a tool does and under whose identity. A "post_journal_entry" tool can be implemented to create a draft requiring approval, and the agent cannot bypass that by calling the ledger directly, because it has no direct route.

Tool permissions: the part to get right

A tool permission is a grant that allows a specific agent identity to call a specific tool, optionally constrained by parameters such as cost center, legal entity, or record type. MCP defines how tools are described and called; it does not, by itself, decide who may call what. That decision belongs to your platform, and it is the single most important design choice in an enterprise MCP deployment.

A five-layer permission model

The recommended model has five layers:

Notice that four layers exist in the system of record and the Gateway, and one exists in the underlying system. Defense in depth is deliberate. Even if an agent were granted a tool in error, the underlying system's security model still applies to the agent's identity.

The gateway pattern

The gateway pattern places a single, governed MCP endpoint between all agents and all MCP servers, rather than letting agents connect to servers directly. Meridian's Gateway implements this pattern. Every third-party or customer-built agent connects to the Gateway, and the Gateway connects to the enterprise's MCP servers, whether those are Meridian-provided, vendor-provided, or built in-house.

The gateway pattern delivers five things that point-to-point connections cannot:

• One place to enforce Registry scope and approval tiers for agents from any vendor.
• One place to authenticate agents with IdP-issued identities and rotate credentials.
• One place to capture every tool call for the audit trail.
• One place to rate-limit and cap consumption per agent.
• One place to turn an agent off. Suspend it in Registry, and the Gateway stops forwarding its calls.

The alternative, direct connections from each agent to each server, recreates the integration sprawl MCP was meant to remove, with each connection carrying its own credentials and none of them visible to audit.

Observability with OpenTelemetry

OpenTelemetry (OTel) is the open standard for traces, metrics, and logs that most enterprise observability stacks already ingest. A trace is a record of one end-to-end operation broken into spans, each span covering one step with its timing, inputs, outputs, and status. Applying OTel to agents means every agent run becomes a trace, and every model call, tool call, approval wait, and retry becomes a span.

Meridian's Gateway emits OTel traces for every agent run, using the emerging OpenTelemetry semantic conventions for generative AI so that agent spans carry consistent attributes for model, tokens, tool name, and outcome. Because it is standard OTel, the data flows into the observability platform your IT team already runs. What this gives a CIO and CFO:

• Latency and error rates per agent and per tool, which is how you find the flaky integration before users do.
• Cost per completed outcome, by joining spans to credit consumption.
• A forensic record. When an approver asks why the Payroll Agent flagged a pay group, the trace shows the exact tool calls and data that led to the flag.
• Alerting on behavior change. A jump in tool calls per run after a model upgrade is a signal worth investigating before it becomes a bill.

Questions for your architecture and vendor reviews

1. Does the vendor's agent platform expose and consume tools through MCP, or through a proprietary connector framework? Proprietary frameworks lock the governance to the vendor.
2. Where are tool permissions enforced, and can we export the effective permissions per agent?
3. Is there a single gateway through which all agents, including third-party ones, reach our systems?
4. Are agent runs emitted as OpenTelemetry traces we can ingest into our own stack?
5. How does an agent authenticate to an MCP server: with an IdP-issued identity we control, or with a shared secret?
6. When we suspend an agent, how quickly do its tool calls stop, and where is that demonstrated?

The practical takeaway

MCP does not make agents safe. It makes agent access legible, which is the precondition for making it safe. Combine MCP for tool access, a gateway that enforces registry scope and approval tiers, IdP identities for agents, and OpenTelemetry for observability, and you have an agent architecture that a finance controller and an IT auditor can both read. That combination, more than any single model choice, is what determines whether agents can be trusted with the ledger and the HR core.