This MCP server lets an AI assistant build and manage GDPR-compliant, EU-hosted FormVault forms through your account's API key.
List forms (list_forms) — see every form in your account with id, name, description, field count and timestamps.
Get a form (get_form) — fetch one form's full field and settings definition by id.
Create a form (create_form) — build a new form from fields (text, email, phone, date, select, checkbox, consent, textarea, number, rating, multiselect, hidden, file, page_break, calculated) plus optional settings like success message, redirect URL, close date and response cap; returns the form id and public share link.
Delete a form (delete_form) — permanently remove a form, immediately breaking its public URL.
List submissions (list_submissions) — read decrypted respondent answers for a form (personal data; only when you explicitly ask).
All operations are scoped to the tenant carried by your API key, so it can't touch another organisation's forms.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@FormVault MCP Server Build a client intake form with a GDPR consent checkbox."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Create and manage GDPR-compliant, EU-hosted forms from any MCP-compatible AI assistant.
This is an MCP server for FormVault, a form builder hosted in Germany. Point Claude, ChatGPT, Cursor, Copilot or any MCP-compatible assistant at your FormVault account and build forms by describing them.
A FormVault account and an API key. Create the key at formvault.eu/app/api-keys.
Related MCP server: formslist-mcp
Add the hosted server to your assistant's MCP configuration — no install, no local process:
{
"mcpServers": {
"formvault": {
"url": "https://api.formvault.eu/mcp",
"headers": {
"Authorization": "Bearer fv_your_key_here"
}
}
}
}Claude Desktop's support for remote/header-based MCP servers depends on your version — check its current docs if the above doesn't show up as an option.
No tool takes a tenant id. The API key carries its own, so it cannot read or write another organisation's forms — and a form id it may not touch reports as not found rather than forbidden, so a key cannot be used to discover what exists. The server itself holds no standing credentials of its own; every request is scoped to whichever key you send. Revoke a key at any time from the API keys page.
For clients that don't yet support a remote/header-based server:
{
"mcpServers": {
"formvault": {
"command": "npx",
"args": ["-y", "@formvault/mcp"],
"env": {
"FORMVAULT_API_KEY": "fv_your_key_here"
}
}
}
}Restart your assistant and ask for what you need, for example:
"Build me a client intake form with a GDPR consent checkbox."
"List my forms and tell me which have no fields yet."
"Delete the test form I made earlier."
Variable | Required | Default |
| yes | — |
| no |
|
You can run this package yourself, either as a local stdio server or as your own HTTP deployment. It is a client of the FormVault API, so it still needs a FormVault account and API key:
npm install
npm run build
# stdio (for a local Claude Desktop/Code config using "command"/"args")
FORMVAULT_API_KEY=fv_... node dist/index.js
# HTTP (what the hosted deployment runs)
PORT=3003 FORMVAULT_API_URL=https://api.formvault.eu node dist/httpServer.jsTo develop against a local FormVault API, point FORMVAULT_API_URL at it (for example http://localhost:3000).
Tool | What it does |
| Every form in your account, with field counts |
| One form's full field and settings definition |
| Build a form from a description |
| Remove a form (irreversible) |
| Decrypted responses for a form |
list_submissions returns your respondents' personal data in the clear. It is described to the model with an instruction not to call it unless you explicitly ask for responses, so ordinary form-building work never pulls it into context.
That is a deliberate boundary, not a limitation. FormVault stores submissions encrypted with AES-256-GCM on servers in Nuremberg, Germany, with a signed DPA on every plan. Whatever you send to your AI provider is your decision — this server's job is to make sure it is a decision rather than a side effect.
Questions and bug reports: open an issue. Pull requests are welcome.
Create a form for the API key's tenant.
Field types: text | email | phone | date | select | checkbox | consent | textarea | number | rating | multiselect | hidden | file | page_break | calculated
Each field needs: id (unique within the form), type, label, required. Optional per field: placeholder, options (select/multiselect), min/max (number/rating), defaultValue (hidden), accept and maxSizeMb (file).
Settings (all optional): successMessage, redirectUrl, closeAt (ISO date), maxResponses.
Returns the created form (including its id) and its publicUrl, the shareable link respondents use. This tool only creates: it never edits an existing form, so call it once per new form and check list_forms first if a form with the same name may already exist. If the FormVault API rejects the input or the key, the tool returns an error result with the API's message and nothing is created.
Keep public-facing forms short — every extra question costs responses.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Form name (non-empty) | |
| fields | Yes | Field definitions (at least one) | |
| settings | No | Optional form behaviour: successMessage, redirectUrl, closeAt (ISO 8601) and maxResponses | |
| description | No | Shown to respondents above the fields |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does well: it discloses the return payload (created form with id plus publicUrl), the create-only/non-idempotent semantics, and the error behavior ("returns an error result with the API's message and nothing is created"). It does not spell out authentication/key requirements or any rate limits, which is the remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then cleanly segmented into field types, per-field requirements, settings, return value, and routing. Slightly verbose — the closing tip ("Keep public-facing forms short") is advisory rather than operational and does not help invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a nested, multi-param create tool with no output schema and no annotations, the description covers everything needed to call it correctly: parameter shape, mutation semantics, return value (id + publicUrl), and error outcome. Nothing an agent needs is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the baseline is 3, but the description adds practical structure beyond the schema: the full field-type enumeration, the required per-field keys (id/type/label/required), which optional keys pair with which types (options for select/multiselect, min/max for number/rating, accept/maxSizeMb for file, defaultValue for hidden), and the optional settings block. This is largely a reorganization of schema content, so it does not go far past the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ("Create a form for the API key's tenant") and immediately scopes it against siblings by stating it never edits an existing form and pointing to list_forms for duplicate checks. An agent can distinguish it from get_form/delete_form/list_forms without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use guidance ("call it once per new form"), an explicit pre-check alternative ("check list_forms first if a form with the same name may already exist"), and an explicit when-not (it never edits existing forms). The failure path is also described so the agent knows what a rejected call looks like.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a form belonging to the API key's tenant. Irreversible, and the form's public URL stops working immediately. Use list_forms to find the id first. Confirm with the user before calling this — do not delete a form on your own initiative.
| Name | Required | Description | Default |
|---|---|---|---|
| formId | Yes | UUID of the form to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it discloses irreversibility, that the public URL stops working immediately, and the tenant scoping of the target. It stops short of stating required permissions or error behavior for a missing/already-deleted id, which would be the remaining disclosure gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the destructive nature and impact, then the prerequisite, then the safety constraint. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-param destructive tool with no annotations and no output schema, the description covers impact, target scope, prerequisite lookup, and human-confirmation policy. Minor omissions like permission requirements or post-delete error semantics keep it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter and schema coverage is 100%, so the schema already documents formId as the UUID to delete. The description adds tenant-scoping context but no format or sourcing detail beyond what the schema and the list_forms pointer provide; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Permanently delete a form') plus the scope ('belonging to the API key's tenant'). It is unmistakable against siblings list_forms, get_form, and create_form, which are all non-destructive or additive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent to list_forms to obtain the id, and adds a hard when-not rule: confirm with the user, do not delete on your own initiative. Both the prerequisite and the prohibition are stated outright.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one form with its full field and settings definition. Read-only. Fetched from the tenant's form list, so an unknown id returns a not-found error rather than another tenant's form. Use list_forms to discover ids; use list_submissions for responses.
| Name | Required | Description | Default |
|---|---|---|---|
| formId | Yes | UUID of the form |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and does well: it declares 'Read-only' and discloses the tenant-scoping behavior (unknown id yields not-found rather than another tenant's form), which is genuine behavioral context. It stops short of auth requirements or explicit return shape, but the scoping and safety profile are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core action, then the safety/scoping trait, then the routing hints. Every sentence carries distinct information; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description says what is returned ('full field and settings definition'), how ids are obtained, what happens on a bad id, and what sibling covers submissions. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning about formId: it is resolved against the tenant's form list and an unknown value produces a not-found error rather than a cross-tenant lookup. That is more than the schema's 'UUID of the form' conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one form') and quantifies scope ('its full field and settings definition'), which separates it from the list/collection siblings. An agent can distinguish it from list_forms, create_form, and delete_form without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: 'Use list_forms to discover ids; use list_submissions for responses.' Both prerequisites (need an id first) and the alternative for a different resource are named, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every form belonging to the API key's tenant. Returns id, name, description, field count and timestamps. Read-only. Use this first to find a form's id before calling get_form, list_submissions or delete_form; use get_form when you need the field definitions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the safety profile ('Read-only'), the tenant-scoping boundary, and the returned fields. It stops short of pagination/result-count behavior, which for a list-everything tool is the one meaningful remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the scope, then the return shape, then the routing guidance. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description enumerates the returned fields (id, name, description, field count, timestamps), so the agent knows what to expect. Combined with the read-only and tenant-scope notes, nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. The description correctly implies the tenant filter is implicit rather than an argument.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (list) and resource (forms) plus the scoping boundary (the API key's tenant), and explicitly distinguishes itself from get_form by noting the latter returns field definitions. An agent can route between these without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit ordering instruction ('use this first to find a form's id before calling get_form, list_submissions or delete_form') and names the alternative plus the condition that selects it ('use get_form when you need the field definitions'). No inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List decrypted submissions for a form. This returns respondents' personal data — only call it when the user has asked for submission content, and do not repeat it further than needed to answer. Read-only. Returns up to limit submissions (default 20) for one form; use list_forms to find the formId.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum submissions to return (default 20) | |
| formId | Yes | UUID of the form |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and does well: it declares 'Read-only', warns that the payload is sensitive personal data, and states the result cap (up to `limit`, default 20) for one form. It omits pagination/ordering behavior and what happens when more submissions exist than `limit`, so the disclosure is strong but not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly packed sentences, front-loaded with the action and the privacy constraint, then the return cap, then the dependency. No filler and no repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter list tool with no output schema and no annotations, the description covers purpose, safety posture, privacy handling, result bounds, and the formId dependency. The main remaining gap is whether results are truncated or paginated and in what order they are returned, which matters for a limit-bearing list endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented and the baseline is 3. The description restates the default of 20 and adds the useful sourcing hint for formId via list_forms, but contributes no syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List decrypted submissions for a form') and immediately differentiates from the sibling list_forms by naming what it returns (respondents' personal data) rather than form metadata. An agent can tell it apart from list_forms/get_form without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit precondition ('only call it when the user has asked for submission content'), a handling constraint ('do not repeat it further than needed to answer'), and routes to the alternative tool needed to obtain the required formId ('use list_forms to find the formId'). Nothing about when to select this tool is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.2create_form3 fields changedInput schema / properties / settings / descriptionAdded value: +"Optional form behaviour: successMessage, redirectUrl, closeAt (ISO 8601) and maxResponses"Input schema / properties / settings / properties / redirectUrl / descriptionAdded value: +"URL to send the respondent to after they submit"Input schema / properties / settings / properties / successMessage / descriptionAdded value: +"Message shown to the respondent after they submit"v0.1.1create_formdelete_formget_formlist_formslist_submissionsScored across 5 tools
Each tool maps to a distinct resource+action: list_forms (discovery/metadata) vs get_form (full field definitions), create_form, delete_form, and list_submissions. Descriptions explicitly cross-reference each other and state when to prefer one over the other, leaving no realistic misselection path.
All five names follow the same snake_case verb_noun pattern (list_forms, get_form, create_form, delete_form, list_submissions). Verb choice is predictable (list/get/create/delete) and resource nouns are consistent between singular and plural forms.
Five tools is a tight, well-scoped surface for a form service and every tool earns its place with no redundancy. It leans slightly thin, since form authoring realistically spans more than a single create operation.
Create, read (list + get) and delete are covered, but there is no update_form at all — create_form explicitly states it never edits an existing form — so agents cannot modify a form or its fields once created. Submissions are also read-only with no single-submission fetch, export, or delete, leaving notable lifecycle gaps.
Build, edit and publish forms and read their responses from your AI assistant.
Create forms, share the link and read responses as JSON or CSV from your AI agent.
Form backend for AI agents: create live form endpoints, configure them, read submissions.
AI-native form builder: create, publish & read responses from Claude, ChatGPT & MCP.