Pixelesq

Get form submissions

get_form_submissions

Read-only

Gets submissions for a form (find the formId via list_forms), newest first. By default (status inbox) spam is left out and each row carries its status: ok, or suspect when the spam filter was unsure (spamReason says why). status ok, suspect or spam lists only that kind; all lists every row. Unfinished submissions (partial: true, saved when a visitor stopped part way through a multi-step form) are left out unless includePartial is true, and pagination.total still counts them. counts holds the form's totals per status, partial rows included: counts.ok is the number of real leads to report. Returns { results: [{ id, submission, createdAt, status, spamReason, partial }], pagination: { offset, limit, total }, counts: { ok, suspect, spam } } where submission is the submitted field values as JSON. Default limit 20. Note: submissions contain user-entered PII.

Input Schema

Name	Required	Description	Default
`limit`	No
`formId`	Yes	The form ID
`offset`	No
`status`	No	inbox (default) is everything but spam; ok, suspect or spam lists only that kind; all lists every row	inbox
`projectId`	Yes	The project ID
`includePartial`	No	Also return unfinished submissions (partial: true). Default false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedOct 22, 2026

addedInput schema / properties / includePartial

Added value: +{
+  "default": false,
+  "description": "Also return unfinished submissions (partial: true). Default false.",
+  "type": "boolean"
+}

addedInput schema / properties / limit / maximum
```
Added value: +100
```
addedInput schema / properties / limit / minimum
```
Added value: +1
```

changedInput schema / properties / limit / type

Previous value: -"number"New value: +"integer"

addedInput schema / properties / offset / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / offset / minimum
```
Added value: +0
```

changedInput schema / properties / offset / type

Previous value: -"number"New value: +"integer"

addedInput schema / properties / status

Added value: +{
+  "default": "inbox",
+  "description": "inbox (default) is everything but spam; ok, suspect or spam lists only that kind; all lists every row",
+  "enum": [
+    "inbox",
+    "ok",
+    "suspect",
+    "spam",
+    "all"
+  ],
+  "type": "string"
+}

First observedOct 17, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well beyond the readOnly/destructive annotations: explains spam filtering, that rows carry status and spamReason, that partial submissions are hidden by default while pagination.total still counts them, that counts includes partials, and flags that results contain user-entered PII. This is rich behavioral context an agent cannot infer from annotations alone.

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-loaded with the core action and formId guidance, and every clause earns its place by explaining filtering/count behavior. It is dense with nested parentheticals, which slightly hurts scanability but not correctness.

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?

Despite having no output schema, the description fully specifies the return shape (results, pagination, counts) and field meanings. Combined with the PII warning, an agent has everything needed to call and interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

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

Although schema coverage is 67%, the description clarifies the non-obvious semantics: the status enum's effect on filtering, the interaction between includePartial and pagination.total, the meaning of counts.ok, and the default limit of 20. This adds meaningful interpretation beyond the raw 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 resource ('Gets submissions for a form'), names the sibling (list_forms) that supplies the formId, and specifies ordering (newest first). An agent can identify and scope this tool without opening the schema.

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 to list_forms to obtain formId, and defines when each status value applies (inbox default excludes spam, ok/suspect/spam list one kind, all lists everything). It also states exactly when to use includePartial to surface unfinished submissions.

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

All Pixelesq tools Inspect

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

Need Help?