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 randomization.

Build what goes around it. Create an ePRO questionnaire with its schedule, an eConsent or a recruitment campaign, 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 key. A key you create in Datacapt, sent with the word Bearer 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 creates their own key 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 with an MCP badge next to your name, in the study and platform audit trails.

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

Never commit a key 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 key of a dedicated Datacapt user with a role limited to what the workflow needs, not the key 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 or a recruitment campaign in DRAFT. What the MCP creates is always created in DRAFT. A LIVE study cannot be modified through the MCP.

Sending and randomizing. The MCP configures, it never triggers. No call sends an email or a questionnaire, and no participant is randomized. What it configures then runs on Datacapt's own schedule, exactly as if it had been set up in the interface: an automation saved on a DRAFT study fires on its test records too, and a scheduled questionnaire goes out to them with its reminders. Randomization 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 key it uses.

Audit trail. Changes made through the MCP are recorded with an MCP badge, 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 organization or of one study.

update_study_settings: name, reference, inclusion target, start date, signature, review, randomization module, participant identity fields, attached sites with their code and target in the study, 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 and CDASH domain of one event or one form, and on an event the variable prefix and suffix. Every change is previewed and confirmed, and a new prefix or suffix renames every variable of the event. DRAFT only.

duplicate_event: duplicates an event with its forms, questions and logic under a new variable prefix. Without a prefix it proposes one derived from the source event and waits for your answer. DRAFT only.

create_items: adds questions, calculations, static content and repeated measures, as a list or as a grid with named rows, one or many at a time and on several forms in one call. A condition can read a question created earlier in the same call, so a whole form is built in one go. DRAFT only.

update_item: label, variable, type, options, position, required flag, role access, display (hidden in the form, read only for a role, answers of other questions shown beside it), conditional logic and validation rules of an item. A change that would delete or break a condition, a rule or a calculation reading the item is previewed first, and a rename that would break a formula is refused with the formulas named. 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, invitation email, email and SMS reminders, closing date and QR code landing page of a questionnaire. The call sends nothing itself; Datacapt then applies the schedule on its own. Replacing existing reminders is previewed first. 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_templates: the templates of your library.

create_from_template: inserts an event, a form, a set of questions or a whole module from a template, after a confirmation. Datacapt offers no way to read a template's content, so the preview names the template, not what it holds. DRAFT only.

save_as_template: saves an event, a form, a question or a whole module to the shared library, with a description, after a confirmation. DRAFT only.

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

list_automations and upsert_automation: the email automations of a study, fired by an inclusion, an exclusion, a randomization, a query, a signed or rejected eConsent or one question's answer, and sent to roles or to typed addresses. An automation that sends a questionnaire is created in the interface and only updated here. Once saved, an automation fires on the test records of a DRAFT study too. Writing is DRAFT only.

list_randomizations and configure_randomization: arms, ratio, blinding, block sizes and strata, as a static list or a dynamic allocation. The randomization module has to be on first, which update_study_settings does. Setup only, and reading it leaves a row in the study's audit trail, as it does in the interface. Writing is DRAFT only.

get_study_translations: where each language stands and which labels are missing, across the eCRF, the questionnaires, the eConsent and the automations, or any narrower scope you name.

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, in progress, completed, signed, open queries, and the screening curve per site.

get_monitoring_stats: one figure at a time: progress, queries, review, SDV or missing data, by site and by form, with the queries nobody has answered and those whose last reply is over a month old.

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, with the counter-signature date, 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 organization.

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, a missing-data reason instead of a value, and a reason for change when an answer is replaced. 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, variable prefix or suffix, changing the options or the type of a question that a condition, a rule or a calculation reads, replacing the reminders of a questionnaire, inserting a template, saving to the shared library and adding a second randomization setup are previewed first. The assistant lists what will be affected and waits for your answer.

Say which sites and which language. An eConsent or a campaign 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 grid is fixed when it is created. A grid holds 20 rows at most, and its columns take no data validation, no conditional logic and no required flag. A list holds up to 50 rows.

Each builder takes its own kinds of data validation: warning, information and exclusion in the eCRF, exclusion alone in an ePRO or an eConsent, disqualification in a recruitment campaign. A range takes two rules, one above and one below.

An exclusion rule raises a query, it never excludes the record. The excluded figure of the dashboard counts the records a user excluded in the interface.

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

An automation that sends a questionnaire, and one fired by a questionnaire being sent, are created in the interface; the MCP updates them. The questionnaire, the delay and the trigger of an existing automation are changed in the interface too.

A template's content cannot be read before it is inserted. Insert it, then read the result.

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. Days are UTC days, which can differ from the local date the interface shows near midnight.

A date entered in a test record is checked against your time zone to refuse a future date. Tell the assistant your time zone, or today's date east of UTC may be read as tomorrow.

The eConsent list shows the date the investigator counter-signed, not the date the participant signed, as the interface's own list does.

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.