Skip to main content
Glama

Invoke agent

invoke_agent

Send a message to a hosted agent and get its reply, with state preserved for future calls. Use for long-running, multi-step tasks by polling the returned run ID.

Instructions

Send a message to an agent and get its reply. Use this for work that should outlive a single request: files written now and read next week, software installed once and reused, a repo kept checked out, or a long job handed off and read later. Do not use it for a stateless snippet you can run inline, with no state worth keeping: a plain code sandbox is cheaper and faster for that. By default waits up to ~25s for the turn to finish and returns the assistant's reply; if it is still running by then it returns a run_id with status "running" to poll via get_run_result. Agent turns can take minutes (research, multi-step or tool-heavy work). This call blocks your own turn while it waits, and no MCP client backgrounds it — so if the user is not waiting on this reply, or you expect a long turn, pass wait=false to get a run_id back immediately and poll get_run_result on your own cadence instead of holding the call open. Running an agent spends credits, and an account's plan caps how many runs it may have in flight at once across all its agents (over the cap returns 429; wait for a run to finish and retry). Turns on one agent are not queued for you. Pass idempotency_key when you might retry this call: a retry carrying the same key returns the original run instead of starting and billing a second one. If the run pauses on a human-input request it returns status "awaiting_input" with the pending request details inline (respond with answer_pending_input). Every result also carries a "url" that opens this run's exact session in the web app, so a human can go read it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
waitNoWait (up to ~25s) for the turn and return the reply (default true). Set false to return a run_id immediately and poll get_run_result — prefer this for long or tool-heavy turns so the call doesn't block your own turn.
messageYesThe message to send to the agent.
agent_idYesThe agent's UUID.
session_idNoOptional thread/session id to continue an existing conversation (a previous invoke_agent or get_run_result result carries it as "session_id"); omit to start a new one.
idempotency_keyNoOptional retry guard: a string you generate for this attempt. Re-sending the same key with the same agent and message within 24h returns the ORIGINAL run instead of starting a second one. Reusing a key with a different message is an error.
max_turn_tokensNoOptional cumulative cache-weighted token ceiling for this turn (0 or omitted uses forge's default; maximum 5,000,000). The agent reserves its final 2% for a tool-free wrap-up.
Behavior5/5

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

Annotations only provide openWorldHint and destructiveHint=false, leaving the description to carry the burden. It fully discloses blocking ~25s, run_id/status flow, credit consumption, plan caps, no queueing, idempotency behavior, awaiting_input, and a session URL. No contradiction with annotations.

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-loaded and every sentence contributes meaningful operational detail, but the description is a long single paragraph without breaks. Could improve scannability with short paragraphs or bullets; still no wasted words.

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, the description thoroughly covers return values (assistant reply, run_id, status values), the awaiting_input flow, the URL, credit/cap/429 conditions, and retry semantics. It is complete for a tool with this complexity.

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 already covers all 6 parameters with descriptions (100% coverage), so baseline is 3. The description adds operational meaning—why wait=false is preferable for long turns, how idempotency_key returns the original run, and how session_id threads conversations—pushing it above baseline.

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?

Opens with a specific verb and resource: 'Send a message to an agent and get its reply.' It also differentiates from siblings by naming get_run_result as the polling alternative and explicitly contrasting with inline code sandboxes for stateless work.

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?

Gives explicit 'Use this for...' (stateful work, long-lived artifacts) and 'Do not use it for...' (stateless snippets) guidance, plus concrete decision rules for wait=true/false, idempotency_key, and 429 retry behavior.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/plori-ai/plori'

If you have feedback or need assistance with the MCP directory API, please join our Discord server