Skip to main content
Glama
Sign In

Checkout Page

by com.checkoutpage
OverviewDiscussionsAdmin

get_submission

Read-only

Retrieve a single form submission by ID from your Checkout Page account. Pass livemode: false to read test-mode records.

Returns one submission record directly by ID, without pagination.

Use list_submissions first if you need to discover a submission ID by customer email, customer name, page, customer ID, or date range.

If the submission ID does not exist, returns a 404 error: "Submission not found".

Example uses:

  • "Fetch submission 6812fe6e9f39b6760576f01c"

  • "Show me the full contents of this submission"

  • "Check which page this submission came from"

  • "What billing and shipping details were captured on this form?"

This tool is read-only. You cannot edit or delete submissions through MCP. For modification requests, show what was submitted and explain that submission management must happen in the Checkout Page dashboard.

Input Schema

NameRequiredDescriptionDefault
livemodeNoSet to false to read test-mode records (created while a page was in test mode). Defaults to live records.
submissionIdYesThe ID of the submission to retrieve. Use `list_submissions` first if you need to discover a submission ID by email, name, page, customer, or date range.

Output Schema

NameRequiredDescriptionDefault
dataYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • addedOutput schema / properties / data / properties / canceledAt
      Added value: +{
+  "anyOf": [
+    {
+      "format": "date-time",
+      "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "ISO 8601 timestamp when the submission was canceled."
+}
    • addedOutput schema / properties / data / properties / canceledBy
      Added value: +{
+  "description": "ID of the dashboard user who canceled the submission. Absent when it was canceled through the seller API.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • addedOutput schema / properties / data / properties / canceledByApiKey
      Added value: +{
+  "description": "ID of the API key that canceled the submission, when it was canceled through the seller API. The key may have been deleted since; `canceledByApiKeyName` keeps its name.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • addedOutput schema / properties / data / properties / canceledByApiKeyName
      Added value: +{
+  "description": "Name of the API key that canceled the submission, as it was at the time. Kept when the key is deleted later.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • addedOutput schema / properties / data / properties / canceledReason
      Added value: +{
+  "description": "The reason given when the submission was canceled.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • addedOutput schema / properties / data / properties / orderStatus
      Added value: +{
+  "default": "active",
+  "description": "Lifecycle status set by the seller. Valid values: active, canceled. `canceled` means the seller canceled the submission: it no longer counts toward \"Prevent duplicate submissions\" and its files left the customer portal.",
+  "enum": [
+    "active",
+    "canceled"
+  ],
+  "type": "string"
+}
    • changedOutput schema / properties / data / required
      Previous value: -[
-  "id",
-  "status",
-  "createdAt",
-  "updatedAt",
-  "dashboardUrl"
-]New value: +[
+  "id",
+  "status",
+  "orderStatus",
+  "createdAt",
+  "updatedAt",
+  "dashboardUrl"
+]
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, yet the description still adds real behavior: the 404 "Submission not found" outcome, the absence of pagination, and the livemode/test-mode switch semantics. It also confirms the write boundary and points to the dashboard as the alternative, which prevents an agent from attempting unsupported edits.

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 scope, followed by the routing rule and the read-only boundary. The four example utterances are somewhat redundant given the usage paragraph, but they are short and help match colloquial user requests. Slight over-length keeps it off a 5.

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?

An output schema exists, so return values needn't be spelled out, and the description correctly focuses on scope, error behavior, and the read-only constraint. Nothing an agent needs to call this correctly – ID format expectations, test vs live selection, missing-record behavior – is absent.

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% – both `submissionId` (with its 24-hex pattern and list-first hint) and `livemode` are fully documented in the schema. The description restates the livemode test-mode behavior and the list-first advice, which reinforces rather than adds new semantics. Baseline 3 is correct where the schema already carries the load.

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 ("Retrieve a single form submission by ID") plus the account scope ("your Checkout Page account"). It also names the sibling `list_submissions` and clearly delineates that this tool is the ID-based single-record fetch, so an agent can distinguish it without opening a 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 tells the agent to call `list_submissions` first to discover an ID by email, name, page, customer ID, or date range. It also gives the when-not path: modification requests cannot be done here and must be handled in the Checkout Page dashboard.

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

All Checkout Page 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