Skip to main content
Glama

List recent submissions

list_recent_submissions
Read-only

The delivery status of recent submissions, any that need review, and any held because they came from a website the form does not allow yet, newest first. Status only: pending or processing means In delivery, synced means Delivered to Sheet (or to the form's other Google output), failed means another delivery attempt is scheduled, dead_letter means Needs review, and needsReview lists only those (never a delivery with another attempt scheduled), the same count list_forms and the console give. acceptedAt is when Webtzm accepted a submission and deliveredAt when Webtzm wrote it to Google (null until then). operation says what a submission does to its Sheet row: insert adds a row, update changes the row of the entry named by targetSubmissionId, archive removes that row. An insert whose row was later removed has removed true and removedAt (when the removal reached the Sheet, or was accepted while still on its way); its own status stays synced because it was delivered. Each needs-review item says where it broke and which reversible fix applies (retry_delivery, or Reconnect Google in the console). Held items name the website; allow_website releases them. Each submission's receipt is the confirmation email to the person who submitted (null when the form sends none): pending, sent, retrying, failed, or skipped with a reason and a summary - recipient_receipt_cap means that address already had the daily maximum of receipts from this form, which resets at 00:00 UTC and needs no fix. For older submissions pass nextCursor back as cursor; get_submission reads one submission by id. What people answered is never included.

Input Schema

NameRequiredDescriptionDefault
limitNoHow many recent submissions to return, 1 to 20. Defaults to 10.
cursorNoWhere to continue: the nextCursor of the previous answer. Omit for the newest.
form_idNoOnly this form's submissions. Omit for the whole workspace.

Output Schema

NameRequiredDescriptionDefault
heldNo
recentYes
nextCursorNo
needsReviewYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / cursor
      Added value: +{
      +  "description": "Where to continue: the nextCursor of the previous answer. Omit for the newest.",
      +  "maxLength": 400,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedOutput schema / properties / nextCursor
      Added value: +{
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
  2. Changed1 schema field changed
    • addedOutput schema / properties / held
      Added value: +{
      +  "type": "array"
      +}
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnly/non-destructive annotations, it discloses rich domain behavior: exact status mappings, what needsReview excludes, how removed inserts retain synced status, receipt states including recipient_receipt_cap, and that answers are never included. This is substantial context an agent could not infer from annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is front-loaded and nearly every clause carries domain meaning, but it is delivered as one very long run-on paragraph. The density makes it harder to scan than it needs to be for a list tool with only three parameters.

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?

Given the rich status model, receipt semantics, and output schema, the description is complete enough for an agent to interpret results correctly. It covers pagination, filtering scope, and the important caveat that answers are excluded.

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 already 100%, so the baseline is 3. The description adds useful meaning by tying cursor to the previous answer's nextCursor and clarifying that form_id scopes to one form while omission covers the workspace.

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 clearly identifies the resource (recent submissions), the main payload (delivery status), and the three triage views (delivered, needs review, held), plus newest-first ordering. It also distinguishes itself from get_submission by saying that tool reads one submission by id.

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 explicit continuation guidance ('For older submissions pass nextCursor back as cursor'), names get_submission as the single-record alternative, and explains that held items can be released with allow_website. It lacks a broad 'use this when' statement, but the usage context is clear.

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