Skip to main content
Glama
Sign In

Paperform

by com.paperform
OverviewDiscussionsAdmin

List items

list
Read-onlyIdempotent

Browse a space, or list the records inside an item. Every id returned is ready to pass to the other tools.

Browsing a space (one tree per space): • list({ space_id }) → the top of the space: { space, folder, items: [{ id, type, title, path, url?, view_url?, edit_url? }] }. The space's forms, documents and workflows are in its folder "@platform/". Pass any folder id as folder to go deeper. • list({ space_id, type: "form" }) → every form in the space. type "document" | "workflow" lists every item of that type. • list({ space_id, type: "document_template" }) → reusable document templates (search filters by name). Create a document from one with create. • list({ space_id, type: "connection" }) → the app connections workflows can use. Credentials are never returned. Only connections this space can use are listed: the space's own, ones shared with it, and ones shared with the whole team; a teammate's Private connection never appears. visibility is in the Stepper Connections page's words: team = "Public" (everyone in the team), restricted = "Shared" (the spaces in shared_with), private = "Private" (owned by this space and usable by every workflow in it, as the space's own platform connection is; nothing needs sharing to use it here). owned_by_you says the user connected it, owner_name who did, and can_share whether the user can change who it is shared with (share_connection). Pass mine: true to list instead every account the user connected themselves, wherever it is shared, their own platform connection included, each with usable_here saying whether this space can use it. If the user says they connected an account that is not listed here, list again with mine: true and offer to share it here with share_connection; if it is not theirs either, ask whoever connected it to share it with this space (share_connection, or Stepper's Connections page: its row's menu → Sharing). • list({ space_id, type: "app" }) → the apps workflow steps can use, each with its action and trigger keys (search filters by name). Fetch an app id for its connections and full schema.

Records inside an item (pass parent; the parent's space is used): • form → submissions (default). Forms: status "partial" for abandoned ones; product, coupon, form_webhook. • folder → the folder's contents (default; the same listing as list({ folder })), or its items by type; type "document_webhook" for a Papersign folder's document webhooks. • workflow → workflow_run, newest first.

Every form, document and workflow carries two links for the user: view_url, the live public page people open (null for documents and workflows, which have no public page), and edit_url, where the user edits it in Paperform once signed in. url is view_url when there is one, else edit_url. A form also carries submissions_url and duplicate_url. Folders carry url alone, and rows from list with type "document" or "workflow" carry no links: fetch the id for them.

Paging: limit, then the next_cursor a page reports as cursor.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list"
  }
}

Input Schema

NameRequiredDescriptionDefault
mineNoConnections only: list the accounts the user connected themselves, wherever they are shared, rather than the ones this space can use.
typeNoWhat to list. See the description for which types need parent.
limitNoPage size.
cursorNoThe next_cursor from the previous page.
folderNoA folder id to list inside.
parentNoAn item id (form, folder or workflow) whose records to list.
searchNoName filter, for forms, workflows and document templates.
statusNoSubmissions only: "partial" lists unfinished ones — never present those as responses.
space_idNoThe space to act in — a key of whoami's `spaces`. Not needed when another argument already carries an id from that space, or when this connection reaches only one space.

Output Schema

NameRequiredDescriptionDefault
csvNo
dataNo
itemsNo
spaceNo
folderNo
has_moreNo
next_cursorNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered and the description's job is to add context beyond that. It does add real behavior: credentials never returned, connection visibility semantics across space/team/private sharing, link nullability for documents and workflows, and cursor paging. That's meaningful but it sits inside an unusually long description, so the marginal value per sentence is diluted.

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?

Excellent structure with a front-loaded summary and two clearly labeled bullet groups for the two browsing modes. The main weakness is bulk: the connection-visibility paragraph is very dense, embeds remediation steps that arguably belong to share_connection, and slows an agent scanning for the core call patterns.

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 9-parameter, 13-value-enum tool that fans out across many item types, the description covers every routing decision, default, and paging mechanism an agent needs. An output schema exists, so the inline return-shape notes are redundant but harmless and help with type selection.

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?

Schema coverage is 100%, so baseline would be 3, but the description adds genuine meaning the schema cannot: the type × context matrix (which types require parent, which require space_id), the defaults when type is omitted, and how mine: true reinterprets the connection listing. It also clarifies that space_id is unnecessary when another argument already carries a space-scoped id.

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?

Opens with a concrete verb+resource split: browsing a space versus listing records inside an item, and immediately names the return shape. It also separates itself from siblings by noting when to 'fetch the id' instead and where 'search filters by name'.

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?

Provides explicit when-to-use routing for each mode: list({ space_id }) for the tree top, type-scoped listings, parent-scoped record listings with stated defaults (submissions, folder contents). It even handles the edge case where a user's connection isn't listed, directing to mine: true and share_connection.

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

All Paperform 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