What is a Claude MCP server and why does enterprise data need one?
A Claude MCP server is a program that gives Claude a defined set of tools, resources and prompts for one business system through the Model Context Protocol, so the model can query NetSuite or Salesforce without holding credentials or a data export. The host, such as the Claude app, creates one client per server, enforces consent and keeps the whole conversation to itself; each server sees only its own requests.
That boundary is why enterprise data belongs behind an MCP server rather than inside a prompt: the server applies the finance team's access rules and approved definitions before an answer reaches the model. When a controller asks for receivables aged over sixty days in the EMEA subsidiary, the server decides which tool runs, which rows the caller may see and what evidence returns with the number.
How do MCP primitives and transports work with Claude?
A server exposes three primitives: tools the model can call, resources the client can read as context, and prompts the server can template for a user. Tools are model-controlled, which is why the specification says there should always be a human in the loop able to deny an invocation. For enterprise data, tools carry nearly all the value, and the query tool is where governance lives.
Two standard transports carry the messages. The stdio transport runs the server as a subprocess launched by the client, exchanging newline-delimited JSON-RPC over standard streams. Streamable HTTP serves remote clients: one endpoint, each request an HTTP POST, each reply a JSON object or a server-sent event stream scoped to that request. The current revision removed protocol-level sessions and the GET stream. Claude's API connector supports only remote HTTP servers and tool calls; local stdio servers cannot be attached.
Related: See how dotSolved deploys Claude on your enterprise systems
How does OAuth authorization work for a remote MCP server?
For HTTP transports the specification bases authorization on OAuth 2.1: the MCP server acts as a resource server, the client acts as an OAuth client on the user's behalf, and an authorization server issues tokens. The server must publish Protected Resource Metadata (RFC 9728) so the client can discover that authorization server. Clients obtain a client ID through Client ID Metadata Documents or pre-registration; Dynamic Client Registration is deprecated and kept for compatibility.
The flow uses PKCE and resource indicators (RFC 8707), so each token is bound to the canonical URI of one MCP server, and servers must validate that audience on every request. Scopes should start minimal, with the server challenging for more through the WWW-Authenticate header as privileged tools are attempted. Local stdio servers skip this flow and take credentials from the environment. Claude's custom connectors typically use OAuth sign-in, and its API connector accepts a bearer token per server.
Which MCP security practices does the specification call out?
The specification's security guidance covers the confused deputy problem, token passthrough, state handle hijacking and scope minimization. Token passthrough means accepting a token not issued for the server and forwarding it downstream; it is forbidden because it defeats audience validation, hides which client called and turns the server into an exfiltration proxy. The confused deputy attack targets proxy servers that reuse one static client ID with a third-party authorization server; the fix is per-client consent before the redirect, exact redirect URI matching and single-use state values.
Consent belongs to the host; the tools specification asks clients to show which tools the model can reach, confirm sensitive operations and log usage for audit. Because the protocol is now stateless, a server that keeps state across calls mints an explicit handle, and a handle is a name, not a credential: the server must check the caller's authorization on every call. Streamable HTTP servers must validate the Origin header against DNS rebinding, and should bind only to localhost when local and authenticate every connection.
What design rules should an enterprise data MCP server follow?
Start with read-only tools, give each tool one narrow purpose, carry the user's own identity on every call, resolve certified definitions on the server, log every call and return evidence with every answer. Read-only first means query tools ship before any write tool exists; Anthropic's MCP connector documentation recommends denylisting write or destructive tools for a read-only assistant. Narrow scope means open_receivables_by_subsidiary with typed arguments for subsidiary, aging bucket and currency, not a generic run_sql tool that invites improvisation.
Per-user identity means the token names a person and the server applies that person's source-system roles, so a regional controller and the CFO get different rows from the same tool. Certified definitions mean bookings, net revenue and open pipeline resolve to the version finance approved. Logging records who called which tool with which arguments and which rows returned. Evidence means the receivables figure comes back with the SQL that produced it and the aging definition it used, so an auditor can reproduce the number.
Should you use a vendor's MCP server, build your own, or use Nexatron?
Evaluate a vendor server against the six rules above, build only when no vendor meets them, and use Nexatron for governed query tools over its Live connectors without writing a server. For a vendor server, ask which transport it uses, whether tokens are audience-bound to it, whether write tools can be disabled, whether logs export to your SIEM and where definitions live. This site's connector approval checklist adds the organizational controls: a named owner, approved scopes, revocation testing and an incident contact.
Building is right for a system nobody covers, provided your team owns every future specification revision. Nexatron exposes governed query tools to any MCP client, including Claude, ChatGPT and Copilot, and every answer carries the query, the certified metric definition and the row-level policies applied. Live connectors include Oracle Fusion, NetSuite, Salesforce, Sage Intacct, SAP S/4HANA, Microsoft Dynamics 365, Snowflake, Databricks and PostgreSQL. For Oracle E-Business Suite, dotSolved's services team implements and supports the application itself. Book a Demo to see the evidence trail on your own data.