Skip to main content
Glama
Sign In

BootForm

by com.bootform
OverviewDiscussionsAdmin

Get a form's HTML snippet

bootform_get_snippet
Read-onlyIdempotent

Returns a ready-to-paste HTML snippet for one of the connected account's existing forms. A read: it changes nothing. Put the snippet on the person's page where the form should appear. Keep its hidden honeypot field: while the form's Honeypot switch is on, a post without it lands in spam. If the form has Turnstile set up in the dashboard, pass include_turnstile: true, or every post from the page is refused; include_powered_by adds a one-line credit. A new form comes with its snippet from bootform_create_form; use this one for an existing form or to change its fields.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "form_id": "<form_id>"
    },
    "name": "bootform_get_snippet"
  }
}

Input Schema

NameRequiredDescriptionDefault
fieldsNoField names to include, e.g. ["name", "email", "message"]. Defaults to ["name","email","message"].
form_idYesThe form's id
include_honeypotNoInclude the hidden honeypot field, under the form's own name (each form has its own; it can be changed in the dashboard's spam protection settings). Always included while the form's Honeypot switch is on (the default), because a submission without the field is then marked spam; turn the switch off in the dashboard first if the page cannot carry it.
include_turnstileNoInclude Turnstile widget markup, if the form has a CAPTCHA configured
include_powered_byNoInclude a small "Powered by BootForm" credit (one line, linking to bootform.com) under the form. Optional; leave it out if the site owner does not want it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is known. The description adds useful operational consequences that annotations cannot express: pages missing the honeypot field get spam-marked, and missing Turnstile markup causes posts to be refused. However it says nothing about snippet size, formatting, or whether the snippet expires, so the behavioral picture is good but not full.

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-loads the core purpose and the read-only nature in the first two sentences, then adds conditional requirements. It is longer than typical but nearly every sentence carries an actionable warning; the create-vs-existing routing at the end could have been placed earlier.

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

Completeness5/5

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

There is no output schema, and the description still tells the agent what is returned (HTML) and how to deploy it (paste where the form should appear). Combined with its failure-mode warnings and schema-level parameter documentation, 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.

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description earns a bump by explaining the consequence of include_turnstile (every post refused if omitted) and the effect of include_powered_by, which is more actionable than the schema's phrasing alone. The 'fields' parameter is left entirely to the schema.

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 output artifact ('Returns a ready-to-paste HTML snippet') scoped to 'one of the connected account's existing forms', and explicitly distinguishes itself from bootform_create_form, which supplies the snippet for new forms.

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 routes the agent: use this for an existing form or to change its fields, use bootform_create_form for a new one. It also gives conditional instructions for include_turnstile and include_powered_by, so the agent knows when each flag is required versus optional.

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

All BootForm toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources