Skip to main content

Set up and use the Datacapt MCP (Beta)

Connect Claude, ChatGPT or another AI assistant to Datacapt to build studies and follow monitoring figures in plain language, what the assistant can and cannot see, and what to do when it fails

The Datacapt MCP is a Model Context Protocol server. It lets an AI assistant such as Claude, ChatGPT or Copilot work with your Datacapt workspace in plain language: create a study, build an eCRF, translate it, set up automations and randomisation, then follow recruitment, queries, SDV and missing data once the study runs. You ask a question, the assistant calls the right Datacapt tool and answers with what it found or what it changed.

🧪 Beta: the Datacapt MCP is in beta. It is available to a limited number of customers, the list of tools and their behaviour may change without notice and the way you connect will evolve. Your feedback shapes what comes next: send it to your Customer Success Manager or through the support chat.

🔑 Prerequisite: Contact your Customer Success Manager to join. You also need an AI assistant or an automation tool that supports remote MCP servers and lets you add an HTTP header.

What you can do with it

  • Build a study. Create a study in DRAFT, lay out visits and forms, add questions, calculations, conditional logic and data validation, insert templates, add languages and translations, configure automations and randomisation.

  • Test it. Create test participants in a DRAFT study, enter answers and read them back to check that calculations, conditional logic and validation rules behave as designed.

  • Follow a running study. Headline figures, progress per visit, queries, SDV, review, missing data, eConsent and ePRO status, site by site and record by record.

  • Check access and activity. Who works on a study and with which role, what a role is allowed to do, and what happened in the audit trail.

How to connect to the Datacapt MCP?

You connect with a personal MCP token, sent as a Bearer token in the Authorization header of every request. There is no sign-in screen (OAuth) during the beta.

  • One token per user. Each person generates their own token from their own Datacapt account.

  • It carries your rights, and nothing more. The assistant sees the studies and the sites you see, and is refused exactly where you would be refused in the interface.

  • It signs your changes. What the assistant changes with your token is recorded in the audit trail under your name, with the origin MCP.

Get your MCP token

🛠️ Step by step guide

  1. Log in to Datacapt with your own account.

  2. Go to Settings.

  3. Select MCP > Generate MCP token.

  4. Copy the token and store it somewhere safe, such as a password manager.

💡 Tip: generating a new token invalidates the previous one. Replace it in every assistant where you had configured it.

Configure your assistant

Two values are needed, whatever the client.

Endpoint: https://mcp.datacapt.com/mcp

Header: Authorization: Bearer <your-mcp-token>

The header name is Authorization. Its value is the word Bearer, one space, then your token.

Claude Code

Run this command in a terminal, with your own token:

claude mcp add --transport http datacapt https://mcp.datacapt.com/mcp --header "Authorization: Bearer <your-mcp-token>"

Cursor, Claude Desktop, Copilot in VS Code, Codex CLI, Gemini CLI and other clients configured with a JSON file

Add the server to the MCP configuration of your client. In VS Code the file is .vscode/mcp.json and the first key is servers instead of mcpServers.

{
  "mcpServers": {
    "datacapt": {
      "type": "http",
      "url": "https://mcp.datacapt.com/mcp",
      "headers": {
        "Authorization": "Bearer <your-mcp-token>"
      }
    }
  }
}

n8n

  1. Add an AI Agent node with your LLM credentials.

  2. Add an MCP Client Tool node and connect it to the Tools input of the agent.

  3. Set the endpoint to https://mcp.datacapt.com/mcp and the transport to HTTP Streamable.

  4. Set the authentication to Header Auth, with the name Authorization and the value Bearer <your-mcp-token>.

  5. Under Tools to include, keep all tools or select the ones the workflow needs.

Other clients

Any client that supports a remote MCP server over HTTP and lets you add a custom header can connect with the same two values. A client that only offers a sign-in screen, with no field for a header, cannot carry the token yet.

Security reminders for your token

⚠️ Warning: treat your MCP token like your password. Anyone who holds it acts on Datacapt as you, and the audit trail will name you.

  • Never share a token between users. Each person generates their own.

  • Never commit it to git or paste it in a shared document, an email or a chat. Use an environment variable or a secrets manager.

  • Regenerate it regularly, and at once if you think it has leaked.

  • For an automation such as n8n, use the token of a dedicated Datacapt user with a role limited to what the workflow needs, not the token of an administrator.

What the assistant can and cannot see

The MCP was designed for clinical data. The limits below are built into the server. They are not instructions given to the assistant, the tools simply cannot return these fields.

  • Participant identity. No name, no contact detail, no date of birth. A participant is known by their Datacapt ID and a record by its subject ID.

  • Collected data. No collected answer leaves Datacapt outside a DRAFT study, where every answer is test data. On a LIVE study the assistant sees statuses and counts, never a value.

  • Queries. Status, site, visit and form only. The text of a query and of its replies is never returned, because it often quotes the value being questioned.

  • Changes. Every change is limited to a study in DRAFT, except creating a study. A LIVE study cannot be modified through the MCP.

  • Sending and randomising. The MCP configures, it never triggers. No email or questionnaire is sent to a participant, and no participant is randomised. Randomisation lists, slots and kits are not reachable, so nothing can unblind a study.

  • Permissions. The assistant works with the rights of the user the token belongs to.

  • Audit trail. Changes made through the MCP are recorded with the origin MCP, so they can be told apart from changes made in the interface.

Available tools

48 tools. You never call a tool by name, the assistant picks it from your request. The list may change during the beta. Tools marked DRAFT only are refused on a study in any other status.

Studies and sites

  • list_studies: the studies you can see, with status and headline counts. Every conversation starts here.

  • create_study: creates a study in DRAFT with its reference, sites and inclusion target.

  • list_centers: the sites of your organisation or of one study.

  • update_study_settings: signature, review, participant identity fields, attached sites, the variable shown in the participant list. DRAFT only.

  • list_projects: the side by side projects you can access.

Form builder

One set of tools for the five builders: eCRF, ePRO, eConsent, recruitment questionnaire and side by side project.

  • get_form_structure: the structure at the depth you need, from headline counts to one form in full with options, conditional logic and validation rules.

  • update_form_structure: creates, renames, reorders and removes visits and forms. Removals are previewed and confirmed. DRAFT only.

  • update_section: name, conditional logic, CDASH domain and variable prefix of one visit or one form. DRAFT only.

  • duplicate_event: duplicates a visit with its forms, questions and logic. DRAFT only.

  • create_blocks: adds questions, calculations, static content and repeated measure tables, one or many at a time. DRAFT only.

  • update_block: label, type, options, role access, conditional logic and validation rules of a question. DRAFT only.

  • delete_block: deletes a question, after listing the calculations and rules that depend on it. DRAFT only.

  • search_variables: checks that a variable name is free, finds a question by variable or title.

  • list_validation_rules: how many rules, of which kind, on which forms, and which questions carry none.

  • list_forms: the ePRO questionnaires, eConsent forms and recruitment questionnaires of a study.

  • update_epro_settings: occurrences, spacing, reminders and QR code of a questionnaire. Nothing is sent. DRAFT only.

Templates and exports

  • list_templates: the templates of your library.

  • create_from_template: inserts a visit, a form or a set of questions from a template, after a confirmation. DRAFT only.

  • save_as_template: saves a visit, form or question to the shared library, after a confirmation.

  • export_blank_ecrf_pdf: the blank eCRF as a PDF, structure only.

Automations and randomisation

  • list_automations and upsert_automation: the email automations of a study. An automation only fires once the study is LIVE. Writing is DRAFT only.

  • list_randomizations and configure_randomization: arms, ratio and strata. Setup only. Writing is DRAFT only.

Translations

  • get_study_translations: where each language stands and which labels are missing, validation messages counted apart.

  • set_source_language, add_study_language, set_study_translations: declare the language the study is written in, add a language, write translations. DRAFT only.

Monitoring

  • get_study_dashboard: screened, enrolled, excluded, completed, open queries.

  • get_monitoring_stats: one figure at a time: progress, queries, review, SDV or missing data, by site and by form.

  • get_site_performance: one site's records, queries, verification, review, missing data and staff in a single answer.

  • get_records: records counted per site, totalled per visit, or listed one by one with their status.

  • get_record_forms: where one record stands, form by form.

  • list_queries: the queries of a study with record, site, form and status. No text.

  • list_missing_data: the required questions still unanswered, record by record.

  • list_sdv: what is verified, by whom and when, and what is waiting.

  • list_consents: eConsent status per participant, including who has not signed the latest version.

  • list_epro_records: each questionnaire occurrence, its status and its deadline.

Recruitment

  • list_recruitment_campaigns: your campaigns, with status and progress.

  • get_recruitment_counts: how many candidates match a set of criteria, to size a criterion before committing to it.

Audit trail

  • get_audit_summary: audit events counted or listed by type, action, actor, origin and period, for one study or for the platform.

  • get_data_change_report: entries, updates and deletions, and how many updates carry a reason for change. Never the field or the value.

People and access

  • list_users: who works on a study, by role and by site, with pending invitations.

  • list_roles: the roles of your organisation.

  • get_role_permissions: the permission matrix of one role.

Test data

  • create_participants: creates test participants in a DRAFT study. Their IDs start with MCP-. DRAFT only.

  • enter_answers: saves answers into a test record, one visit at a time. DRAFT only.

  • get_answers: reads the stored answers back, with the calculations and validation rules they triggered. DRAFT only.

💡 Tip: when Datacapt adds tools, some assistants need the server to be refreshed or reconnected before they see them.

Examples

Build a study from a protocol

  1. "Create a phase III study on type 2 diabetes, 240 inclusions, on the Lyon and Bordeaux sites." The assistant creates the study in DRAFT and proposes a free reference if yours is taken.

  2. "Lay out screening, then W4, W12, W26 and W52, plus an unscheduled visit." The visits and their forms are created in one call.

  3. "Build the vital signs form for the screening visit, with a BMI calculated from height and weight." Questions, calculation and variable names are created together.

  4. "Raise a query when systolic pressure is above 180." A validation rule is added to the existing question.

  5. "Create two test participants in Lyon, enter a systolic pressure of 190 and show me what fired." You see the rule trigger before the study goes live.

Prepare a monitoring review

  1. "Where do we stand on FASTEN?" Headline figures from the dashboard.

  2. "Give me the site performance for Lyon." Records, open queries, SDV rate, review and missing data for that site.

  3. "Which queries in Lyon have never been answered?" The list, by record and form, without any query text.

  4. "Where is subject LY-012 in the study?" The status of every form of that record.

More requests that work well

  • "Which questions have no data validation at all?"

  • "What is still missing in the German version?"

  • "Can a CRA lock a form?"

  • "Who has not signed the latest consent version?"

  • "How many answers were updated without a reason for change this month?"

Best practices

  • Name the study first. Start with the study name or reference so the assistant resolves it once and stays on it.

  • Build form by form. Ask for one form at a time rather than a whole eCRF in one sentence. Each step is faster, and easier to review.

  • Narrow monitoring questions. Name a site, a visit, a status or a period. Lists are paginated and broad questions are answered with counts first.

  • Read previews before confirming. Deleting a form or a question, inserting a template and saving to the shared library are previewed first. The assistant lists what will be affected and waits for your answer.

  • Review in the interface before going live. The MCP builds faster than a person, it does not replace your validation of the study. Open the builder, test the forms, then change the study status yourself.

Limits and constraints

  • The MCP is in beta. Tools can be added, renamed or removed, and answers can change shape from one week to the next.

  • Authentication is by Bearer token only. There is no OAuth sign-in yet, so a client that cannot send a custom header cannot connect.

  • Changes are possible on DRAFT studies only. Going LIVE is done in the interface.

  • ePRO questionnaires, eConsent forms, recruitment campaigns and projects are created in the interface. Once they exist, the MCP can build their content.

  • Test participants cannot be removed through the MCP. Going live deletes their records, the participants themselves stay in the repository, nameless, with their MCP- ID.

  • Test answers cannot be entered inside a repeated measure table.

  • Conditional logic has no "is empty" operator. A yes or no question used as a gate is the way round it.

  • Audit tools cover the last 31 days by default, and the event list accepts a window of 31 days at most.

  • Queries carry no creation date and no author on this route. The assistant can tell which queries were never answered or whose last reply is over a month old, not how long a query has been open.

  • Counts below five are reported as "five or fewer", so per site figures may not add up exactly to the total. The total is the figure to quote.

  • Some assistants stop a tool after 60 to 120 seconds. Very large requests can hit that limit.

Troubleshooting

401 or 403 error when connecting

Check the header first. Its name must be Authorization and its value Bearer <your-mcp-token>, with one space after Bearer, no quotation marks around the token and no line break at the end. Check that you pasted the MCP token and not the public API key. If you generated a new token since, the old one no longer works.

To test the token outside your assistant, send a request to the endpoint with the same header from an HTTP client such as Postman. A 401 answer means the token is wrong, revoked or missing from the request. Any other answer means the token is accepted and the problem is in the configuration of your client.

The tools do not appear after connecting

Check that the server address is exact, with no space and no extra slash at the end. Restart the client or refresh the server in its MCP settings. Check that your client supports remote MCP servers over HTTP with custom headers.

The assistant says a study is not in DRAFT

This is expected. A LIVE study can be read, not modified. Make the change in the interface, where it follows your usual change process.

A study or a site is missing from the answers

The assistant sees what the owner of the token sees. Check your role and your site access on the study with your administrator.

A large build stopped halfway

Ask the assistant to read the form back and list what was created, then continue with the remaining questions. Building one form at a time avoids it.

The assistant refuses to show names or answers

This is by design, see What the assistant can and cannot see above. Open the record in Datacapt to read the data itself.

For anything else, or to share feedback on the beta, contact the Datacapt support team from the chat, with the name of the study and the request you made. Never paste your token in the chat.

👉🏻 Next step

Design Forms with the Builder

Update a study's status

Read the platform audit trail

Related Articles
Did this answer your question?