Skip to main content
Glama

Resolve step parameters

resolve_parameters
Read-onlyIdempotent

The parameters a workflow step (action) or trigger takes, resolved against a connection and the values chosen so far. Pass exactly one of action or trigger.

Returns { status, data: [{ key, label, type, required, default, options, dynamic, dependent, … }] }. default is what the editor pre-fills. edit_source and create fill it in only for a field the app's #schema declares with a plain default (text, number, true/false, date, multiple-value text, dropdown or multiple dropdown), on a step whose params the edit writes; a field listed here but absent from the #schema (computed from earlier values), or an object or reference field, is not filled, so write its default yourself. When the workflow is published, a field this lists as html is marked so inserted answers are HTML-escaped, unless the param says options { encodeHTML: false }. A required key left out with nothing filled is refused. A static dropdown carries its choices in options; message and error fields only show text and take no value. An embedded field (a file picker, such as Google's) can't be filled by typing an id: picking the file is what gives the connection access to it. Such a field carries pick_url when you own the connection: give that link to the user to choose the file in their browser, then call again with the same input and the field carries picked { id, label }; write that option as the param's value. Without pick_url, only the connection's owner can choose the file. dynamic marks a dropdown whose options come from the connected account (read them with list_parameter_options); dependent marks a parameter whose shape changes with the ones it depends on. The list itself grows as values are set: parameters absent from the first answer appear once the ones before them have values, so after choosing any value call again with the full input so far, and stop when an answer repeats the previous one.

Example: resolve_parameters({ app: "12:app:airtable-1", action: "findRecord", connection: "12:connection:9c58…" }) → { "status": "success", "data": [ { "key": "applicationId", "type": "dropdown", "dynamic": 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>"
    },
    "name": "resolve_parameters"
  }
}

Input Schema

NameRequiredDescriptionDefault
appYesThe app id, exactly as list({ type: "app" }) returned it.
inputNoThe parameter values chosen so far, key → value (plain values, not the source forms). Later parameters often depend on earlier ones.
actionNoAn action key, from fetch on the app.
triggerNoA trigger key, from fetch on the app.
connectionYesA connection id for this app, from list({ type: "connection" }) or fetch on the app.

Output Schema

NameRequiredDescriptionDefault
dataNo
statusNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover read-only/idempotent/open-world, and the description adds substantial behavior beyond that: iterative re-resolution as new parameters appear, the refusal of a missing required key, HTML-escaping of html fields unless options { encodeHTML: false }, and the pick_url file-picker handoff that grants the connection access. The one gap is that 'refused' is not spelled out as a validation error versus a state change, which is minor but worth a point.

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?

Front-loading is good — purpose and return shape come first, and the worked example anchors it. However, the middle is a single dense paragraph mashing together default-fill rules, HTML escaping, required-key refusal, dynamic/dependent flags, iteration protocol, and file pickers; the iteration protocol in particular is buried where an agent may skim past it.

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 tool with an output schema and a subtle iterative contract, the description covers everything an agent needs to call it correctly: the one-of action/trigger rule, the re-call-until-repeat loop, default fill behavior, embedded field handoff, and the meaning of dynamic/dependent. Little is left to inference.

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 the baseline is 3, and the description earns more: it clarifies that input holds plain values rather than source forms, that only one of action/trigger may be supplied, and that a picked { id, label } option becomes the parameter value. It does not re-explain app or connection beyond the schema, which is appropriate.

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?

The opening states the exact resource (the parameters a workflow step or trigger takes) and the resolution scope (against a connection plus values chosen so far), and the 'pass exactly one of action or trigger' constraint makes the calling shape unambiguous. It also differentiates from siblings by naming list_parameter_options for dynamic options and edit_source/create for filling defaults.

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 concrete operational guidance: pass exactly one of action or trigger, re-call with the full input after each choice, and stop when an answer repeats the previous one. It routes option-reading to list_parameter_options. It stops short of a full when-not-to-use statement (e.g. when to use fetch or test_action instead), which keeps it out of the top band.

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