Skip to main content
Glama

Create a run

create_run

Start an AI agent run in an isolated sandbox and return the run (status queued) at once. Give a prompt, or the name of a saved workflow. Poll with get_run or block with wait_for_run for the result. Every run has a cost cap (max_cost_micros) and a timeout, and is billed to the organization of the API key. Connections must already be saved in the organization; reference them by name. Use idempotency_key to make a retry safe. A run's cost_micros is provisional (usually above the final cost) until cost_final is true; see get_run. On the hosted service a run costs a run fee once its worker starts, compute per second, model calls at the provider's price plus a percentage, and web requests and searches at flat prices; GET /v1/me reports the rates.

Input Schema

NameRequiredDescriptionDefault
webNoWeb access: true, false, or an object limiting it.
filesNoFiles placed in the sandbox: inline content, or a file saved in the organization.
inputNoAny JSON the agent receives as its input. If the workflow has an input_schema, it must match.
modelNoA model id from list_models. Omit for the default.
shellNoWhether the agent may run shell commands in its sandbox.
promptNoWhat the agent should do. Required unless workflow is set.
workflowNoName of a saved workflow to run instead of a prompt (see list_workflows).
connectionsNoSaved connections the agent may use, keyed by the name the agent sees. Each refers to a connection saved in the organization and can only narrow it.
descriptionNoWhat the workflow does and what input it expects, in a sentence or two, for people and agents. At most 500 characters.
input_schemaNoA JSON Schema (draft 2020-12 or 7, at most 32 KiB, no references to other documents) that this run's input must match. A run whose input does not match is refused with the path and the reason, such as "input.city: required".
output_schemaNoA JSON Schema (draft 2020-12 or 7, at most 32 KiB, no references to other documents) that this run's output must match. The agent is told the schema and asked to reply with JSON only; the output is then checked, and a run whose output does not match fails with the reason.
idempotency_keyNoA retry with the same key returns the original run instead of starting another.
max_cost_microsNoCost cap in millionths of a dollar. The run stops at the cap.
timeout_secondsNoWall-clock limit for the run.
zero_data_retentionNoRecord nothing of the run's content; the output is kept only briefly and released on first retrieval.

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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 (readOnlyHint=false, openWorldHint=true, idempotentHint=false): it discloses billing destination (organization of the API key), cost cap and timeout enforcement, provisional vs. final cost semantics, hosted-service pricing components, and retry safety via idempotency_key. That is exactly the operational context an agent needs before incurring spend.

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?

Front-loads purpose and control-flow guidance in the first two sentences, with cost/pricing detail after — a good ordering. The trailing pricing sentence is dense and slightly sprawling, but it earns its place for cost-capped runs.

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 15-parameter, nested-object creation tool with no output schema, the description covers the return shape (queued run), asynchronous result retrieval, cost finality, prerequisites, and billing — nothing needed to invoke it correctly 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 100%, so the baseline is 3; the description adds real semantic value by explaining max_cost_micros' role as a hard stop, idempotency_key's retry behavior, and that connections must pre-exist and are referenced by name. It stops short of explaining zero_data_retention, files, or web scoping in the description, leaving those to the schema.

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 ("Start an AI agent run in an isolated sandbox") plus immediate return state ("status queued"), which distinguishes it from get_run/wait_for_run and from schedule/run_schedule siblings referenced in the text.

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?

Explicitly names the two usage modes ("Give a prompt, or the name of a saved workflow") and routes follow-up work to alternatives: "Poll with get_run or block with wait_for_run for the result." It also states the connections prerequisite (must already be saved, reference by name) and when to use idempotency_key.

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