Insurance industry leaders have barely achieved a tentative comfort level with artificial intelligence (AI) that talks (conversational AI), before being urged into AI that acts (GenAI and agentic AI). Tool use changes the operational profile immediately. Interfaces, permissions, logs, and change control start carrying real risk, and teams feel that risk fast.
Adoption pressure keeps climbing. According to McKinsey's State of AI in 2025 report, 62% of organizations are now experimenting with or piloting AI agents, and 23% report scaling agentic systems in at least one business function. The execution gap underneath those numbers is wide. Recent research from Adaline Labs notes that on τ-bench, a standard AI agent evaluation benchmark, well-trained language models succeed on roughly 25% of tasks, and the majority of those failures trace back to tool selection errors rather than execution errors.
Insurance, however, likes complexity, and therefore, adds a second constraint: Successful scaling of AI remains rare. Only 7% of insurers have brought AI systems to scale, and about two-thirds remain in piloting, according to Boston Consulting Group's Sept. 2025 report.
Part of this problem is due to unexpected results when AI is deployed "in the wild," so to speak. If used correctly, Model Context Protocol (MCP) can reduce the opportunity for AI to get out of its intended "box," and dull the sharp edge of errors or breaks produced when unanticipated switches get flipped. Five of the most common breaks include using ambiguous parameters that trigger unpredictable behavior, not implementing an MCP server to control tool calls, failure to log requests and responses blocking incident response, relying on unversioned interfaces, and missing timeouts and fallbacks that turn tool use into workflow friction.
Break 1: Ambiguous Parameters Trigger Unpredictable Behavior
Loose tool contracts invite ambiguity. Engineers define "address" in one system and "streetAddress" in another. Teams accept free-form strings where a workflow expects structured fields. Tool calls pass basic tests, then drift when real-world inputs hit the boundary. The Adaline Labs research found that parameter-level selection errors cascade to a wrong final answer roughly 62% of the time, citing the AgentProp-Bench benchmark for tool-using agents, and the wrong tool call is rarely the end of the failure.
Teams can stop this drift by making sure the fields in the response have clear, human-understandable names so the large language model (LLM) can parse them as needed. This is also true of the output values. Make sure the meaning of each value is clear, and don't rely on documentation or other external information to interpret match codes or other field values.
Action: Clearly name or label fields to ensure the LLM interprets match codes or other field values correctly.
Break 2: Implement an MCP Server to Oversee Tool Use
Tool-using AI generates requests at scale, but bad inputs rarely arrive one at a time. They arrive in bursts. A tool that accepts invalid payloads creates downstream damage in the form of partial records, misrouted work, duplicate entries, and manual cleanup.
Teams prevent this by "supervising" the LLM through the creation of an MCP server. Think of the LLM as an eager intern. Interns typically want to work hard, but don't have the experience to validate information independently. In the ideal scenario, your MCP server assumes the role of a gatekeeper, validating every request before passing it to downstream resources. Regulated workflows benefit from explicit controls, such as allowlists or authorizations for actions, strict parameter constraints, and business-rule validation where the tool touches risk decisions.
Action: Implement an MCP server to act as gatekeeper over tool calls while also validating requests and responses.
Break 3: Weak Logging Blocks Incident Response and Auditability
Trust collapses when teams can't reconstruct what happened. If you treat the LLM as you would any other employee, it needs to answer basic questions on demand, including who called what, with which parameters, what the tool returned, and what action executed next.
Employees need clear authorities and logs that support replay, audit, and performance analysis. Correlation IDs should tie tool calls to workflow events and downstream outcomes.
Action: Log every request and response with stable identifiers, timestamps, version tags, and access context. Store logs in a system that supports retention and retrieval requirements.
Break 4: Unversioned Interfaces Create Regressions that Stall Releases
Tool contracts evolve. Parameters change. Downstream systems break. Engineers lose weeks chasing regressions that started as "small" changes to an interface.
Versioning eliminates most of this pain. Teams should treat tool contracts like public APIs. Version tags, change notes, and deprecation windows keep consumers stable. Contract tests should verify behavior against expected inputs and outputs.
Action: Publish versioned tool definitions, enforce backward compatibility policies, and run automated contract tests in CI.
Break 5: Missing Timeouts and Fallbacks Turn Tool Use into Workflow Friction
Every tool call inevitably carries latency and failure risk. Networks fail, dependencies degrade, and a workflow that waits indefinitely builds backlogs and frustrates users.
Proactive teams can keep workflows moving by defining timeouts and explicit fallbacks. A fallback can route work to review, request missing fields, or return a structured "cannot complete" response that preserves workflow continuity.
Action: Set latency budgets for each tool, enforce timeouts, implement retries with backoff where appropriate, and define a deterministic fallback for every failure case.
What Teams Should Build Next
Tool-using AI succeeds when teams build execution infrastructure that behaves like software, supports governance, and scales across workflows.
- Inventory Tools and Classify Risk. Separate read-only tools from side-effecting tools. Apply stricter constraints to side-effecting actions.
- Write Strict Schemas and Enforce Validation. Treat schema design as a first-class engineering artifact.
- Implement Traceable Logging and Replay. Store enough data to reproduce an incident and prove what happened.
- Version Contracts and Automate Regression Testing. Protect downstream workflows from breakage.
- Define Timeouts, Fallbacks, and Failure Semantics. Keep workflows moving during degradation.
MCP is intended to standardize how AI applications discover tools and exchange structured inputs and outputs. Teams, however, still need engineering discipline to keep tool use safe, repeatable, and resilient. Fortunately, MCP can also provide the interface layer that standardizes tool discovery and invocation.
Using MCP, teams create safety and scalability through contract discipline and operational safeguards. Tool use will move into production quickly, and teams that ship reliably will treat tool contracts, validation, audit trails, and change control as core infrastructure.
