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.

Build what goes around it. Create an ePRO questionnaire with its schedule, an eConsent, a recruitment campaign or a side by side project, and fill each of them with the same builder tools as the eCRF.

Test it. Create test participants in a DRAFT study, enter answers, repeated measures included, 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.

Sign in with your Datacapt account (OAuth2). The assistant opens a Datacapt sign-in screen and you approve the access. Nothing to copy or store. This is the way to go for assistants that connect to a remote MCP server by its address alone, such as Claude or ChatGPT.

Personal MCP token. A token you generate in Datacapt, sent as a Bearer token in the Authorization header of every request. This is the way to go for automation tools and for clients configured with a file.

One connection per user. Each person signs in with their own Datacapt account, or generates their own token from it.

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 on your behalf is recorded in the audit trail under your name, with the origin MCP.

Never share a token or a signed-in assistant between users. Each person connects with their own account.

Never commit a token 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.

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, a recruitment campaign or a project in DRAFT. What the MCP creates is always created in DRAFT. 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 who signed in or whose token it uses.

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.

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, randomisation module, participant identity fields, attached sites, the variable shown in the participant list. DRAFT only.

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 events and forms, and sets which roles see a form. Removals are previewed and confirmed. DRAFT only.

update_event: name, conditional logic, CDASH domain and variable prefix of one event or one form. Every change is previewed and confirmed. DRAFT only.

duplicate_event: duplicates an event with its forms, questions and logic. DRAFT only.

create_items: adds questions, calculations, static content and repeated measures, as a list or as a table with named rows, one or many at a time. DRAFT only.

update_item: label, type, options, position, role access, conditional logic and validation rules of an item. DRAFT only.

delete_item: deletes an item, after a preview of the conditional logic and calculations that read it and a warning about the automations that would be deleted with 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_study_modules: the ePRO questionnaires and eConsents of a study, with their status.

create_epro: creates an empty ePRO questionnaire in a study. DRAFT only.

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

create_econsent: creates an empty eConsent in one language and one version, for the sites you name. DRAFT only.

list_recruitment_campaigns: your campaigns, with status and progress.

create_recruitment_campaign: creates a campaign in DRAFT with its reference, sites, recruiter and target.

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

list_projects: the side by side projects you can access.

create_project: creates a side by side project in DRAFT with its brand, category and sites.

list_templates: the templates of your library.

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

save_as_template: saves an event, form or question to the shared library, after a confirmation.

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

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, as a static list or a dynamic allocation. Setup only. Writing is DRAFT only.

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.

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.

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.

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.

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, including the rows of a repeated measure. DRAFT only.

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

"Which questions have no data validation at all?"

"What is still missing in the German version?"

"Create the English eConsent, version 1.0, for the Paris site."

"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?"

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 an event, a form or an item, changing an event's name, logic or variable prefix, inserting a template, saving to the shared library and adding a second randomisation setup are previewed first. The assistant lists what will be affected and waits for your answer.

Say which sites and which language. An eConsent, a campaign or a project is created for the sites you name. The assistant asks rather than attaching every site.

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.

Changes are possible in DRAFT only. No tool changes a status: going LIVE, publishing an eConsent or opening a campaign is done in the interface.

Repeated measures exist in the eCRF only, and calculations in the eCRF and ePRO only. A prefill rule exists on a single-choice question of the eCRF only.

An image item needs a file upload, which the MCP cannot do. Add it in the builder.

Whether a repeated measure shows as a list or as a table is fixed when it is created.

Configuring randomisation always creates a new setup. An existing setup is edited or removed in the interface.

A new version of a published eConsent is a new eConsent.

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.

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

Deleting a question does not repair what read it. Conditional logic and calculations that pointed at it have to be fixed by hand, and the preview lists them.

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.