Skip to main content
Glama

List form submissions

list_submissions
Read-onlyIdempotent

List form submissions for a site. Returns summaries (name, email, form_type, source — which page/form the submission came from, e.g. a specific job position — is_read, preview of message, and attachments — any uploaded files as {field, name, url} with DURABLE download links safe to paste into an exported Google Sheet / CSV) plus a monthly_counter block (used / limit / over_limit / locked / month / plan). The allowance is per calendar month; a month's locked submissions stay locked after it ends. Capture is NEVER gated on any plan: every submission is stored and forwarded to the site's webhook regardless of the count. Each one is also emailed to the site owner's account address — on by default, switched per site from the dashboard's Submissions panel; it can't go to a different address (for that, set the form's integration.webhookUrl). What the allowance controls is READING. On Free, submissions past a month's allowance come back with locked: true — created_at and form_type only, with name, email, description and attachments withheld; say plainly that the submission arrived and was kept. Do NOT imply anything was lost or dropped, and do not pitch a plan change on the back of it, and do not try to recover a locked submission through read_submission or the contact tools — they withhold it too. Pro never locks. Filter by form_type, unread_only, or since-timestamp. form_type is free-form text set by whoever built the form — the built-in presets are contact, waitlist, newsletter, rsvp, quote, application and custom, but templates ship their own (e.g. booking, tour-request, commission-enquiry), so read the form_type values off an unfiltered call before filtering on one. Use read_submission to fetch the full payload of one.

Input Schema

NameRequiredDescriptionDefault
limitNo
sinceNo
site_idYes
form_typeNo
unread_onlyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, it discloses detailed behavior: return summary fields, durable attachment links, the `monthly_counter` structure, per-calendar-month allowance semantics, locked-submission behavior on Free, and the fact that capture is never gated on plan. It also gives important agent-facing guidance not to imply data was lost or to pitch a plan change, which is unusually rich behavioral context.

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 description is front-loaded with purpose and return shape, then proceeds through allowance and filtering details. It is long, but most sentences carry non-obvious behavioral or policy information that an agent needs in order to respond correctly to locked submissions.

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, so the description carries the burden of explaining return values, and it does so in detail: summary fields, attachment links, and the `monthly_counter` block. It also explains the complex locked-submission behavior and filter semantics thoroughly enough for an agent to call the tool correctly.

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 0%, and the description adds useful meaning for three of five parameters: `form_type`, `unread_only`, and `since`. However, it does not explain `limit` or add much beyond the obvious for `site_id`, so it only partially compensates for the lack of schema descriptions.

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 starts with a specific verb and resource: "List form submissions for a site." It clearly distinguishes itself from `read_submission` by saying this returns summaries and by explicitly directing the agent to `read_submission` for the full payload of one submission.

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?

It explicitly names when to use this tool versus `read_submission`, lists the available filters, and warns that `form_type` is free-form so an unfiltered call should be read before filtering. It also explains that locked submissions cannot be recovered through `read_submission` or contact tools, which is a clear usage constraint.

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