Every AI tool an engineer installs wants its own connection into your systems. Across a company that turns into a set of connectors nobody can review, rotate or revoke as a group. The Model Context Protocol (MCP) gives AI tools and internal systems one shared way to expose tools and data under the identity you already run.
MCP is an open-source standard for connecting AI applications to external systems: data sources, tools and workflows (MCP introduction). Anthropic published it on 25 November 2024 with a public specification, SDKs and example servers, to replace one-off custom integrations (Anthropic announcement).
This article is for IT, security and digital leaders who approve AI tools, tokens and agent access to production systems. It covers what an MCP server is, what an open standard changes about integration cost, which security questions stay with you, and how PetroBench runs one.
An MCP server
An MCP server exposes capabilities to an AI application. Those capabilities are tools (operations with schemas), resources (readable context) and prompts (guided workflows). The model proposes a call. The server runs it with the credentials and policy attached to that call, then returns a result the model uses on the next turn.
Risk review follows that split. The questions are which servers are allowed in corporate AI tools, which tools each server publishes, and which principal those tools run as.
MCP sits beside your identity stack and your APIs. It standardizes how an approved AI tool reaches a system of record. Model choice, SSO and data classification stay company decisions.
Servers come in two deployment shapes. Local servers run on a workstation and suit demos. Remote hosted servers sit next to the system of record and put network controls, token policy and audit in one place. Enterprise standards usually require remote servers for anything that touches production data.
Host, client and server
The protocol names three roles. Using the same vocabulary in architecture reviews keeps teams from talking past each other.
Host. The application the person uses: Claude, ChatGPT, Gemini, Grok or any other MCP-compatible tool. The host owns the UI, the model connection and the consent prompts the user sees.
Client. The connector inside the host that speaks MCP to one or more servers. People usually say "Claude" or "ChatGPT" and mean host plus client together.
Server. The process or remote endpoint that offers tools, resources and prompts. Programs that protect production data prefer centrally managed remote servers over binaries installed per laptop.
The MCP specification defines how hosts, clients and servers share context and expose tools, so an AI application can compose a workflow without a custom adapter per data source. Role and message flow detail is in the architecture documentation.
For IT the operating model is short: keep an allowlist of hosts, keep an allowlist of servers, and bind both to identity and logging. "MCP enabled" without those two lists is incomplete.
This maps onto how you already handle applications and APIs. The host is a client application. The MCP server is an API-shaped surface built for agent tool calls. Several hosts speak the same protocol, so a change of preferred chat tool doesn't mean rewriting adapters.
The economics of an open protocol
Before a shared standard, each AI product invented its own plugin format, and integration cost scaled as the number of hosts times the number of systems. Anthropic described the failure mode at launch: capable models stay isolated behind silos, and every new data source needs its own implementation (Anthropic announcement).
An open standard changes that in concrete ways:
- One server implementation serves every approved host.
- Hosts compete on product quality while speaking the same tool protocol.
- Procurement can require MCP without locking the company to one chat tool.
- Security review targets a known shape (tools, resources, authorization), so one checklist covers every connection.
"Open" means the interface is shared and inspectable. Access policy, scopes and revocation still belong to your organization.
Provider-specific function calling stays useful inside one model API. MCP sits one layer above it as a portable way to expose tools across hosts. Most stacks will use both: function schemas for a single provider, and MCP when the same capabilities have to reach Claude, ChatGPT and an internal host without three separate adapters.
MCP next to APIs and warehouses
MCP complements warehouse sync and REST programs. Batch export, scheduled jobs and human login stay on the paths you already trust. MCP covers interactive tool use from an AI tool that needs live operations mid-conversation.
A visible tool is still only as safe as its design. A server that exposes destructive actions behind a long-lived shared secret is a poor design regardless of protocol. MCP makes the tool list inspectable; engineering judgment decides what ships.
MCP also leaves model selection alone. Your company chooses which models may run inside approved tools. MCP governs how those tools reach systems of record after that choice is made.
Identity and security questions for IT
The MCP documentation covers protecting servers so only permitted principals reach sensitive operations, including OAuth-style authorization servers and enterprise-managed authorization (authorization tutorial). Interoperability writeups make the same point about centralized authorization, so corporate credentials and policy travel with the call (AWS Open Source on MCP authentication).
Security research on MCP points at token handling, scope design and the host-server boundary as the places where programs fail in practice (Hasan et al., 2025). Agents with tools are capable. Broad, long-lived tokens are the usual failure.
Use this checklist on any MCP server under review:
- Identity. Is each call tied to a user, a service principal or both, and how does that map onto the SSO (SAML/OIDC), SCIM and RBAC you already operate?
- Least privilege. Can you scope tools per token and review the list before rollout?
- Token lifecycle. Expiry, rotation and revocation on a known clock.
- Server allowlist. Which MCP servers may engineers attach, and who approves additions?
- Audit. Can you show who ran which tool against which resource, and when?
- Data path. Where do prompts and tool results land under the host vendor's terms? That review sits beside the server's own controls.
Supply chain belongs on the same list. Community MCP servers are unreviewed code with access to your data. Prefer first-party or contractually reviewed servers for wells, financials or PII, and put "no arbitrary MCP URLs in host configuration" in the standard the same way you constrain OAuth app sprawl.
If a vendor can't answer the checklist in writing, pause the rollout.
MCP on PetroBench
PetroBench is a cloud platform for rod lift engineering. Engineers design and simulate in the browser with RodSim, compare designs side by side, and keep version history and an audit trail on every well. The same platform exposes the PetroBench API and a hosted PetroBench MCP server, so agents reach the same wells, simulations and permission model.
Tools such as find-wells, get-simulation and run-simulation follow the same abilities as the API and the browser. An agent operates inside the organization boundary on the live system of record, and a token can't do more than the user who owns it.
That claim is testable in a security review. Platform identity includes SSO (SAML/OIDC), SCIM, RBAC and MFA. Data controls include AES-256 at rest, TLS 1.2 or higher in transit, and audit logs. Detail is published at docs.petrobench.com/trust.
Three surfaces share one engine:
- Browser. Interactive engineering work and review.
- PetroBench API. Scheduled jobs, warehouse paths (Snowflake, Databricks and related integrations), internal apps, and webhooks with retention and replay.
- PetroBench MCP server. Agents inside approved tools such as Claude or ChatGPT that need live tools during a conversation.
A review scenario: an engineer in an approved tool asks an agent to find a well and summarize the latest simulation. The tools resolve against the organization the token can see, and the same well in the browser should match. If the agent can see another organization's wells, identity failed. If the agent can do something the token doesn't grant, scope failed.
MCP is optional for teams that work only in the browser and the API. It matters once the agent program is real and you want agents on the same wells and simulations people already trust. The product pages are petrobench.com/mcp and petrobench.com/api.
Questions before approving a rollout
- Which hosts are in scope, and who owns host configuration?
- Which servers are approved, and where do tokens live?
- What default scopes apply to a person versus a service account?
- How are write tools scoped separately from reads?
- How is access revoked within an hour?
- How do you prove the agent saw the same record a person sees in the system of record?
- What is the process for adding a new MCP server without host configuration becoming shadow IT?
These questions apply to any tool-calling program. MCP lets you ask them in one shape across every host.
Our position
Our bet is that MCP becomes the default way approved AI tools reach systems of record, and that the winning setup is one hosted server per platform, reviewed once and reused across every host. Keep identity and scopes with the people who already run SSO and the API program. A platform that exposes MCP on the same engine and permissions as its browser and REST API fits that model; a private store behind an opaque token doesn't.