How do I use FormVault MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. 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.

FormVault MCP Server

by terjetyl

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

FormVault MCP server

npm License: MIT

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.

Prerequisites

A FormVault account and an API key. Create the key at formvault.eu/app/api-keys.

Related MCP server: mcp-server-dashform

Setup (hosted — recommended)

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.

Setup (npx / stdio)

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
`FORMVAULT_API_KEY`	yes	—
`FORMVAULT_API_URL`	no	`https://api.formvault.eu`

Self-hosting / local development

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

To develop against a local FormVault API, point FORMVAULT_API_URL at it (for example http://localhost:3000).

Tools

Tool	What it does
`list_forms`	Every form in your account, with field counts
`get_form`	One form's full field and settings definition
`create_form`	Build a form from a description
`delete_form`	Remove a form (irreversible)
`list_submissions`	Decrypted responses for a form

About respondent data

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.

Support

Questions and bug reports: open an issue. Pull requests are welcome.

License

MIT

Available Tools

5 tools

create_formCreate a formB

Create a form for the API key's tenant.

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.

Keep public-facing forms short — every extra question costs responses.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Form name (non-empty)
`fields`	Yes	Field definitions (at least one)
`settings`	No
`description`	No	Shown to respondents above the fields

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It usefully discloses that the form is scoped to the API key's tenant, which is real auth/multi-tenancy context. It does not state what is returned on success (no output schema exists), whether creation is idempotent, or what validations/errors to expect — meaningful gaps for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose, then organized into scannable blocks: field types, required per field, optional per field, settings, and a closing tip. The list format serves a deeply nested schema well. The final tip is the weakest line, but overall it is efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a nested-schema creation tool with no annotations and no output schema, payload construction is covered thoroughly, which is the dominant complexity. But the description omits the return value (e.g., the new form's id) and any permission/error behavior, leaving an agent unable to predict the outcome of the call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 75%, so the schema already documents most parameters, making 3 the baseline. The description consolidates the required-per-field set (id, type, label, required) and the conditional field usage (options for select/multiselect, min/max for number/rating, accept/maxSizeMb for file), but this largely restates descriptions already present in the schema rather than adding new semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource and adds the tenancy scope: 'Create a form for the API key's tenant.' An agent immediately knows this is a creation operation, and the verb form distinguishes it implicitly from list_forms, get_form, and delete_form. However, it never explicitly contrasts itself with those siblings, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use, when-not-to-use, or alternative-selection guidance is given. The closing tip ('Keep public-facing forms short') is form-design advice, not tool-selection advice, so it does not route an agent between create_form and siblings. Usage is only inferable from the verb.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_formDelete a form (irreversible)A

Permanently delete a form belonging to the API key's tenant. Irreversible, and the form's public URL stops working immediately. Confirm with the user before calling this — do not delete a form on your own initiative.

ParametersJSON Schema

Name	Required	Description	Default
`formId`	Yes	UUID of the form to delete

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and delivers the critical traits: permanence, irreversibility, and immediate public-URL breakage, plus tenant scoping. It omits cascade effects (e.g., what happens to the form's submissions) and any permission/auth requirements beyond tenant ownership.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences, front-loaded with the highest-consequence fact (permanent deletion) followed by consequences and the safety instruction. Every sentence earns its place with no repetition of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter destructive tool with no annotations and no output schema, the description covers the essentials an agent needs: scope, irreversibility, blast radius, and a call-for-confirmation guardrail. Missing detail on cascading deletion of related submissions and error behavior (e.g., unknown formId) keeps it from being fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the single formId parameter (UUID format) is already fully documented in the schema. The description adds nothing parameter-specific, which matches the baseline of 3 when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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") and scopes it ("belonging to the API key's tenant"). The destructive intent is unambiguous and clearly distinguished from the read/create siblings (list_forms, get_form, create_form).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells the agent when not to act autonomously ("Confirm with the user before calling this — do not delete a form on your own initiative"), which is strong operational guidance for a destructive tool. It doesn't name an alternative action (e.g., disabling or archiving a form instead), so it stops just short of full alternative routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_formGet a formA

Get one form with its full field and settings definition. Fetched from the tenant's form list, so an unknown id reports not found rather than another tenant's form.

ParametersJSON Schema

Name	Required	Description	Default
`formId`	Yes	UUID of the form

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does meaningful work: it discloses the return payload (full field + settings definition) and the error semantics (unknown id reports not found instead of returning another tenant's form, i.e., tenant isolation). It does not state permission requirements or whether the read has side effects, so it stops short of exhaustive, but adds real behavioral value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with zero waste. The return scope is front-loaded and the error/tenant-isolation caveat follows where it is most useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description correctly names what is returned (field and settings definition) and covers the not-found case. For a single-param read tool this is nearly complete; only auth/permission expectations are unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and formId is documented as "UUID of the form" in the schema itself. The description adds no additional format, sourcing, or constraint detail about the parameter, so the baseline 3 applies when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource ("Get one form") with an explicit scope of what is returned: the full field and settings definition. It is clearly distinguishable from the sibling list_forms (single vs. list) and the mutating create_form/delete_form, without needing to open any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Retrieval-by-id usage is implied by "Get one form" plus the required formId, and the tenant-scoped lookup is explained. However, no sibling is named as an alternative nor is any when/when-not condition given (e.g., use list_forms to discover ids first). Adequate but with a clear gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_formsList formsA

List every form belonging to the API key's tenant. Returns id, name, description, field count and timestamps.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full disclosure burden. It usefully adds tenant scoping and the exact return fields (id, name, description, field count, timestamps), but says nothing about pagination, ordering, or volume limits for a list operation where those matter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the verb and scope, followed by the return payload. Every clause earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description steps in to name the returned fields, which is the key information an agent needs. It stops short of covering pagination or result limits, a minor gap for a zero-parameter list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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. Baseline 4 applies; no parameter-related gaps exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('List') plus resource ('every form') and scope ('belonging to the API key's tenant'), letting an agent distinguish it from get_form (single) and list_submissions (different resource) 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.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the verb ('List every form'), and tenant scoping hints at the intended context, but the description never states when to prefer this over get_form or what prerequisites apply. No explicit alternatives or exclusions are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_submissionsList submissionsA

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.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum submissions to return (default 20)
`formId`	Yes	UUID of the form

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It does disclose two important traits: the returned data is decrypted personal data, and it should be handled with restraint. However, it says nothing about pagination, ordering, default limits, or failure modes, which are notable behavioral gaps for a data-retrieval tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste. The purpose is front-loaded, and the privacy constraint follows immediately as a critical guardrail. Nothing is padded or repeated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter read with no output schema, the description is adequate and even adds a valuable privacy guardrail that annotations could not supply. It omits return-format, pagination, and ordering details, though the absence of an output schema and the simple parameter set keep the practical impact limited.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and both parameters (limit with its default of 20, formId as a UUID) are fully documented in the schema itself. The description adds no parameter-level meaning beyond what structured fields already provide, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

"List decrypted submissions for a form" gives a specific verb (list) plus resource (submissions), with a meaningful qualifier (decrypted) and scope (for a form). Sibling tools (list_forms, get_form, create_form, delete_form) all operate on forms, so the submissions resource cleanly delineates this tool from them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to call it: "only call it when the user has asked for submission content," which is a clear condition, and pairs it with an avoidance rule about not repeating the data further than needed. Both the when and the when-not are stated in the description text.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.1Oct 18, 2026
- First observedcreate_form
- First observeddelete_form
- First observedget_form
- First observedlist_forms
- First observedlist_submissions

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-10-18 13:45 across 5 tools

Disambiguation5/5

Each tool targets a distinct resource+action: list_forms and list_submissions return different collections, get_form retrieves a single form definition, and create/delete are unambiguous write operations. There is no meaningful overlap between any pair.

Naming Consistency5/5

All five tools follow a strict snake_case verb_noun pattern (list_forms, get_form, list_submissions, create_form, delete_form). The convention is applied uniformly with no deviations.

Tool Count5/5

Five tools is well-scoped for a form-management server, with each tool earning its place across form listing, retrieval, creation, deletion, and submissions. No redundancy or padding.

Completeness3/5

The surface covers create/read/delete for forms and read for submissions, but there is no update_form (editing an existing form is a core workflow) and no submission-level operations beyond listing. These gaps will force agents to work around missing lifecycle steps.

Resources

Need Help?

Related Servers

Related MCP Connectors

FormsListOAuth
com.formslist
Form backend for AI agents: create live form endpoints, configure them, read submissions.
API Testing Data Platforms Developer Tools
1
brieformOAuth
io.github.silentdany
AI-native form builder: create, publish & read responses from Claude, ChatGPT & MCP.
Developer Tools App Automation
2
Deoochform AOAuth
io.github.musaib001
Create forms, read submissions, and build invitations from Claude, ChatGPT, or any MCP client.
App Automation Workplace & Productivity
102
mcpOAuth
com.formester
Give AI agents access to form submissions — read, search, update, and process file attachments.
App Automation Databases Customer Data Platforms
2

Related MCP Servers

Tally MCP
App Automation Content Management Systems
learnwithcc
A
license
B
quality
F
maintenance
Manage Tally.so forms through AI conversation. Create, update, and organize forms using natural language instead of web interfaces. Features safe bulk operations and works with all major MCP clients.
Updated a year ago (2025-06-25 03:36 UTC)
16
19 npm
8
ISC
mcp-server-dashform
App Automation Marketing Customer Support
makloai
A
license
Not graded
quality
F
maintenance
MCP server for Dashform (getaiform.com) - create and manage AI-powered forms, quizzes, and surveys. Supports form creation, response collection, analytics, and AI-driven form building with 15 tools across form management, response handling, and AI operations.
Updated 7 months ago (2026-03-31 05:38 UTC)
MIT
formslist-mcp
App Automation Data Platforms
vaibhavjain2608
F
license
A
quality
C
maintenance
MCP server for FormsList, a form-backend SaaS. Enables creating form endpoints, reading submissions, configuring auto-responses, and generating embed snippets via natural language.
Updated 2 months ago (2026-08-08 17:25 UTC)
7
-
formasty
App Automation Marketing Workplace & Productivity
QuantumCoderSys
A
license
Not graded
quality
A
maintenance
Enables AI agents to build and operate production-ready forms, quizzes, surveys, and workflows, including creation, publishing, submission management, and integration with webhooks and analytics.
Updated 2 months ago (2026-08-18 16:54 UTC)
MIT

FormVault MCP server

Prerequisites

Setup (hosted — recommended)

Setup (npx / stdio)

Self-hosting / local development

Tools

About respondent data

Links

Support

License

Available Tools

Tool Schema Changelog

Resources

Related MCP Connectors

Related MCP Servers