Coherent MCP connects AI agents to governed Spark calculations
Date July 27, 2026
The short version:
-
Enterprises are investing heavily in agent orchestration, but agents still need somewhere trustworthy to send a calculation. Coherent MCP makes governed Spark services callable as tools by MCP-compatible AI clients.
-
The architecture separates reasoning from calculation. The agent interprets requests, assembles inputs, and explains results. Spark executes the enterprise's actual logic, deterministically.
-
Agents can do more than execute. Through Spark's Testing Center tools, an agent can run testbeds, monitor runs, and compare result sets inside the same testing infrastructure the business already relies on.
-
MCP complements the Spark REST API rather than replacing it. Same services, different interaction model, no rebuild.
Most enterprise AI programs now have an orchestration layer and a reasoning layer. Very few have an answer for the calculation layer. When an agent needs a premium, a projection, or an eligibility decision, the question is where that number actually comes from, and "the language model worked it out" is not an answer that survives review, audit, or a regulator.
Our position is simple. Agents should interpret, orchestrate, and explain. The enterprise's own published logic should calculate. Coherent MCP is how those two layers connect.
What Coherent MCP is
Model Context Protocol (MCP) is an open standard for connecting AI systems to external tools and data. Coherent provides a remove MCP server that exposes Spark services as tools that MCP-compatible clients, including Claude, Cursor, and Visual Studio Code, can discover and invoke during a conversation or workflow.
The logic itself stays in Spark. Spark services are the calculation, rules, and testing infrastructure your teams have already built from the Excel models where the business reasoning lives, versioned with formula-level history and deployable to any connected system. MCP adds an agent-facing access layer on top. Authentication runs through your Spark tenant, so an agent's reach is bounded by the tenant identity and Spark permissions that govern access to your services.
The flow is short. A user makes a request in natural language. The agent identifies the relevant Spark service, assembles the structured inputs, and calls it. Spark executes and returns the result. The agent presents it, compares it, or carries it into the next step.
The agent reasons, Spark calculates
A language model can interpret a request about pricing, risk, or financial close with real skill. It should not be asked to reproduce the underlying calculation from prose. Probabilistic systems are the wrong tool for logic that has to return the same answer every time and show its work.
Spark's calculation engine is deterministic. Same inputs, same outputs, regression-testable and explainable back to the model it came from. When an agent calls a Spark service through MCP, the boundary between the two is explicit. The agent handles intent, input mapping, orchestration across multiple calls, and explanation of results. Spark handles execution of the published logic. If a result is questioned later, there is a governed service version behind it rather than a transcript of model output.
An agent workflow is only as trustworthy as the layer that does the math.
That boundary is what makes agent adoption defensible in regulated environments. It does not make an agent workflow automatically compliant, and the agent layer still needs its own governance. It does mean the calculation is never the improvised part.
What an agent can do once connected
The Coherent MCP server currently exposes tools in three areas.
Execute services
The spark_execute_v3 tool runs any Spark service the authenticated identity can access, with support for version selection, subservice invocation, and call tagging. An agent can price a scenario, run a projection, apply a decision model, or re-execute after the user changes a single assumption, all within one conversation.
Inspect and integrate
The spark_service_info tool returns a service's interface, so the agent can work out what inputs are required and guide the user through supplying them. The spark_generate_snippet tool generates integration code examples for the Execute API in twenty languages, from Python and JavaScript to Go and Swift. A developer in Cursor or VS Code can go from "what does this service expect" to a testable integration draft without leaving the editor. Generated code still goes through your normal review and delivery controls.
Run and compare tests
This is the capability that separates MCP from generic API connectivity. Through Spark's Testing Center tools, an agent can download a testbed template, start a testbed run against a service, monitor the run to completion, and compare two result sets against each other. Testing is where confidence in spreadsheet-derived logic is actually earned, and these tools put agents inside that workflow rather than around it. An agent can help a model owner regression-test a new version before promotion, then produce the comparison evidence a reviewer needs.
Full tool references and client configuration are in the Coherent documentation.
What this looks like in practice
A few architectural patterns this unlocks.
Conversational scenario analysis. An analyst asks for the base scenario, then a variant with the interest rate up 50 basis points, then a comparison of the two, then an explanation of which assumptions drove the largest change. Every number comes from governed Spark executions. The agent contributes the interaction, the comparison, and the narrative.
AI-assisted integration work. A developer building against a Spark service uses their IDE's agent to inspect the interface, generate a starting snippet, run sample requests, and diagnose input-shape issues, cutting the distance between service discovery and a working integration.
Guided access to complex models. Instead of handing a business user a workbook or an API schema, an agent asks for the missing values, normalizes terminology, assembles the request, runs the service, and presents the output in plain language. Sophisticated models become usable well beyond the team that built them.
Governed steps inside larger workflows. A Spark call can be one step in a longer agent sequence: collect information, validate it, execute the model, request human review where materiality demands it, pass the approved output downstream. Where regulation, materiality, or internal policy requires human review, this pattern keeps that step intact.
Where MCP fits alongside the REST API
MCP is one integration pattern among several, and choosing it is an architectural decision rather than an upgrade.
Reach for MCP when |
Reach for the REST API or SDKs when |
| The experience is conversational or agent-led | The workflow is fully application-controlled |
| An AI client needs to discover and invoke services dynamically | The interfaces should stay fixed, with no agent-driven service selection |
| A workflow involves several calculation calls shaped by evolving context | Maximum throughput or low-level request control is the priority |
| Developers want Spark access inside an AI-enabled IDE | The integration runs unattended for long periods |
Both routes call the same Spark services, so nothing is built twice.
The larger point sits above the protocol. Agents are arriving faster than most calculation estates are ready for, and the organizations that will move confidently are the ones whose critical logic is already governed, versioned, and callable. That is what Spark makes of an Excel model, and MCP is how agents reach it.
MCP support is rolling out across Spark environments.
Whether you run Spark today or are still mapping how agents will reach your calculation logic, talk to us about enabling it for your team.