Brieform
Server Details
AI-native form builder with a native MCP server. Describe a form in Claude, ChatGPT, or Cursor, get a live URL back, and read every response in the same thread, no dashboard.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 12 of 12 tools scored.
Each tool has a clearly distinct purpose: form CRUD, publishing, duplication, analytics, sharing, responses, and theming. No overlapping or ambiguous tools.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_form, delete_form, get_form_analytics), making it predictable for an agent.
12 tools cover the full lifecycle of form management without being excessive. Each tool serves a necessary function for the server's purpose.
The set provides full CRUD, publishing, duplication, analytics, sharing, theming, and response retrieval. The only noted limitation (file uploads not supported) is a feature constraint, not a completeness gap.
Available Tools
12 toolscreate_formCreate formAInspect
Create a new draft form for the authenticated user.
PREFER structured input: when the user describes a form in natural language, generate the form structure yourself (title, description, fields with proper types and labels, theme if requested) and pass it as form. This avoids extra AI inference on Brieform's side and gives you precise control.
FALLBACK: pass prompt (the user's request verbatim) only when you don't have enough context to generate the structure — Brieform's AI will handle it.
The form starts as a draft (not publicly accessible). Call publish_form to make it shareable.
Returns form_id (save for subsequent operations), preview_url (signed, 24h, read-only — share with user), and summary for natural relay.
Field types available: text, email, tel, textarea, select, radio, checkbox, rating, date, number, url, password, gdpr. File uploads are not yet supported.
| Name | Required | Description | Default |
|---|---|---|---|
| form | No | Complete form structure you've generated. Preferred input. Includes title, description, fields (with types/labels/required/placeholder/options/conditionalLogic), theme, isMultiStep, steps, successMessage, redirectUrl. | |
| prompt | No | Natural language description. Used only if `form` is not provided. Pass the user's verbatim request when uncertain about the structure. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses draft state, return fields (form_id, preview_url, summary), and unsupported file uploads. Could mention authorization or rate limits but still strong.
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?
Well-structured with first-line summary, preference guidelines, fallback, draft status, return values, and field types. Every sentence adds value, front-loaded.
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?
Given complex nested schema and no output schema, description provides comprehensive guidance including return values, field types, and relationship to publish_form. Lacks mention of performance or limits but covers essential context for agent usage.
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% and description adds significant value: explains preferred vs fallback input, field types list, note on field labels for conditional logic, and return details not in 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?
Clearly states 'Create a new draft form for the authenticated user' with specific verb and resource. Distinguishes from sibling tools by mentioning publish_form and contrasting structured vs prompt input.
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 advises when to use structured `form` vs fallback `prompt`, and notes the draft state and need to call publish_form for sharing. Provides clear 'PREFER' and 'FALLBACK' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_formDelete formADestructiveIdempotentInspect
Hard-delete a form. ALL responses are deleted as well. This is irreversible.
SAFETY: requires explicit confirm: true. If you call without confirm, you get MISSING_CONFIRMATION — re-call once the user explicitly confirms.
Idempotent: deleting an already-deleted form returns success.
Before calling, ALWAYS ask the user to confirm, especially if the form has responses. Mention the response_count from get_form or list_forms.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Must be `true`. Set only after the user has explicitly confirmed they want to permanently delete this form and all its responses. | |
| form_id | Yes | ID of the form to delete. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint: true and idempotentHint: true. The description adds crucial context: it is a hard-delete that also removes all responses, it is irreversible, and it is idempotent (deleting already-deleted form returns success). No contradiction with annotations.
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?
The description is concise yet complete: three short paragraphs with front-loaded action, safety instructions, and pre-call guidance. Every sentence adds value without redundancy.
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?
Given no output schema and only two parameters, the description covers all essential aspects: purpose, destructive behavior, safety checks, idempotency, and required user confirmation steps. It is fully adequate for an agent to use.
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 baseline is 3. The description emphasizes the `confirm` parameter's role (must be true, set only after user confirmation) and references response_count from other tools, which adds value beyond the schema's description. Thus a 4.
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?
The description begins with 'Hard-delete a form. ALL responses are deleted as well. This is irreversible.' This clearly states the verb ('delete') and resource ('form') while emphasizing the permanent, destructive nature. It distinguishes from siblings like update_form or unpublish_form.
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?
The description provides explicit when-to-use instructions: it requires explicit confirmation via `confirm: true`, warns that calling without confirm yields a MISSING_CONFIRMATION error, and instructs to always ask user for confirmation, mentioning response_count from get_form or list_forms. This guides correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
duplicate_formDuplicate formAInspect
Duplicate a form. Useful when the user says "make a similar one for X" or "copy my Y form and change it for Z".
The duplicate is created as a draft (regardless of source status). Responses are NOT copied — only structure, theme, and post-submission settings.
Optionally pass new_title to set a different title. If omitted, the duplicate gets "Copy of {original title}".
| Name | Required | Description | Default |
|---|---|---|---|
| form_id | Yes | ID of the form to duplicate. | |
| new_title | No | Title for the duplicate. Defaults to 'Copy of {original}'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Thoroughly explains key behaviors: always creates draft, does not copy responses, copies only structure/theme/post-submission settings, and default title naming. No annotations to contradict.
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?
Efficient four sentences, front-loaded with main action, no redundant information.
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?
Covers behavior and params well, but lacks mention of what the tool returns (e.g., duplicate form ID), which is a minor gap given no output schema.
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 has 100% coverage with descriptions. The description restates the new_title default but does not add significant new information 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?
Clearly states it duplicates a form, distinguishes from siblings like create_form and update_form by specifying it creates a draft copy without responses.
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?
Provides explicit use cases ('make a similar one for X' or 'copy my Y form and change it for Z'), offering clear context but no explicit when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_formGet formARead-onlyInspect
Fetch the complete structure and metadata of a form. Use this when:
You need the current form definition before modifying it (especially for PUT-style update_form).
The user asks "what's in my X form?" or "show me the fields".
You want to display details before suggesting changes.
Returns the full FormField array, theme, steps (if multi-step), URLs, and response_count.
| Name | Required | Description | Default |
|---|---|---|---|
| form_id | Yes | ID of the form to fetch. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, confirming a safe read operation. The description adds value by detailing what is returned (FormField array, theme, steps, URLs, response_count) and that it fetches 'complete structure and metadata', which goes beyond the annotation.
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 sentences plus bullet points are well-structured and front-loaded. Every sentence adds value, with no redundant or extraneous information.
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 simple one-parameter tool with no output schema, the description sufficiently explains what the tool returns and when to use it. It covers the necessary context for an agent to invoke it correctly.
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%, and the description does not add meaning beyond the schema's 'ID of the form to fetch'. Baseline 3 is appropriate as the description provides no extra semantic guidance on the parameter.
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?
The description clearly states 'Fetch the complete structure and metadata of a form' using a specific verb and resource. It distinguishes from sibling tools by explaining when to use it (e.g., before modifying) and lists detailed return fields.
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?
The description provides explicit use cases (e.g., 'before modifying', 'what's in my form?') and scenarios for using the tool. However, it does not directly contrast with similar tools like list_forms, which could provide clarity on when to use this vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_form_analyticsGet form analyticsARead-onlyInspect
Return view/submission/conversion metrics for an owned form.
Use this when the user asks "how is my form doing?", "how many responses this month?", "where is my traffic coming from?", or wants performance insights.
Includes:
Total views, total submissions, and conversion rate over the period.
Daily breakdown (views + submissions per day).
Top referrers (up to 10, sources like "twitter.com" or "direct").
Step funnel for multi-step forms (drop-off per step). Null for single-step forms.
Requires Starter plan or higher. Free-plan users get a QUOTA_EXCEEDED error.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Time window. Defaults to "30d". | |
| form_id | Yes | ID of the form to fetch analytics for. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true. The description adds value by detailing return fields (views, submissions, conversion, daily breakdown, top referrers, funnel) and special cases (null funnel for single-step forms). No contradictions.
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?
The description is well-structured with bullet points and front-loads the main purpose. It is thorough but slightly verbose; could be more concise.
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?
Despite no output schema, the description thoroughly explains return values, plan requirements, and error conditions. For a tool with 2 params and no output schema, it is highly 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?
Schema coverage is 100%, so baseline is 3. The description notes period defaults to 30d but doesn't add additional meaning beyond the schema's descriptions.
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?
The description clearly states 'Return view/submission/conversion metrics for an owned form,' specifying the verb, resource, and output. It distinguishes from siblings like get_form (structure) and get_responses (individual responses).
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 usage examples are given ('how is my form doing?', 'how many responses this month?') and the plan requirement is noted. No when-not-to-use or sibling comparisons are provided, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_responsesGet responsesARead-onlyInspect
Fetch responses submitted to a form. Use when the user asks "how many responses?", "show me submissions", "what do my leads say?", etc.
PAGINATION: results are paginated. Default 50 per page, max 200. Use cursor for next page.
LARGE DATA OPTIMIZATION: if the user has many responses (50+) OR they want to export to another tool (Notion, Google Sheets, etc.), request format: "csv_url" instead of inline JSON. Returns a signed URL (1h TTL) to a CSV file — you can hand the URL to the user or to another tool. This avoids exhausting your context window with hundreds of rows.
FILTERING: use since (ISO date) to fetch only recent responses.
Each response has a fields object keyed by field LABEL (not id) for readable AI consumption.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max responses per page. Max 200. | |
| since | No | ISO datetime. Returns only responses submitted at or after this time. | |
| cursor | No | Pagination cursor from previous response's `next_cursor` (ISO timestamp). | |
| format | No | `json`: inline data (small datasets only). `csv_url`: returns signed URL to CSV download (recommended for 50+ responses or when chaining to export tools). | json |
| form_id | Yes | ID of the form. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, consistent with fetching data. The description discloses pagination, large data optimization (csv_url), and filtering behavior, adding context beyond annotations. No contradictions.
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?
The description is well-structured with sections (PAGINATION, LARGE DATA OPTIMIZATION, FILTERING). It is mostly concise, though slightly verbose; every sentence adds value.
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?
Given 5 parameters, annotations, and no output schema, the description explains parameter usage and response structure. It covers key aspects for a data-fetching tool, leaving little ambiguity.
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%, but the description adds meaning by explaining pagination cursor, when to use csv_url, and that 'since' is ISO date. It also notes response fields use label not id, aiding agent understanding.
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?
The description clearly states it fetches responses submitted to a form and provides example user queries. It is specific (verb+resource) but does not explicitly differentiate from sibling tools like get_form or get_form_analytics.
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?
The description tells when to use the tool via example queries ('how many responses?', 'show me submissions'), and provides context on pagination, large data optimization, and filtering. It lacks explicit exclusions but covers common scenarios well.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_formsList formsARead-onlyInspect
List the authenticated user's forms. Use when:
User asks "show my forms", "what forms do I have?", or similar.
You don't know which form_id the user is referring to and need to disambiguate.
Filter by status, search by title, paginate via cursor. Results are sorted by updatedAt desc.
For each form, returns minimal metadata (id, title, status, response_count, timestamps, URLs). Use get_form if you need the full structure of a specific one.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max forms to return. Default 20, max 100. | |
| cursor | No | Pagination cursor from a previous response's `next_cursor` (an ISO timestamp). | |
| search | No | Search query matching form title or description (case-insensitive substring). | |
| status | No | Filter by form status. Default: all. | all |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and description adds behavioral details: sorting by updatedAt desc, pagination via cursor, minimal metadata returned. No contradictions.
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?
Concise, well-structured with bullet points for usage. Front-loads main action, then usage, then details. No extraneous information.
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?
Covers filtering, pagination, sorting, and return type (minimal metadata). Suggests get_form for full structure. Complete for a list operation with no output schema.
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 covers all parameters with descriptions; description adds context like case-insensitive substring search, ISO timestamp for cursor, and default values. Adds value beyond 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?
The description clearly states 'List the authenticated user's forms' with a specific verb and resource, and distinguishes it from siblings like get_form (full structure) and search-related tools.
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 says 'Use when: User asks...' and provides disambiguation context. Also tells when to use alternative (get_form for full structure).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
publish_formPublish formAIdempotentInspect
Publish a draft form so it becomes accessible at a public URL (brieform.app/f/[slug]). Once published, the form accepts submissions.
ONLY call this when the user has confirmed they want to go live. Always show the preview URL first and ask for confirmation.
If slug is provided, Brieform tries to use it. If taken, returns SLUG_TAKEN error — suggest alternatives.
If slug is omitted, Brieform auto-generates one from the form's title.
This tool is idempotent: re-publishing an already-published form is a no-op (returns current state).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Custom URL slug (lowercase letters, numbers, hyphens). If omitted, auto-generated from title. Example: 'contact-us-2026'. | |
| form_id | Yes | ID of the form to publish. | |
| regenerate_slug | No | If true, generates a new slug even if the form already has one. Use when user explicitly asks for a different URL. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint: true. The description adds extra transparency: 'Once published, the form accepts submissions', 're-publishing an already-published form is a no-op', and error handling for slug conflicts. No contradiction.
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?
The description is concise with four focused paragraphs. Each sentence adds value: purpose, usage constraint, slug details, idempotency. No redundancy.
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, so description should cover return values. It mentions returning current state on re-publish and error codes, but does not fully describe success response structure. Adequate but not 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?
Schema coverage is 100% with parameter descriptions. The description adds minimal extra beyond schema: mentions error when slug is taken and auto-generation behavior. Baseline 3 is appropriate.
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?
The description clearly states the tool's purpose: 'Publish a draft form so it becomes accessible at a public URL'. It distinguishes from siblings like 'unpublish_form' and 'create_form' by focusing on the publish action and the public URL aspect.
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 provides when-not-to-use: 'ONLY call this when the user has confirmed they want to go live. Always show the preview URL first and ask for confirmation.' Also explains slug behavior and idempotency, guiding correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_form_themeSet form themeAInspect
Apply visual theme (colors, font, border radius, submit button) to a form. Three input modes — pick exactly ONE:
A. preset_id (CHEAPEST, prefer when applicable): pick from the curated presets. Available: modern-blue, slate-professional, vibrant-green, elegant-violet, warm-rose, sunset-orange, corporate-neutral, minimal-stone. No AI inference required.
B. theme (structured): pass a complete FormTheme object. Use when the user requests something specific you can map directly (e.g. "primary color #f97316, font Inter, rounded corners").
C. prompt (fallback): pass a natural language description ("make it dark with neon green accents"). Brieform's AI builds the theme.
Use set_form_theme instead of update_form when only the theme is changing — it's faster and doesn't risk altering other fields.
| Name | Required | Description | Default |
|---|---|---|---|
| theme | No | Full FormTheme object. Use when you can map the request directly. | |
| prompt | No | Natural language theme description. Used as fallback. | |
| form_id | Yes | ID of the form to theme. | |
| preset_id | No | Pick a preset. Zero AI cost — prefer when the user's intent matches a preset name/feel. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the three input modes and their behavioral implications (e.g., 'No AI inference required' for preset_id, 'Brieform's AI builds the theme' for prompt). However, it does not mention potential side effects like overwriting existing theme settings or error handling.
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?
The description is concise and well-structured with clear sections for each input mode (A, B, C). Every sentence adds value without redundancy.
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?
The description covers the tool's purpose, input modes, and relationship to siblings. However, it does not describe the return value or confirm success, which might be needed for a mutation tool. Despite this, the high parameter coverage and clear usage make it mostly 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?
Although schema coverage is 100% (baseline 3), the description adds substantial meaning beyond the schema by grouping parameters into three exclusive modes, providing examples and usage guidance for each parameter, and listing available preset values.
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?
The description clearly states the verb 'Apply' and the resource 'visual theme to a form'. It also distinguishes from sibling tool 'update_form' by noting the specific use case for theme-only changes.
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?
The description provides explicit guidance on when to use each of the three input modes (A: preset_id, B: theme, C: prompt), including cost and applicability trade-offs. It also advises to use this tool over 'update_form' when only the theme is changing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
unpublish_formUnpublish formADestructiveIdempotentInspect
Unpublish a form. The public URL stops working and the form returns to draft status. Existing responses are preserved.
Idempotent: unpublishing a draft form is a no-op.
Useful when the user wants to "pause" a form, fix an issue, or stop receiving submissions temporarily. The slug is preserved so re-publishing later uses the same URL.
| Name | Required | Description | Default |
|---|---|---|---|
| form_id | Yes | ID of the form to unpublish. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: idempotency is described, result (preserves responses, slug stays same). No contradiction with annotations.
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 paragraphs, each sentence adds value. No fluff, well-organized.
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?
Covers purpose, effects, idempotency, use case. No output schema needed; all relevant info present.
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 (form_id) with clear schema description. Description adds no extra parameter info, but schema coverage is 100%, so baseline 3.
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?
Clearly states the action ('Unpublish a form') and explains the consequences: public URL stops working, form returns to draft, responses preserved. Distinguishes from sibling publish_form.
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 mentions when to use ('pause', fix issue, stop submissions) and notes idempotency (unpublishing draft is no-op). Could contrast with delete_form but not necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_formUpdate formADestructiveInspect
Modify an existing form. Two modes:
MODE A (structured, preferred): pass the full updated form structure. Use this when you have the form in conversation context — fetch it via get_form first if needed, apply the user's changes, send the new structure. PUT semantics: replaces all fields/theme/etc. Include each field's id from get_form to preserve response history for existing fields.
MODE B (prompt, fallback): pass prompt describing the change ("add a budget field", "make the message field optional", "change theme to dark blue"). Brieform's AI uses the current form as context and applies the modification. ⚠️ WARNING: prompt mode may silently modify unrelated parts of the form (options, isMultiStep, steps) beyond what was requested. Use MODE A for precise, targeted changes.
If the form is currently published, the changes go LIVE IMMEDIATELY — the summary returned will include a warning. Inform the user.
Returns the same shape as create_form, with the actual status reflecting if the form is still draft or already published.
| Name | Required | Description | Default |
|---|---|---|---|
| form | No | Full updated form structure. PUT semantics: replaces the entire form definition. Preferred mode. | |
| prompt | No | Natural language description of the change. Used only if `form` is not provided. | |
| form_id | Yes | ID of the form to update. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond destructiveHint=true, description reveals that published changes go live immediately with warning, and MODE B may silently modify unrelated parts. Provides critical context annotations alone don't cover.
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?
Well-structured with labeled modes, warnings in bold, and clear instructions. Each sentence serves a purpose without redundancy.
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?
Despite no output schema, description covers the return shape (same as create_form) and status implications. Addresses key scenarios: fetching form first, mode selection, published impact, and fallback behavior.
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%, baseline 3. Description adds value: explains PUT semantics for 'form', need to include field IDs for response history, and that 'prompt' is only used if 'form' absent.
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?
The description clearly states it modifies an existing form and distinguishes two distinct modes (structured and prompt). It differentiates from siblings like create_form (create) and delete_form (delete).
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 guidance: MODE A is preferred when form context is available, MODE B is a fallback with warnings about unintended changes. Also advises fetching with get_form first and informs about published forms going live immediately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!