Fetch Hive

Run an agent

run_agent

Destructive

Send one message to an agent and let it work, like calling it through the API. Runs cost money and the agent's tools can send messages or change things in connected apps, so: call it first without approved to get the cost, tell the person, and only call again with approved: true after they say yes. A quick answer comes back at once; otherwise the result has a run_id, and you call get_run every 10 seconds or so until done is true. If the agent stops for a tool approval, get_run lists it: show the person and use decide_approval with their answer.

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": {
      "agent_id": "<agent_id>",
      "message": "<message>"
    },
    "name": "run_agent"
  }
}

Input Schema

Name	Required	Description
`message`	Yes	What to ask the agent, with everything it needs.
`agent_id`	Yes	The agent to run (search_agents).
`approved`	No	true only after the person has agreed to this run and its cost.
`thread_id`	No	Keeps a conversation: runs with the same thread_id see the earlier messages. Leave out for a one-off.
`response_format`	No	A JSON Schema the answer must follow, for this run only.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already flag destructive and open-world, but the description adds the crucial context: runs cost money and the agent's tools can send messages or alter connected apps, which is why human sign-off is required. It also discloses the async behavior (run_id, poll every ~10 seconds until done) and the tool-approval pause path, none of which appear in structured fields.

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 with the core action, then the cost/approval workflow, then the async and approval-pause handling — a logical order with little waste. The simile 'like calling it through the API' is the only mildly expendable phrase, and the sentence is long but dense with load-bearing detail.

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 carries the return-value burden and does so: either an immediate answer or a run_id to poll, with the tool-approval case surfaced via get_run. For a costly, destructive, open-world tool with 5 parameters, the description covers cost, consent, async polling, and escalation paths.

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 baseline is 3, but the description adds procedural meaning the schema does not: 'approved' is tied to a mandatory cost-confirmation round trip rather than just a boolean, and 'thread_id' behavior is reinforced by the instruction to poll get_run. The response_format and message nuances remain solely in 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 and resource: send one message to an agent and let it work. It also implicitly separates itself from get_run (polling) and decide_approval (tool approval handling), so an agent can pick the right tool without opening schemas.

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 an explicit two-phase protocol — first call without 'approved' to obtain cost, tell the person, then call again with approved: true only after consent — plus named alternatives (get_run for polling, decide_approval for tool pauses). When-to-use and when-not-to-proceed are both spelled out.

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

All Fetch Hive tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?