Skip to main content
Glama

Fetch item

fetch
Read-onlyIdempotent

Read one item in full by id. Returns { id, title, text, url, view_url, edit_url, metadata }: text is a readable rendering, metadata the record without storage housekeeping. 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. A view (#preview, say) and a record inside an item (a submission, a run) carry url alone.

By type: • submission — every answer. • form — its settings and live state. Add "#fields" to the id for the question set (the keys submission answers use), "#source" or "#outline" for its source, "#preview" for a five-minute link that renders the draft in a browser (not submittable), or "#options" for the payment accounts and calendars that can be attached to it and where to connect new ones. • product, coupon — one of a form's products or coupons. • document — status, folder and each participant's signing state. Add "#download" to a completed document's id for a link to the signed PDF. • workflow — status (draft | live | paused, the Stepper editor's Draft, Live and Paused badges); has_unpublished_changes, whether the draft differs from the live version (a draft always exists once it has been published, so its presence says nothing; list rows leave it out, so fetch the workflow for it); live_version and draft_version, each a version number and validation state (not its steps), where version status active is the live version (the editor's "Active" in Version History), then draft, archived or publishing; is_component_library; and triggers (trigger_id for run_workflow). "#source" is its definition as editable text (the draft, else the live version; read get_help topic "workflow"), "#outline" its trigger/step/rule ids, "#samples" each node's saved example output in full, keyed by node id: what the editor's "Choose an example" and "Run test action" saved, what test_action and load_trigger_samples stored when given workflow and node, and what edit_source and create stored on their own (#source shows them trimmed under ::: outputs). • app — a workflow app: its actions and triggers (each trigger with the type a workflow trigger on it must carry), and the connections usable in the space, with the same visibility as list({ type: "connection" }). "#schema" is the app's full definition. Stepper's own apps (platform, ai, email, approvals, paperform, papersign) run on the space's platform connection, which fetch on the app returns under connections; list({ type: "connection" }) does not list it. • workflow_run — status, settled, and steps: each step's node, inputs (secrets redacted), output or error. While not settled it carries retry_after (seconds until it is worth reading again) and, for a step waiting on an approval or delay, waiting_on; a paused run carries a note on what resumes it. A run just started may answer visible: false with retry_after until it syncs. run_state.status is the editor's run badge: pending | running | sleeping (backing off before a retry) | paused | completed | failed | crashed | terminated (someone pressed Cancel on the run page). A paused run's pausedReason is not_enough_credits ("Insufficient Credits"), step_count_exceeded ("Step Limit Reached"), run_max_steps_exceeded ("Run Step Limit Reached"), workflow_paused ("Workflow Paused") or manual ("Manually Paused"). A step's status is trigger | success | error | waiting (an approval, delay or child run not back yet; the editor shows "loading..."). Resuming, pausing or cancelling a run is done on Stepper's run page, not here. • folder — the folder and what is in it.

• connection — an app connection: who it is shared with (shared_with, visibility as in list), whether the user owns it and can change that, and — only when the user owns it — used_by: each workflow the user can see that uses it, its space, and whether its live version does; used_elsewhere/live_elsewhere say workflows in spaces the user cannot see use it too (never named). Credentials are never returned.

Webhooks and partial submissions are read with list; their list rows are the full records.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

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

Input Schema

NameRequiredDescriptionDefault
idYesAn id exactly as search, list or fetch returned it. Ids are opaque — never build or edit one.

Output Schema

NameRequiredDescriptionDefault
idNo
urlNo
textNo
titleNo
edit_urlNo
metadataNo
view_urlNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / edit_url
      Added value: +{}
    • addedOutput schema / properties / view_url
      Added value: +{}
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds real behavioral context: secrets are redacted in run inputs, credentials are never returned for connections, run visibility is limited to workflows the user can see (used_elsewhere never named), a just-started run may answer visible: false with retry_after, and a #preview link expires in five minutes. These are constraints an agent cannot 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 first sentence is well front-loaded and the type-by-type bullets are scannable, so structure is sound. But the description runs several hundred words and much of the return-value enumeration (field-level detail for workflow_run, connection, app) restates what the existing output schema can carry, so not every sentence earns its place.

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 polymorphic fetch over ten item types, the description covers the cases an agent would otherwise get wrong: which types have no public page, which fragments exist per type, how draft vs live versions are expressed, and what is withheld for permissions. Nothing needed to call it correctly appears to be missing.

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?

The single parameter has 100% schema coverage, and the description goes beyond it by documenting id fragment suffixes (#fields, #source, #outline, #preview, #options, #samples, #download, #schema) that materially change what is returned. That is genuinely additive, though it sits in mild tension with the schema's "Ids are opaque — never build or edit one," which the description never reconciles.

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?

"Read one item in full by id" gives a specific verb, resource and scope, then immediately enumerates the return shape ({ id, title, text, url, view_url, edit_url, metadata }). The per-type bullet list (submission, form, product, coupon, document, workflow, app, workflow_run, folder, connection) makes it unmistakable versus list/search, which return rows rather than full records.

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 gates several cases explicitly: "rows from list with type 'document' or 'workflow' carry no links: fetch the id for them," and "Webhooks and partial submissions are read with list." It also redirects to get_help for workflow source and to the run page for resuming/pausing/cancelling. What's missing is a single upfront statement of when to fetch instead of search or list for the common item case.

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