Server4Agent

Prompt the on-server agent

prompt

Destructive

Send a freeform prompt to the on-server agent. It plans, writes code, runs commands, and ships whatever the prompt asks for. It spends the account's AI budget, so use it when the user asks for the on-server agent or to continue a run it started; to build something yourself, write_file, exec, start_app and deploy cost nothing. Returns a run_id to poll with get_run. Each call starts a new conversation unless you pass follow_up_of: the run_id of an earlier run to continue, so the agent remembers what it did there. Use it to answer a run that is awaiting_input, or to ask for changes to what a run built. Pass project_id to work inside one project's workspace, or omit it to work across the whole server workspace (e.g. scaffolding a new project).

Input Schema

Name	Required	Description
`prompt`	Yes	What you want the agent to do, in plain language. The more specific, the better the result.
`server_id`	Yes	The server's id, as returned by create_server or list_servers.
`project_id`	No	Optional. Scope the run to this project's workspace folder. Omit to run at the server workspace root. Not needed with follow_up_of, which runs where the earlier run did.
`follow_up_of`	No	Optional. The run_id of an earlier run on this server to continue. The agent picks up that conversation, in the same folder and project. The result's resumed is false when there was no conversation left to pick up: the agent then works in the same folder without that memory.

Output Schema

Name	Required	Description
`run_id`	Yes	The run. Poll it with get_run.
`status`	Yes	Run status.
`resumed`	No	Whether the earlier conversation was picked up. false means the same folder, without that memory.
`project_id`	No	The project whose folder it works in. null at the server root.
`follow_up_of`	No	The earlier run this one continues, when follow_up_of was passed.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The annotations already flag destructive and openWorld, and the description adds substantive context beyond them: it spends the account's AI budget, it returns a run_id to poll with get_run, each call starts a fresh conversation unless follow_up_of is passed, and project scoping behavior. That async, stateful, cost-bearing profile is exactly what an agent needs and is not derivable from 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?

The core action and cost warning are front-loaded, and every sentence carries information. It is on the long side at six sentences, and the project_id/follow_up_of guidance partly duplicates schema descriptions, but nothing is filler.

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 non-idempotent, destructive, open-world tool with four parameters, the description covers cost, async polling via get_run, conversation continuity, and scoping. An output schema exists, so omitting return-value detail is appropriate, and it still names run_id and resumed.

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, but the description goes further by explaining the consequence of omitting project_id (whole-server workspace, e.g. scaffolding a new project) and the conversational semantics of follow_up_of (memory is retained, and a run continues where the earlier one ran). These are effects, not restatements of the schema text.

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 a freeform prompt to the on-server agent) and then enumerates the agent's capabilities (plans, writes code, runs commands, ships). It explicitly contrasts itself with the manual siblings write_file, exec, start_app and deploy, so an agent can separate this tool from them without reading any 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?

Gives explicit when-to-use conditions: when the user asks for the on-server agent, to continue a run it started, to answer a run awaiting_input, or to request changes to what a run built. It also gives a when-not rule (build it yourself with the free tools) and names those alternatives.

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

All Server4Agent 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.