The Intely MCP Server connects Claude, Cursor, GitHub Copilot, ChatGPT Codex and other AI clients directly to the Intely platform, so an agent can build, inspect, and operate real healthcare integrations on your behalf.
Build healthcare integrations by describing them — in the AI client you already use. Your team already works alongside AI. Now it can build on Intely the same way: in plain language, in the client you already have open.
Building a healthcare integration has always meant learning a platform before you could use one. Which screen creates a data type. Where field mappings live. What has to be published before anything will run.
The clinical work — this HL7 segment becomes that FHIR element, this code set maps to that one — is rarely the hard part. Getting it expressed in a system that will execute it reliably, at three in the morning, for the next four years, is what takes the weeks.
That curve is real for our own engineers. It is steeper for customers who touch the platform a few times a quarter, and steeper still for a health tech team that wants to own its integrations but cannot justify a full-time specialist to do it.
Today we are removing that barrier.
The Intely MCP Server connects any AI client — Claude, Cursor, GitHub Copilot, ChatGPT Codex and others — directly to the Intely platform, so an agent can build, inspect, and operate real integrations on your behalf.
MCP, the Model Context Protocol, is the emerging standard for how AI clients connect to external systems. It is what lets an agent stop guessing about your environment and start working in it. The Intely MCP Server implements that standard across the full platform.
Once connected, an agent is not reading documentation about Intely. It is operating Intely. Ask it to build a mapping between two data types and it creates the mapping, wires the field-level transformations, publishes a version, and reports what it built. Ask why last night's run failed and it pulls the execution history, reads the logs, and tells you which step threw. Ask it to stand up an entire environment — apps and connections, data types, mappings, the integrations that move the data and the jobs that process it — and it builds that too.
The tool coverage spans the platform, organized by domain:
Integrations and their steps, the connections that form the flow graph, recurring schedules, version publishing, activation, and full execution history. An agent can construct a working integration and then prove it ran.
Data types, mappings, and crosswalks — the semantic layer where healthcare data actually gets reconciled. Finding the right data type among thousands is a genuine problem for a human clicking through a UI. It is a trivial one for an agent that can search, read cardinality, and compare field structures in seconds.
App definitions — interfaces, resources, actions — and the configured instances that point them at a real endpoint, including webhooks and sharing.
Intely Storage for the files a workflow consumes and produces, project organization, and search across Intely's own documentation so the agent can answer platform questions without leaving the session.
The on-premise agent we introduced earlier this year is fully addressable. An AI client can register an agent, define the jobs it runs inside the customer's network — database extracts, local API calls, file retrievals — trigger a run on demand, and read back execution history and logs to confirm what happened. Credentials stored on those jobs are always returned masked, so an agent can inspect and reconfigure a job without ever seeing the secret it uses.
Server instances and the source and destination interfaces attached to them, started and stopped on demand, with full message history available for inspection. This is the real-time HL7 path, operable from the same session as everything else.
Processing jobs carrying the same draft, publish, and version lifecycle as the rest of the platform, executed on demand, with execution records and logs returned for review.
Those last three are what close the loop with the Intely Agent. An AI client can now define a file-retrieval job that runs inside a customer's network, create the interface that picks the file up, start it, trigger the run, and confirm both that the message flowed and which integration execution it triggered — end to end, without anyone opening the UI.
Most integration tooling draws a hard line between building a thing and operating it: one set of screens to configure, another to monitor, and a handoff between two groups of people in the middle. Here they are the same conversation. The session that builds an integration can also start the interface that feeds it, run the on-premise job that produces the file, and read the logs when something fails at two in the morning.
On an EHR conversion or a hospital divestiture, the work is repetitive in shape and unique in detail. Every project needs data types, mappings, and crosswalks built for a specific source system, a specific target, and a specific set of local customizations. The patterns repeat. The particulars never do.
That combination is exactly where a human team loses time. The engineer who knows MEDITECH's quirks is not always the engineer with the most hours in our platform, so knowledge transfer becomes a scheduling problem. Meanwhile the build itself — hundreds of field mappings across dozens of data types — is mechanical enough to be tedious and detailed enough that tedium causes errors.
With the MCP server, the specialist describes the transformation and the agent constructs it, then reads it back for review. The expert stays in their area of expertise. The platform work stops being a bottleneck that only a few people can clear.
For projects with a hard go-live date, that changes what a small team can commit to.
For health tech companies using Intely as their integration layer, the constraint has usually been onboarding speed. Every new health system site means new interfaces, new mappings for local variations, and a round of configuration that scales linearly with the number of customers you sign.
An agent with direct platform access changes that ratio. Your implementation team can describe the new site's differences from the last one and have the configuration built and published in the same session. Site-specific quirks that would have become a backlog ticket get handled while the customer is still on the call.
It also covers the running system, not just the build. Interfaces can be started and stopped, message history pulled, and on-premise jobs re-run from the same session — so when a site reports that messages stopped arriving on Friday afternoon, diagnosing it does not require finding the one person who knows where that screen lives.
And it means your own engineers can work on Intely from inside the tools they already live in, rather than context-switching into a platform they use occasionally. The integration layer stops being a separate destination and becomes part of the environment they already have open.
A large tool surface is a liability if the agent does not know how to use it. An agent that can call anything, with no sense of order or platform rules, will build something that looks right and does not run.
So the server ships its own instruction set. Alongside the tools, it serves a set of how-to guides covering the platform's core building blocks — integrations, mappings, data types, crosswalks, and apps — that tell a connected agent which tools to call, in what order, and which rules the platform enforces: what must exist before something else can reference it, how the draft-and-publish lifecycle works, what versioning means for something already in production.
The agent reads these before it builds. Because the guides ship with the server rather than being installed on each machine, every connected client is on the current version the moment we deploy one. There is nothing for your team to update and no way to drift onto stale instructions.
This is the difference between an agent that can technically reach your platform and one that knows how to work in it.
For the engineers and security reviewers who will evaluate this, three design decisions matter most.
Every downstream call carries the identity of the authenticated user who asked. Authorization is evaluated against that person's permissions, and audit records attribute the work to them. An agent cannot reach anything its operator could not reach directly, and nothing it does is anonymous.
Each tool requires its own read or write permission for its domain. A session granted read access to integrations cannot write mappings. When a call exceeds what the session was granted, it is refused with a response naming precisely what would be needed, so the client can ask for it explicitly rather than failing silently or over-requesting up front.
Credentials are validated on each call — signature, issuer, intended audience, and expiry — with nothing cached between requests. Revoking access takes effect immediately rather than at the end of a session. Organization membership is confirmed against the platform rather than taken on the client's word, so a user cannot address an organization they do not belong to.
Connecting is a browser sign-in with your normal Intely credentials. There is no long-lived token to generate, paste into a config file, rotate, or leak.
The same posture that governs the rest of the platform governs this one. Sessions are scoped to a single organization, resolved and verified per request, so an agent cannot reach across a tenant boundary even by accident. Stored secrets stay masked wherever they surface. Every action lands in the same audit trail as work done in the UI, attributed to a named person — which matters more, not less, when the thing taking the action is an agent.
For organizations operating under a BAA with Intely, the MCP server extends the existing compliance posture rather than creating a parallel one. No new trust boundary, no separate set of credentials, no shadow access path.
We did not build this because agents are interesting. We built it because the same friction kept showing up on project after project.
Knowing healthcare data and knowing our platform are two different skills, and the projects that go well are the ones where the same person has both. That is a scarce combination, and it means the pace of a project is set by the availability of a handful of people rather than by the difficulty of the work. Giving an agent competent platform access decouples those two things. The person who understands the source system can now build in Intely without first becoming an expert in Intely.
Standing up an integration environment — apps and connections, data types, mappings and crosswalks, the integrations that move data and the processing jobs that act on it — has historically required either deep platform expertise in-house or a services engagement with our team. That made Intely a dependency on work our customers were entirely capable of owning, and it put a queue between them and changes they needed this week rather than next quarter.
With direct platform access from an AI client, customers build and operate these environments themselves — not sandboxes or throwaway demos, but full production environments integrating and processing real data. Our team stays available for the genuinely hard problems instead of being the bottleneck on routine build-out.
Hundreds of field mappings across dozens of data types is mechanical work where a single transposed field surfaces as a production defect months later. It is precisely the kind of task where human attention degrades and machine consistency helps — provided the result is reviewable, which it is, because everything the agent builds is visible in the UI and versioned like anything else.
For a health tech team, Intely is one system among many. Asking engineers to leave their editor, open a separate platform, and relearn its conventions every few weeks is a real tax on adoption. Meeting them inside the client they already have open removes it.
The Intely MCP Server is available now to all Intely customers. Connecting takes a single entry in your AI client and a browser sign-in with your existing credentials — no tokens to generate or manage.
Instructions for every supported client, including Claude Code, Claude Desktop, Cursor, ChatGPT Codex, GitHub Copilot and Copilot CLI, are available directly in the Intely platform under Organization → MCP, pre-filled for your organization and ready to copy.
If you are planning an EHR conversion, scaling integration delivery across multiple sites, or simply want your engineers to work on Intely without leaving the tools they already use — this was built for exactly that.
Talk to our team Visit intely.io
.png)
