Skip to main content
Glama

Run endpoint

run
DestructiveIdempotent

Execute one endpoint and charge the workspace per its published price. Build input against the inspected input_schema. Generate a UUID for idempotency_key and reuse the SAME key to retry — it never charges twice; the result carries replayed:true on a replay. A provider 404/500 is a COMPLETED run carrying that outcome in provider_response, not an error. A QUEUED/RUNNING result means an async endpoint is still working — poll runs_get. The user's own keys and integrations outrank Glasser; never run speculatively, in loops or in bulk without naming the price and getting the user's go-ahead. The result's run_url opens the run's records in the workspace console, exactly as the provider returned them (members only); when your answer relies on the run, cite run_url as its source — the run id alone opens nothing. Docs: https://glasser.ai/docs/api-reference/runs/create

Input Schema

NameRequiredDescriptionDefault
inputNoProvider-native input. Build it from the input_schema returned by Inspect.
task_idNo
endpointYes
providerYes
idempotency_keyYes
endpoint_versionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / endpoint_version / anyOf
      Previous value: -[
      -  {
      -    "description": "Select a supported Endpoint version. Compatible updates keep this version; it does not lock the Price. New Runs use the Price at admission. Omit to use the default version. Unavailable or retired versions return 409.",
      -    "exclusiveMinimum": 0,
      -    "type": "integer"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "description": "Select a supported version, or omit for the default. Compatible updates keep the version; unavailable or retired versions return 409. A version does not lock Price: new Runs use the Price at admission, and accepted Runs keep it through settlement.",
      +    "exclusiveMinimum": 0,
      +    "type": "integer"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • addedInput schema / properties / input / description
      Added value: +"Provider-native input. Build it from the input_schema returned by Inspect."
  2. Changed1 schema field changed
    • addedInput schema / properties / task_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "description": "The task this run belongs to, from a catalog search response. Grouping only: it never affects routing, price or idempotency.",
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations, which only flag mutating/idempotent/open-world. The description discloses billing behavior (charge per published price), idempotency mechanics (generate a UUID, reuse the SAME key, never double-charges, replayed:true), error semantics (provider 404/500 is a COMPLETED run in provider_response, not an error), and async state (QUEUED/RUNNING means poll runs_get).

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?

Long but densely packed: it leads with the action and price consequence, then layers idempotency, error handling, async polling, safety gating, and citation guidance. Nearly every sentence carries operational information, though the volume is on the heavier side for a single tool.

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?

With no output schema and 6 parameters, the description compensates by describing the salient return fields (provider_response, replayed:true, QUEUED/RUNNING, run_url) and the run_url citation convention. Nothing essential for correct invocation or interpretation is 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?

Schema coverage is only 17%, so the description carries most of the burden: it explains how to construct input (from an inspected input_schema) and the idempotency_key generation/reuse rule, which the bare minLength:1 schema does not convey. It does not elaborate on the provider/endpoint string formats beyond their regex patterns, leaving a small gap.

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+resource: "Execute one endpoint and charge the workspace per its published price." This clearly separates run from siblings inspect (schema discovery), runs_get (polling), runs_list and runs_stop, so an agent can route without opening another 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?

Explicit routing and gating: build input from the inspected input_schema, poll runs_get when a result is QUEUED/RUNNING, and never run speculatively, in loops or in bulk without naming the price and getting user go-ahead. It names the alternative tool and the conditions that select it.

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.