MCP and LLMs in Clinical Research: Driving an EDC with an AI Agent

In an EDC, an assistant that only answers questions is of limited use. A data management team expects a tool to do things: create a form, set a visibility rule, add a language to a study. And because every action on a study falls under GCP and 21 CFR Part 11, that action has to be traced, attributed to a person, and held until someone has validated it.

The Model Context Protocol (MCP) is the standard that lets an LLM such as Claude, ChatGPT, Gemini, Grok or a locally hosted model drive an EDC without rewriting an integration for every new need. This article covers what it changes compared with APIs, the principle that governs everything else (no clinical data is sent to the model), the use cases where it delivers the most, and what it does not allow.

What Is the Model Context Protocol?

MCP is an open standard published by Anthropic in late 2024 and since adopted by most model providers. It describes how an LLM, whether Claude, ChatGPT, Gemini, Grok or another, discovers and calls the functions of a third-party application.

In practice, an MCP server exposes a catalogue of tools: list_studies, get_form_structure, create_item, get_query_stats. Each tool has a description and parameters. The model reads the catalogue, receives a request in plain language and decides for itself which tools to call.

Behind the MCP server, the EDC's existing REST APIs do the work. The protocol does not replace them. It adds a layer that lets a model use them without a developer writing a connector for every scenario.

API or MCP: What Changes

APIs remain the foundation of any integration, and Datacapt is built API-first. They are very well suited to one-off, structured needs: a scheduled export to a data warehouse, a sync with a CTMS, a lab results feed. The need is known in advance, so is the format, and the integration runs for years.

Their limit shows when requests multiply and vary. Each new need means a dedicated build: one integration to pull a site's enrolment metrics, another to flag overdue forms, a third to export for the steering committee. When the next need comes along, slightly different, the cycle starts again.

With an MCP server, all of the EDC's capabilities are exposed once and immediately usable. The user states the request in plain language and the model carries it out, picking the right tools in the right order.

The Governing Principle: No Clinical Data Is Sent to the Model

The starting point is simple. Sending clinical data to a public LLM, whether Claude, ChatGPT, Gemini, Grok or another, carries a risk most sponsors and CROs cannot take: health data, subject identifiers, randomisation elements. Technically, it could be done, with contractual guarantees, encryption and certified hosting. The safest choice is still to send nothing at all. That is the choice made here, and everything else follows from it.

What the model receives: counts, statuses, percentages, structures. The number of patients enrolled per site, the SDV rate, the breakdown of queries by age, the list of sections in a form with their validation rules.

What the model never receives: a value entered in an eCRF, an ePRO response, a subject or screening identifier, consent content, a randomisation element. Monitoring endpoints that return rows at the enrolment level are aggregated by the server before anything is sent. A raw row never reaches the model.

This rule holds whatever the client. The agent built into the platform and a local model the user connects through their own MCP client go through the same server, with the same scopes. In local mode, neither the prompt nor the model is under the vendor's control, so the guardrails live in the service, not in the instructions given to the model. A missing scope cannot be talked around by rephrasing the request.

What About End-to-End Encryption?

The question comes up often: could we not build a bridge where clinical data travels encrypted end to end, so the model handles it without ever reading it in clear?

Technically, yes. But an LLM works on readable text. On encrypted content it can neither compare two dates, nor spot an inconsistency, nor suggest a MedDRA code. It would carry opaque blocks from one point to another, which an API already does very well without it. And decrypting on the model side, even in an isolated environment, reopens exactly the question we wanted to close.

So the choice is to keep the data away from the model and accept what that implies.

What This Limits

It should be said plainly: this architecture closes some doors.

• No subject-level queries. The agent cannot write "visit V3 for subject 012 is dated before V2". It can flag that a site has twelve incomplete forms in the adverse events section and draft a reminder to the investigator. The subject-level query itself is still written by the data manager.
• No medical review. The agent does not see values, so it detects neither clinical inconsistencies nor safety signals.
• No export of collected data. MCP exports are limited to structures and templates.

Main Use Case: From Protocol to eCRF Study Build

This is the use case that weighs most on a study's start-up timeline, and it is also the one the rule above does not affect: designing an eCRF requires no patient data.

Going from a protocol to a working eCRF takes several weeks. The thinking is quick. What eats the time is the entry: creating visits, forms, fields, edit checks, display conditions ("this block only appears if the patient is a woman of childbearing potential"), then writing the test scripts and running them one by one.

With an agent connected to the EDC's MCP server, the sequence becomes:

1. The user provides the schedule of assessments. The table is enough. Feeding in the protocol's 80 pages does not improve the result and burns tokens for nothing.
2. The agent builds the structure in a draft environment: sections, items, fields, conditional logic and validation rules. It draws on the protocol elements provided, the user's request, or existing forms.
3. The agent produces a report of what it created and writes the UAT test scripts.
4. The data manager reviews, corrects, validates the tests and accepts the move to production. The agent can then trigger it.

This is the human-in-the-loop principle: at every step, the agent proposes and a person decides. The data manager reviews the configuration, fixes what needs fixing (a misread footnote, a numeric field where a dropdown was needed, there are always corrections), validates the test scripts the agent wrote, then signs off on the move to production. Nothing goes LIVE without that explicit acceptance, and it is recorded in the audit trail under the person's name, not the agent's.

Once the study is LIVE, the agent no longer changes anything in the published version. Any change goes through a new study version, which returns to draft, and the agent along with it.

Other Use Cases

• Dashboards and monitoring. "Show site 102's enrolment against forecast, and the breakdown of open queries by age." The agent reads the aggregated indicators (screening, enrolment, completion by section, SDV, missing data), builds the chart, comments on the gap. The CRA no longer has to open four screens. The limit shows when the question rests on an undefined notion ("at-risk patients"): without an explicit definition, the model makes one up.
• Translations. The agent can add a language to a draft study and propose translated labels, working from the source labels and the gaps it identifies.
• Medical coding assistance. This is the one place where entered text has to leave the platform: the verbatim term, on its own, with the dictionary and its version. No subject, no site, no date, no visit. In return, a suggested MedDRA or WHODrug code, never an applied one. The medical coder validates or replaces it, and not only for regulatory reasons: on ambiguous or misspelt terms, a model's error rate is still too high to skip the review.

How It Is Built

The MCP server is a separate service placed in front of the public API. It has no direct database access and holds no credentials of its own. It calls the API with the user's key, and that key opens nothing its holder did not already have.

[ Data manager / CRA ]
        │  "Build the eCRF structure from the schedule of assessments"
        ▼
[ LLM agent — built-in chat or the user's local model ]
        │  get_form_structure(), create_item(), list_templates()
        ▼
[ MCP server — separate service, user's MCP key ]
        │  aggregation, filtering, DRAFT status check, MCP origin written to audit trail
        ▼
[ EDC public API ]
        │  execution report, no clinical data
        ▼
[ Review, test validation and acceptance by the data manager ]  ──►  production

The MCP key is distinct from the classic API key. A system integration and a conversational agent share neither lifetime nor risk profile: the MCP key is individual, expires, can be revoked immediately, carries scopes fixed at creation and volume quotas. There is no organisation key and no service account for MCP.

Compliance: 21 CFR Part 11, Annex 11, ICH E6(R3)

Three questions come up every time with quality teams.

• Can the agent perform an irreversible action? No. Writes are confined to studies in DRAFT or new versions, and that check sits in the backend, not in the instructions given to the model. Moving to production requires explicit acceptance from the user. Actions on a published version (editing a LIVE form, applying a code, writing to collected data) are not exposed at all.
• What does the audit trail contain? Every call is recorded with an "MCP" origin, distinct from platform actions and classic API calls, along with the tool name, its parameters, the user who made the request and the timestamp. The recorded actor is always the person, never a system actor. An "MCP origin" filter lets an auditor isolate the whole set in one query. That is what 21 CFR Part 11 and Annex 11 expect for computerised system traceability.
• Are protocols or study structures used to train the model? That depends on the LLM provider and the setting the user chooses. Claude, ChatGPT, Gemini and Grok all offer an option not to use data for training, but it is up to the user or their organisation to enable it in their account. Datacapt has no visibility on that setting. For a locally hosted model, the question does not arise.

ICH E6(R3) points the same way, with its emphasis on a risk-proportionate approach and on data integrity. An agent that prepares without deciding, and does not see the data, fits that logic.

What MCP Does Not Solve

A few situations where the approach shows its limits today, beyond those already described on data access:

• The full build without review. The agent produces a solid base, not a finished eCRF. Someone always has to go over it.
• Errors. It makes them, and some are quiet ones: a field type, a unit, an inverted condition. That is exactly why the data manager reviews everything and the agent deploys nothing without acceptance.
• Cost. A full eCRF build represents a non-trivial volume of model calls, to be budgeted like a licence.
• Vague requests. A well-designed MCP server returns a clarifying question rather than an approximate action, but that depends on the implementation.

MCP with Datacapt

The Datacapt MCP server applies the rules described in this article. It can be used from the chat built into the platform or from the MCP client of your choice, connected to the model you have chosen, whether Claude, ChatGPT, Gemini, Grok or another.

• Metadata and aggregates only. No eCRF value, no ePRO response, no subject identifier leaves the platform. The only entered text that can leave is a verbatim term, on its own, for a coding suggestion.
• Writes in DRAFT or on a new version, never on a published version. eCRF structure, conditional logic, validation rules, templates, languages. The check sits in the backend.
• One MCP key per user. Distinct from the API key, time-limited, revocable, with scopes fixed at creation. It inherits the person's rights and nothing else.
• MCP origin in the audit trail. Every call is identifiable as such, under the user's name, with the tool and its parameters. A dedicated filter for inspections.

Conclusion

MCP does not change what an EDC can do. It changes who can trigger those capabilities and how: a data manager or a CRA, in plain language, without a dedicated build.

In clinical research, the condition for this to work comes down to two rules. The agent prepares, the human validates. And for now, the model sees no clinical data at all, which narrows its scope. That should evolve, for instance with an internal model hosted locally, which would let the agent work with some data without it ever leaving the infrastructure.