Model Context Protocol

ONE-SENTENCE DEFINITION

Model Context Protocol (MCP) is an open protocol that standardizes how AI applications connect to external tools, data resources, and reusable prompts through a host–client–server architecture.

MCP should be treated as an enterprise integration and governance pattern—not merely a developer convenience. A carrier should adopt it only within a clearly defined trust architecture that preserves system-of-record controls, separates read from write access, limits data scope, and makes consequential actions reviewable and auditable.

Insurance AI initiatives frequently begin with a narrow assistant connected to one document repository or one operational system. As use cases expand, carriers face a recurring integration problem: every AI experience needs a reliable way to discover available capabilities, retrieve context, invoke tools, and return results while respecting enterprise controls. Point-to-point integrations can work, but they become expensive and inconsistent when each application implements its own connector patterns, security assumptions, schemas, and error handling.

Model Context Protocol addresses part of that problem by defining a common protocol between AI applications and external capability providers. In the MCP architecture, the host is the AI-enabled application. It creates clients that communicate with MCP servers. Servers can expose tools, resources, and prompts. A tool can query a claim, retrieve policy details, calculate a value, create a draft, or initiate a governed workflow. A resource can provide controlled context such as a policy form, claim note, underwriting guideline, or model documentation. A prompt can package a reusable interaction pattern.

For insurers, MCP is most valuable when it provides a controlled façade over existing enterprise services. It can make capabilities easier for approved AI applications to discover and use without giving the model direct, unrestricted access to databases or core platforms. A claims assistant might use one MCP server for claim-system queries, another for document retrieval, and another for analytics. An underwriting assistant could retrieve submission data, appetite rules, prior-loss context, and referral guidance through separately governed servers.

MCP does not eliminate the need for integration engineering. Existing APIs still need to be reliable. Identity still needs to flow correctly. Data entitlements still need to be enforced. Tool schemas must be carefully designed. Business actions must be validated. Observability, testing, model governance, privacy, and incident response remain essential. The protocol standardizes communication; the carrier remains responsible for the safety and correctness of the connected system.

The recommended insurance operating model is progressive. Begin with low-risk, read-only tools. Add narrowly scoped drafting and analysis capabilities. Introduce write actions only after authorization, approval, idempotency, rollback, and audit controls are proven. Preserve professional accountability: the AI may gather, organize, explain, and recommend, but authorized insurance professionals remain responsible for claim, underwriting, coverage, payment, and customer decisions.

Executive Definition

MCP is a standardized way for approved AI applications to use enterprise information and capabilities through governed connections rather than bespoke integrations for every use case.

MCP is an open, JSON-RPC-based protocol for stateful or protocol-defined exchanges between hosts, clients, and servers. Servers expose primitives such as tools, resources, and prompts; clients and servers negotiate supported capabilities during initialization and communicate over defined transports such as standard input/output or Streamable HTTP.

In P&C insurance, MCP is a potential integration layer through which AI assistants and agents can retrieve claim, policy, submission, document, and analytics context—or invoke tightly controlled workflow actions—while the carrier enforces identity, authorization, data access, business rules, approvals, and auditability.

The Enterprise Integration Problem

A typical insurer operates multiple systems of record, document repositories, data platforms, analytical services, portals, and third-party products. AI experiences often need context from several of them at once. Without a standard interaction pattern, every use case may require custom discovery, authentication, schema mapping, invocation logic, and response handling.

VALUE

MCP adds value when several AI experiences need consistent, governed access to the same enterprise capabilities, or when a carrier wants a reusable tool and resource layer across claims, underwriting, service, and operations.

LIMIT

MCP adds little value when a use case is simple, static, and already served well by one direct integration. It should not be adopted merely because it is fashionable.

Core Components

An insurance professional asks the host application a question or requests an action.

The host interprets the request and determines which approved server capability may be relevant.

The client discovers or invokes the tool, resource, or prompt through the MCP connection.

The server authenticates and authorizes the request, validates inputs, and calls the underlying enterprise service.

The server returns structured results, errors, evidence, or resource links.

The host presents the result, requests approval when required, and records the interaction for audit and monitoring.

MCP connections begin with initialization and protocol-version negotiation. Clients and servers declare supported capabilities. During operation, they exchange requests, responses, notifications, and utility messages. Controlled shutdown, timeouts, cancellation, and error handling are part of a production implementation. Insurers should record negotiated versions and server capabilities because behavior may differ by version and deployment.

DESIGN PRINCIPLE

Each server should have a focused responsibility and a clear trust boundary. A broad “enterprise everything” server is easier to build initially but harder to secure, test, explain, and govern.

Tools

Tools are executable functions exposed to the AI application. They may retrieve information, perform calculations, call an API, or initiate a workflow. Tool descriptions and input schemas help the model determine when and how to use them, but tool descriptions must not be treated as a substitute for authorization or server-side validation.

Resources provide contextual data or content. Examples include a policy form, a claim document, a guideline, a data dictionary, or model documentation. Resource access should be filtered by user identity, claim or policy entitlement, jurisdiction, business purpose, and retention rules. Returning a URI or resource link can be preferable to copying sensitive content into every message.

Prompts are reusable templates or interaction patterns. In insurance, prompts can standardize a claim-file review, underwriting submission summary, reserve discussion, litigation referral, or management briefing. Prompt governance should include ownership, versioning, testing, approved data sources, prohibited outputs, and review requirements.

MCP specifications also define client-side capabilities such as model sampling, user elicitation, and boundary information. These features can be useful, but they expand the trust relationship. Carriers should enable only the capabilities required for the use case and should clearly control what prompts, data, and results a server can access.

The protocol should never become an alternate source of truth. Claim, policy, billing, and underwriting systems remain authoritative. MCP servers should return the system source, retrieval time, record identifiers, and relevant version information so that users can verify results and reconcile discrepancies.

A claims manager asks an AI workbench to identify material developments across a portfolio of open bodily injury claims. The host connects to several MCP servers: a claim-system server, a document-intelligence server, a predictive-analytics server, and a litigation-information server.

The claim server returns current reserves, exposures, assignments, dates, and recent activity. The document server returns extracted facts from medical reports, demand packages, and correspondence. The analytics server returns severity and litigation indicators with model version, confidence, and explanation. The litigation server returns attorney involvement and upcoming deadlines.

The host assembles a review package that identifies a new surgery recommendation, recent attorney representation, a demand amount, a coverage issue, and a reserve that may no longer reflect the exposure. It links every finding to source evidence. The system recommends management review but does not change the reserve or send a communication.

The claims manager reviews the evidence, consults the adjuster, determines the appropriate action, and documents the decision. Tool calls, returned evidence, model outputs, and the final human decision are retained for audit and performance analysis.

KEY CONTROL

The server can surface a potential reserve mismatch, but only an authorized insurance professional should establish or change the reserve. The workflow must distinguish analysis, recommendation, approval, and system-of-record action.

An underwriter receives a submission containing applications, schedules, statements of values, prior-loss reports, photographs, inspection material, and broker correspondence. The AI host uses an MCP document server to classify and extract information, a policy-system server to retrieve account history, a catastrophe server to obtain hazard context, and an underwriting-guideline server to retrieve current appetite and referral rules.

The host identifies missing roof-age information, a discrepancy in total insured value, a concentration concern, and a loss trend requiring review. It prepares a sourced risk summary and a referral package. Each tool returns provenance, timestamp, and data-quality indicators.

The underwriter validates the information, contacts the broker for missing data, assesses risk quality, and determines terms. The AI reduces search and preparation effort but does not independently select risk, set price, or bind coverage.

Pattern 1: Read-Only Context Layer

Servers expose narrowly scoped read tools and resources. This is the recommended starting pattern because it limits operational risk while proving identity propagation, data filtering, logging, latency, and usefulness.

Tools create tasks, route referrals, request documents, or initiate existing workflows. The server validates allowed transitions and returns a workflow identifier. The AI does not directly manipulate core tables or bypass business services.

Servers expose predictive, rules, optimization, or document-intelligence services with standardized inputs and outputs. Responses include model or rules version, explanation, confidence, limitations, and monitoring metadata.

Claims, policy, underwriting, documents, analytics, and enterprise knowledge are separated into domain servers. This supports distinct ownership, release cadence, entitlement models, and risk classifications.

An MCP server provides an AI-facing interface over existing APIs, message services, batch processes, or—only where necessary—controlled UI automation. The underlying legacy system remains unchanged while the carrier modernizes access incrementally.

Core Security Principles

Required Governance Artifacts

GOVERNANCE RULE

The protocol’s technical ability to expose a tool does not create business authority to use it. Authority must come from the insurer’s policies, role design, delegated limits, and approved workflow.

Do not evaluate MCP only as infrastructure. Evaluate the entire workflow: whether the right information was obtained, whether the user understood the evidence, whether unauthorized activity was prevented, whether the professional decision improved, and whether the business outcome justified the complexity.

Start with read-only access

Prove identity, entitlements, relevance, latency, and logging before exposing write operations.

Prefer get_claim_summary or create_underwriting_referral over generic database-query tools.

The model may suggest a tool call, but the server must determine whether it is allowed.

Include record identifiers, timestamps, source systems, model versions, and links.

Use different tools, permissions, and approval steps for recommendations and system changes.

Assume systems will time out, return partial data, change schemas, or become unavailable.

Track protocol, server, tool, schema, prompt, model, and policy versions.

Make review expectations visible and preserve the professional’s rationale and decision.

Only approved servers should be available in production; ownership and risk tier must be clear.

Usage volume is not success. Measure quality, safety, time, cost, and insurance results.

MCP May Be a Good Fit When…

Insurance value does not come from connecting a language model to more systems. It comes from connecting professionals to better information, earlier insight, reliable evidence, and governed workflow actions. MCP can support that objective when it is used as part of a broader claims and underwriting intelligence architecture.

For claims, a governed protocol layer can help an AI workbench retrieve current claim facts, analyze new documents, surface severity or litigation signals, explain the evidence, and prepare a review package. For underwriting, it can help organize submissions, validate data, retrieve appetite guidance, add portfolio context, and prepare referrals. In both cases, the professional remains responsible for the decision.

Charlee.ai’s responsible-AI position is that purpose, data, model output, explanation, source evidence, professional review, decision documentation, monitoring, and controlled change must operate as one governance loop. MCP can standardize part of the connection layer, but it cannot substitute for insurance expertise, data governance, model governance, or accountable management.

RESPONSIBLE-AI OPERATING LOOP

Approved purpose and data → governed MCP retrieval or tool use → validated AI analysis → explanation and source evidence → professional review → decision and documentation → monitoring, feedback, incident response, and controlled change.

This chapter is an insurance-focused interpretation of the public Model Context Protocol specification and documentation. Protocol capabilities and security requirements evolve; implementation teams should verify the current specification revision before design or deployment.