Skip to main content
Glama
Sign In

Faldaro

by com.faldaro
OverviewDiscussionsAdmin

create_submission

Create a submission for a form. data maps field slugs to values — send only what the user provided; computed fields are derived server-side and anything sent for them is ignored. Use draft:true to save partially-filled work (skips required-field validation). Check the form’s field slugs via get_form_draft or evaluate_submission first. Requires submission:write.

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": {
      "formId": "<formId>",
      "data": "<data>"
    },
    "name": "create_submission"
  }
}

Input Schema

NameRequiredDescriptionDefault
dataYesField slug → value.
draftNoSave as draft (default false).
formIdYesThe form id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The description substantially enriches the sparse annotations. It discloses that computed fields are derived server-side and ignored if sent, that draft mode skips required-field validation, and that the operation needs `submission:write` permission. These are behavioral details not visible in the schema or annotations.

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?

The description is compact and front-loaded. The first sentence states the core purpose, and every following sentence adds useful information: data semantics, draft behavior, prerequisite lookup, and permission requirement. There is no fluff or redundancy.

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?

For a 3-parameter mutation with no output schemahol, this description covers all essential context: what is created, how data maps to fields, draft behavior, server-side handling, needed permission, and prerequisite tools. No critical operational gap remains.

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 goes further by explaining `data` as slug→value with computed-field caveats, and by clarifying that `draft:true` skips required-field validation. It does not add much beyond the schema for `formId`, but the main parameters get meaningful elaboration.

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 description opens with a specific verb and resource: 'Create a submission for a form.' It clearly distinguishes this from sibling tools like update_submission, list_submissions, and transition_submission by naming the creation action and adding form-specific context.

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 gives concrete guidance: use `draft:true` for partially-filled work and check field slugs via get_form_draft or evaluate_submission first. However, it does not explicitly state when to prefer a sibling tool such as update_submission for an existing submission, so it stops short of full when-not guidance.

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

All Faldaro toolsInspect
Try in Browser
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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources