Skip to main content
Glama

Connect a form to Xodia Forms

connect_form

Turns a form in the site's code into a Xodia form, the same way as Send to Xodia Forms in Xodia's Settings panel: it writes action, method="post", data-xodia-form, success and error text, a hidden spam field and the page field onto the form, adds the site helper, and makes the form's record (recipients: you, the member whose AI this is; the Turnstile check on for paid plans). Pick the form with index, line or match, or leave them out when the file has one form. Works on React (.tsx, .jsx) and plain HTML (.html) files. Keep the form's field names, keep or add a role="status" (or data-xodia-status) element for the answer, and never add an onSubmit or a mailto: action; a form with its own submit code is connected but flagged, so remove that code. Refused for a form that is already connected (form_already_connected), a file with no such form, other file types, and forms with no named fields. Writes unsaved changes the user reviews and saves in Xodia; recipients, Turnstile, notifications and webhooks are changed in Xodia.

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": {
      "file": "<file>",
      "projectId": "<projectId>"
    },
    "name": "connect_form"
  }
}

Input Schema

NameRequiredDescriptionDefault
fileYesThe file the form is in, relative to the project root (src/pages/Contact.tsx, contact.html)
lineNoA line of the form in the file (its <form> tag or any line inside it), as read_file numbers them
nameNoThe form's name in Xodia (Contact form); default from the data-xodia-connect value or the file name
indexNoWhich form in the file, 1 for the first. Give one of index, line or match, or none when the file has one form
matchNoThe form's data-xodia-connect value, id, name or aria-label, as written in the code
branchNoOptional branch; default the branch the workspace has open
projectIdYesProject id from list_projects

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations (readOnly=false, destructive=false, openWorld=false), the description discloses the precise side effects: specific attributes written, a site helper added, a form record created with recipients and Turnstile defaults, and that changes are unsaved until the user reviews and saves in Xodia. It also surfaces the form_already_connected refusal code, the "connected but flagged" outcome for forms with their own submit code, and hard constraints (no onSubmit, no mailto:). This is unusually rich behavioral disclosure 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?

The action and its constraints are front-loaded and nearly every clause carries information (written attributes, selector rules, constraints, refusals). However, the second sentence is a long run-on packing three distinct instructions together, which makes it harder to scan than it needs to be.

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 7-parameter mutation tool with no output schema, the description covers side effects, review/save flow, refusal cases, and follow-up configuration well enough to call it correctly. The remaining gap is the `branch` parameter and any indication of what the tool returns on success.

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%, so the baseline is 3. The description restates the index/line/match selection rule that the schema already documents, and adds only light meaning for `name` (the form's name in Xodia) and `file` (the file with the one form). It does not explain `branch` or clarify precedence when multiple selectors are supplied.

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?

The opening clause gives a specific verb and resource ("Turns a form in the site's code into a Xodia form") and immediately enumerates exactly what it writes onto the form. It also bounds the resource space (React .tsx/.jsx and plain .html files), so an agent can distinguish this from generic writers like write_file or edit_file.

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?

It states the operational context (equivalent to Send to Xodia Forms in Xodia's Settings) and gives concrete selection guidance for index/line/match. It also names when NOT to expect success (already connected, no such form, other file types, no named fields) and redirects post-connection configuration (recipients, Turnstile, notifications, webhooks) to Xodia. It stops short of naming a sibling tool to use instead for adjacent tasks, so not a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources