Paperform

List parameter options

list_parameter_options

Read-onlyIdempotent

The choices for one dropdown parameter of a workflow step (action) or trigger, read from the connected account. Pass exactly one of action or trigger, and the values chosen so far as input (a table list needs its base, for instance).

Returns { status, data: [{ id, label }] }. Write the choice into the source as option { id: "…", label: "…" }. A value typed in rather than picked is the editor's "Custom" choice (offered on action steps, not triggers): option { id: "<text, may hold {{refs}}>", label: "…", isCustom: true }.

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": {
      "app": "<app>",
      "connection": "<connection>",
      "parameter": "<parameter>"
    },
    "name": "list_parameter_options"
  }
}

Input Schema

Name	Required	Description
`app`	Yes	The app id, exactly as list({ type: "app" }) returned it.
`input`	No	The parameter values chosen so far, key → value (plain values, not the source forms). Later parameters often depend on earlier ones.
`action`	No	An action key, from fetch on the app.
`trigger`	No	A trigger key, from fetch on the app.
`parameter`	Yes	The key of the dropdown parameter.
`connection`	Yes	A connection id for this app, from list({ type: "connection" }) or fetch on the app.

Output Schema

Name	Required	Description	Default
`data`	No
`status`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so safety is covered. The description does add valuable context beyond them: the option-writing form, and the Custom-choice rule that applies to action steps but not triggers. It says little about what a non-ok status means or what happens when no options exist.

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?

Three sentences, front-loaded with the purpose, then calling rule, then result handling. No filler, though the second sentence is densely packed and takes a second read. Efficient overall.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only lookup feeding a parameter editor, the description covers purpose, exclusivity, dependent inputs, and how to render the chosen option. With an output schema present it need not detail return values. Only failure/empty-result behavior is unaddressed.

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 100%, so per-field meaning is already documented. The description nonetheless contributes semantics the schema lacks: the mutual exclusivity of action and trigger, and the reminder that input holds plain values rather than source forms. Good added value above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource and operation: the choice list for one dropdown parameter of a workflow action or trigger, read from the connected account. Action-vs-trigger scope is explicit. It does not name the closest sibling (resolve_parameters), so differentiation still requires inference, keeping it short of 5.

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 a concrete calling rule (exactly one of action or trigger) and explains that prior parameter values go in 'input', with an example of dependency (a table list needs its base). It also explains the Custom fallback. Missing is an explicit statement of when to call this versus resolve_parameters or fetch.

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

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