A task prompt carries the work; the generated submit_result tool carries the ending. Nothing is appended to your prompt, so the two most common failures, no_output and step_limit, trace back to what the prompt and the tool descriptions do or do not say. For conversational prompting see prompting an agent.

​
Where each instruction goes

Do not list the output fields or tell the model to call submit_result in the prompt; that repeats what the tool schema already says. Do replace the starter submit_result_description — a model not told that prose is not a result may write a good paragraph and end the run as no_output. See inputs and output.

​
A prompt shape that finishes

  1. Purpose — what a finished run has produced, in one or two sentences.
  2. Inputs — each {{vars.…}} the prompt reads and what it is.
  3. Method — the steps in order: which tool when, and when to stop calling it.
  4. Standards — what each value must meet before submitting.
  5. When something cannot be found — send null and move on. Without this the model keeps searching and runs out of steps.
A field that must always have a value should keep required: true (the default), which makes the tool refuse null. Set required: false only where “not found” is a valid answer, and say when in the field’s description.

​
Prompting for tools

The model chooses tools from their names and descriptions; the prompt adds order and stopping rules.
  • Use the name the model sees. For an MCP tool that is the namespaced name (crm_search, not search); GET /v1/integrations/{integration_id}/mcp-tools lists both. See MCP servers.
  • Give the order. “Call crm_search with the domain first. Only if it returns no rows, use web_lookup.”
  • Say what an empty result means. “If crm_search returns an empty list, the company is not a customer; do not search again with a different query.” Without it, the model retries until the steps run out.
  • Say what not to call on a write-capable server, in addition to narrowing allowed_tools on the integration.
A task can afford llm.reasoning_effort: no caller is waiting, so thinking costs tokens and seconds, not dead air. See reasoning and builtin tools.

​
no_output or step_limit

Both mean the run ended without a valid submit_result call. The fix differs: A run with no result is re-prompted up to twice, so attempts is 1–3. attempts: 2 or 3 on a completed run means earlier attempts were thrown away: it worked at two or three times the tokens and will start failing when the work gets harder. See errors and limits.

​
Iterating on the trace

Run, read the trace, change one thing. Runs with the same vars are directly comparable. Use task_version: "draft" on POST /v1/task-runs to test an edit before publishing, and task_override to try another model without editing the task.

​
Next

Inputs and output

The generated submit_result tool and field descriptions.

Errors and limits

Every error.type and the two budgets that bound a run.