What can you do with this server?

The worker-mcp server enables a coordinator AI agent to spawn, control, and supervise local worker coding agents, with interactive consent for high-risk operations and detailed logging. * Session Management: Spawn a worker agent in a specified workspace directory, optionally with a custom model, system prompt, and risk policy. List, terminate, and restart sessions; configurations persist across server restarts. * Command Dispatch: Send prompts or slash commands to a session, with support for background async execution, timeouts, and response summarization. Cancel in-progress commands with forced termination if the agent does not settle. * Gating & Approval: Retrieve pending high-risk tool calls that require coordinator approval. Approve or reject them, optionally providing feedback to guide the worker. * Risk Policy: Dynamically set auto-approval thresholds (e.g., LOW, MEDIUM, HIGH, CRITICAL) and define custom glob-pattern overrides for command or file path patterns. Audit auto-approved actions with optional filtering. * Resources: Access session conversation history and stdout/stderr subprocess logs via MCP resources.

How do I use worker-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@worker-mcp spawn a worker to fix the bug in auth.ts" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

worker-mcp

by noosxe

Overview Schema Related Servers Score Discussions

TypeScript

Local

worker-mcp

worker-mcp is a Model Context Protocol (MCP) server that empowers a highly intelligent coordinator agent (like Claude 3.5 Sonnet or Gemini Pro) to spawn, control, and interactively guide lower-intelligence, locally hosted worker agents.

Instead of rolling a custom local LLM tool loop, worker-mcp delegates coding, bash, and filesystem operations to the pi coding agent (@earendil-works/pi-coding-agent) by running it in JSON-RPC mode. Since these small local models require significant supervision, worker-mcp acts as a gating and auditing harness.

Features

Interactive Gating (Consent Hook): Automatically intercepts and blocks high-risk operations (e.g. executing shell commands or writing files) and prompts the coordinator for approval before execution.
MCP Tool Integration: Standardized tools to spawn worker sessions, dispatch prompts, list active runners, and approve/deny pending commands.
Log and History Resources: Message history and subprocess logs (including stderr feeds) are exposed as standard MCP resources.
Session Registry Persistence: Session configurations and directory bindings survive server restarts via state files in ~/.config/worker-mcp/sessions.json.
Automatic Extension Deployment: Deploys its supervisor gate extension directly into ~/.config/worker-mcp/ and loads it explicitly when spawning the worker agent (leaving standalone pi agent runs unaffected).

Related MCP server: projscan

Installation & Usage

worker-mcp is published on npm as @noosxe/worker-mcp. This is the recommended installation path for most users.

1. Install via npm (Recommended)

Option A: Global Installation

Install the package globally on your system:

npm install -g @noosxe/worker-mcp
# or using pnpm
pnpm add -g @noosxe/worker-mcp

Once installed globally, you can run the server using the worker-mcp command.

Option B: Run ad-hoc via npx

Alternatively, you can run the server on stdio immediately without installing it:

npx @noosxe/worker-mcp

2. Install via Nix

This project also provides a Nix flake to ensure consistent environments and easy installation.

Option A: Run Directly (Ad-hoc)

You can run the server on stdio immediately using Nix:

nix run github:noosxe/worker-mcp

Option B: Install to User Profile

Install the worker-mcp executable globally in your user profile:

nix profile install github:noosxe/worker-mcp

Once installed, run it with:

worker-mcp

3. Declarative Installation via Flake Overlay (System / Home Manager)

If you manage your operating system or user profile declaratively via NixOS or Home Manager, you can consume our default overlay.

Step 3.1: Add the Flake Input

Add worker-mcp to your system's flake.nix input section:

inputs = {
  nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
  
  # Add worker-mcp input
  worker-mcp.url = "github:noosxe/worker-mcp";
};

Step 3.2: Configure the Overlay and Install

Option A: NixOS Configuration

Add the overlay to nixpkgs and include worker-mcp in your system packages:

outputs = { self, nixpkgs, worker-mcp, ... }@inputs: {
  nixosConfigurations.my-system = nixpkgs.lib.nixosSystem {
    system = "x86_64-linux"; # Or your system architecture
    modules = [
      ({ pkgs, ... }: {
        # Apply the overlay
        nixpkgs.overlays = [
          worker-mcp.overlays.default
        ];

        # Install the package
        environment.systemPackages = [
          pkgs.worker-mcp
        ];
      })
      ./configuration.nix
    ];
  };
};

Option B: Home Manager Configuration

Add the overlay to nixpkgs and install it in your user packages:

outputs = { self, nixpkgs, worker-mcp, ... }@inputs: {
  homeConfigurations.my-user = inputs.home-manager.lib.homeManagerConfiguration {
    pkgs = import nixpkgs {
      system = "x86_64-linux";
      overlays = [ worker-mcp.overlays.default ];
    };
    modules = [
      ({ pkgs, ... }: {
        # Install the package
        home.packages = [
          pkgs.worker-mcp
        ];
      })
      ./home.nix
    ];
  };
};

Harness Integration (Antigravity CLI / `agy`)

To register the worker-mcp server with your Antigravity TUI/CLI (agy), follow these steps:

Step 1: Register the Server via `mcp_config.json` (Declarative)

Antigravity CLI resolves MCP servers from dedicated configuration files (rather than the old settings.json). Add the configuration in one of the following locations:

Global Configuration: ~/.gemini/config/mcp_config.json
Project-local Configuration: .agents/mcp_config.json (at the root of your project workspace)

Configuration file schemas:

Option A: If installed globally (via npm or Nix)

{
  "mcpServers": {
    "worker-mcp": {
      "command": "worker-mcp",
      "args": []
    }
  }
}

Option B: If running ad-hoc via npx

{
  "mcpServers": {
    "worker-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@noosxe/worker-mcp"
      ]
    }
  }
}

Option C: If running ad-hoc via GitHub Flake

{
  "mcpServers": {
    "worker-mcp": {
      "command": "nix",
      "args": [
        "run",
        "github:noosxe/worker-mcp?ref=main"
      ]
    }
  }
}

Option D: Declarative Home Manager Configuration

If you manage your user configuration via Home Manager, you can declare the global mcp_config.json file in your home.nix using home.file combined with builtins.toJSON:

home.file.".gemini/config/mcp_config.json".text = builtins.toJSON {
  mcpServers = {
    worker-mcp = {
      # If installed via overlay in system/home packages or globally via npm:
      command = "worker-mcp";
      args = [];

      # Alternatively, if running ad-hoc via npx:
      # command = "npx";
      # args = [ "-y" "@noosxe/worker-mcp" ];

      # Alternatively, if running ad-hoc via Nix:
      # command = "nix";
      # args = [ "run" "github:noosxe/worker-mcp?ref=main" ];
    };
  };
};

Step 2: Verify and Manage via TUI (`/mcp` command)

Once you have added the server configuration to mcp_config.json, you can manage it interactively inside the CLI:

Launch the Antigravity TUI:
```
agy
```
Type the slash command /mcp in the prompt input and press Enter.
An interactive management overlay will open, showing worker-mcp in the list. You can inspect its status, trigger manual reloads, or verify that the tools/resources are successfully discovered by the coordinator agent.

Operational Configuration

Environment Variables

WORKER_MCP_PI_PATH: Absolute path to the pi coding-agent binary (defaults to searching PATH for pi).

Pre-requisites

Make sure you have the global pi coding-agent CLI installed in your local system:

npm install -g @earendil-works/pi-coding-agent

Configure your models in pi (e.g. using pi --mode rpc to set default models, or registering Ollama model definitions).

MCP Reference

Exposed Tools

spawn_pi_session: Spawns a new supervisor-gated worker agent in the specified workspace directory.
send_pi_command: Dispatches prompts to the worker session. Supports background MCP task execution (resolving asynchronously) or blocking mode with an optional timeout.
cancel_pi_command: Aborts the currently running command in a session and cancels its background task.
list_pi_sessions: Returns a list of active sessions, directory targets, and current states.
get_pending_actions: Fetches the details of an intercepted command awaiting consent.
approve_action: Approves execution of a gated tool call.
reject_action: Blocks a gated tool call and forwards feedback to correct the agent's course.
set_risk_policy: Updates the risk-based auto-approval policy for a session at runtime.
get_auto_approved_log: Retrieves the audit log of actions that were auto-approved by the risk policy.

Exposed Resources

worker-mcp://sessions/{sessionId}/history: Returns the conversation log and internal message stream.
worker-mcp://sessions/{sessionId}/logs: Returns the stdout/stderr trace logs of the subprocess.

Local Development

If you are contributing to this codebase, you must enter the Nix development shell:

nix develop

This enters an environment pre-packaged with:

Node.js 24
pnpm
TypeScript
BiomeJS

Dev Tasks

Code Quality (Check, Lint, Format): biome check --write src/
Compile TypeScript: pnpm run build
Run local server: pnpm run dev
Build Nix Derivation: nix build

Available Tools

10 tools

approve_actionC

Approve an intercepted tool execution.

ParametersJSON Schema

Name	Required	Description
`actionId`	Yes	The ID of the intercepted tool call/action.
`sessionId`	Yes	The target session ID.
`summarize`	No	If true, returns a concise summary of the worker's response once it completes.

TDQS

C2.7/5.0

Behavior1/5

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

No annotations are provided, and the description fails to disclose behavioral traits such as side effects (e.g., the tool executes), required permissions, or what happens after approval. This is a significant gap.

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?

Single sentence is front-loaded but may be overly minimal. Could be expanded slightly without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description does not explain the result of approval (e.g., the tool executes) or any return value. This leaves the agent uncertain about the outcome.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the description adds no extra meaning beyond the schema. Baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Approve an intercepted tool execution' clearly identifies the verb and resource, distinguishing it from sibling 'reject_action'. However, it could be more specific about what 'intercepted tool execution' entails.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like 'reject_action' or 'get_pending_actions'. The agent receives no context about when approval is appropriate.

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

cancel_pi_commandA

Abort the currently running command in a session. Sends abort to the agent; force-terminates after 2s if it doesn't settle.

ParametersJSON Schema

Name	Required	Description	Default
`sessionId`	Yes	The ID of the session whose command to cancel.

TDQS

A3.5/5.0

Behavior3/5

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

The description discloses the force-termination timeout (2s) and the abort signal, adding behavioral context beyond a simple 'cancel'. However, it does not specify side effects, error conditions (e.g., no running command), or required permissions, which would improve transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences. The main action is front-loaded, and no unnecessary words are included. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core action and timeout behavior, but for a tool with no output schema, it could mention what happens after cancellation (e.g., response, error cases). It is minimally adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, sessionId, is fully described in the schema ('The ID of the session whose command to cancel.'). The tool description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.

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?

The description clearly states the action ('abort') and the resource ('currently running command in a session'). It effectively distinguishes from siblings like 'send_pi_command' and 'terminate_pi_session', which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as the need for a running command, or when cancellation is appropriate.

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

get_auto_approved_logA

Retrieve the audit log of actions that were auto-approved by the risk policy. Useful for reviewing what the worker did without coordinator intervention.

ParametersJSON Schema

Name	Required	Description	Default
`pattern`	No	Optional filter: only return log entries whose matched override pattern equals this value.
`sessionId`	Yes	The target session ID.

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description bears full responsibility. It correctly identifies the operation as a retrieval (non-destructive). However, it does not mention any prerequisites, permissions, rate limits, or output format. For a read-only audit log tool, this is adequate but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, immediately front-loaded with the action and resource. No wasted words. Structure is optimal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple retrieval tool with two fully documented parameters, the description is fairly complete. It could mention the return type or pagination, but the core purpose is sufficiently conveyed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with both parameters described. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.

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?

The description clearly states the verb 'Retrieve' and the specific resource 'audit log of actions that were auto-approved by the risk policy'. It provides context about reviewing worker actions without coordinator intervention, which distinguishes it from sibling tools like approve_action or reject_action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates when to use the tool ('reviewing what the worker did without coordinator intervention'). While this implies the context, it does not explicitly state when not to use it or list alternatives. The context is clear enough for most agents.

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

get_pending_actionsA

Retrieve details of a tool call or action currently awaiting approval.

ParametersJSON Schema

Name	Required	Description	Default
`sessionId`	Yes	The target session ID.

TDQS

A4/5.0

Behavior4/5

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

No annotations are provided, so the description must carry the full burden. It clearly indicates a read operation with no side effects. It could mention permission requirements or limitations but is sufficient for a simple retrieval.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no unnecessary words. It front-loads the key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple retrieval tool with one parameter and no output schema, the description is adequate. It could mention that it lists pending actions for a session, but it is complete enough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds no extra meaning to the single parameter 'sessionId' beyond what the input schema already provides (100% schema coverage). Baseline of 3 is appropriate.

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?

The description clearly states the tool retrieves details of pending actions, using a specific verb (Retrieve) and resource (tool call or action awaiting approval). It distinguishes from siblings like approve_action and reject_action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is used before approving or rejecting actions, but it does not explicitly state when to use it vs. alternatives. With 8 siblings, more direct guidance would be helpful.

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

list_pi_sessionsA

List all active sessions and their status.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Only states 'list all active sessions and their status' without disclosing potential limitations (e.g., pagination, data freshness) or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no waste. Every word is necessary and front-loaded with the action and subject.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple list tool with 0 parameters and no output schema, but lacks details on what 'status' entails or any filtering options. Could be more thorough.

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?

No parameters exist, so baseline 4 applies. Description adds no parameter info, but schema coverage is 100% trivially.

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?

The description clearly states the tool lists all active sessions and their status, using specific verbs and resource. It distinguishes from siblings like spawn_pi_session or terminate_pi_session.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, such as get_pending_actions or get_auto_approved_log. The description does not mention exclusions or context.

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

reject_actionA

Deny an intercepted tool execution and feed feedback/refusal back to the agent.

ParametersJSON Schema

Name	Required	Description
`reason`	No	Optional feedback or reason for rejection to guide the agent.
`actionId`	Yes	The ID of the intercepted tool call/action.
`sessionId`	Yes	The target session ID.
`summarize`	No	If true, returns a concise summary of the worker's response once it completes.

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses the basic effect (denial and feedback) but does not mention irreversibility, impact on the agent, or any side effects. Adequate but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no fluff, clearly communicates the core action. Efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters, no output schema, and no annotations, the description is minimal. It explains the basic function but does not cover expected return behavior, logging, or persistence of denial. Adequate for a simple tool but could be more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond what the schema already provides for each parameter. The term 'feedback/refusal' aligns with the 'reason' parameter but is not explicitly mapped.

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?

The description clearly states the tool denies an intercepted tool execution and feeds feedback back to the agent. It uses specific verb 'deny' and resource 'intercepted tool execution', distinguishing it from siblings like approve_action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as approve_action. The description implies it's for interception contexts but does not explicitly state when not to use it or what prerequisites are needed.

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

send_pi_commandB

Send a prompt or slash command to a running session.

ParametersJSON Schema

Name	Required	Description
`command`	Yes	The text prompt or slash command (e.g. '/model', '/reload', or 'Implement main function').
`timeout`	No	Max time (ms) to wait for completion in blocking mode. If exceeded, returns with command still running.
`sessionId`	Yes	The ID of the target session.
`summarize`	No	If true, returns a concise summary of the worker's response instead of the raw output/status.

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries the full burden for behavioral disclosure, but it does not mention important behaviors like blocking mode with timeout, error handling, or return values.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no extraneous information, effectively conveying the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the schema covers all parameters, the description omits details about timeout and summarize behavior, leaving some context missing for correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% coverage with descriptive parameter descriptions. The description adds minimal value beyond 'send' context, meeting baseline expectations.

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?

The description clearly states the action 'Send', the resource 'prompt or slash command', and the target context 'to a running session', effectively distinguishing it from sibling tools like spawn_pi_session which creates a new session.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., cancel_pi_command, spawn_pi_session), nor any prerequisites or exclusions.

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

set_risk_policyA

Update the risk-based auto-approval policy for a session at runtime. Controls which actions are auto-approved based on risk level.

ParametersJSON Schema

Name	Required	Description	Default
`sessionId`	Yes	The target session ID.
`riskPolicy`	Yes	The new risk policy to apply.

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits, but it only says 'Update' without detailing side effects, permissions needed, or whether the change persists. It lacks depth for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no extraneous words; all information is front-loaded and relevant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description is adequate for basic understanding but omits behavioral details (e.g., return value, side effects) that would help an agent fully utilize the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds minimal value beyond what the schema already provides, referencing 'risk level' but not elaborating on parameters.

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?

The description clearly states the verb 'Update' and the resource 'risk-based auto-approval policy for a session,' explaining what the tool does and distinguishing it from sibling tools that handle commands, sessions, or approvals.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is used when needing to change the policy, but provides no explicit when-to-use or when-not-to-use guidance, nor mentions alternatives among siblings.

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

spawn_pi_sessionB

Spawn a new pi coding agent session in the specified workspace directory.

ParametersJSON Schema

Name	Required	Description
`cwd`	Yes	The absolute directory path where the pi agent will execute.
`model`	No	LLM model name override (e.g. ollama/qwen2.5-coder:7b or anthropic/claude-3-5-sonnet).
`sessionId`	Yes	A unique identifier for the session.
`riskPolicy`	No	Risk-based auto-approval policy. Controls which tool calls are auto-approved based on risk level. If not specified, defaults to auto-approve LOW risk and notify on MEDIUM risk.
`systemPrompt`	No	Custom system instructions to append/override.

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavioral traits. It only states the spawning action but omits details like potential failures, required permissions, side effects on existing sessions, or what happens if the workspace directory is invalid. This is insufficient for a sensitive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, concise sentence with no redundant information. It is front-loaded with the core action and context. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 5 parameters, nested objects, and no output schema, the description is too sparse. It does not explain return values, the purpose of riskPolicy, or how the session interacts with other tools. The agent may not understand how to use this tool effectively without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all 5 parameters with descriptions (100% coverage). The description adds no new semantics beyond refrencing 'cwd', which is already clear in the schema. Baseline score of 3 is appropriate as the schema does the heavy lifting.

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?

The description clearly states the action ('Spawn a new pi coding agent session') and the target resource ('in the specified workspace directory'). This distinguishes it from sibling tools like send_pi_command or terminate_pi_session.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., when to spawn a new session vs. list or terminate existing ones). The description implies usage contexts but does not provide explicit conditions or exclusions.

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

terminate_pi_sessionA

Stop a session and remove it, freeing its id for reuse. Use this to clear a session that has crashed, wedged, or is no longer needed.

ParametersJSON Schema

Name	Required	Description	Default
`sessionId`	Yes	The ID of the session to terminate.

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, but description discloses destructive action (removes session, frees id) and suggests use for problematic sessions. Does not detail required permissions or side effects, but adequate for a simple termination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with action and result, followed by usage guidance. 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?

Simple tool with one parameter and no output schema; description fully explains purpose and effect (stops, removes, frees ID). Complete for its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters with description. Description adds no extra meaning beyond schema's 'The ID of the session to terminate.'

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?

Description clearly states verb 'Stop a session and remove it' and resource 'session', differentiating from siblings like spawn_pi_session (create) and send_pi_command (send command).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use for crashed, wedged, or unneeded sessions. Does not explicitly list when not to use, but context is clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

2 tool updatesv0.4.1Jul 30, 2026

Addedcancel_pi_command

Changedsend_pi_command1 field changed

addedInput schema / properties / timeout

Added value: +{
+  "description": "Max time (ms) to wait for completion in blocking mode. If exceeded, returns with command still running.",
+  "type": "number"
+}

9 tool updatesv0.3.3Jul 29, 2026
- First observedapprove_action
- First observedget_auto_approved_log
- First observedget_pending_actions
- First observedlist_pi_sessions
- First observedreject_action
- First observedsend_pi_command
- First observedset_risk_policy
- First observedspawn_pi_session
- First observedterminate_pi_session

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a distinct purpose covering session lifecycle, interaction, approval workflow, and policy management. No two tools are easily confused.

Naming Consistency5/5

All tools use consistent snake_case with verb_noun pattern. The verbs and nouns are uniformly structured, making the naming predictable.

Tool Count5/5

9 tools is ideal for this domain, covering all necessary operations without being excessive or sparse.

Completeness5/5

The tool surface fully covers session management, command execution, approval handling, and policy auditing with no obvious gaps.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
agentwork-mcp A
io.github.ferm-ai
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
Agent Orchestration Autonomous Agents App Automation
2
agentmailrooms-mcp
com.clauxel.agentmailrooms
A paid remote MCP for OpenAI Codex agent coordination MCP, built to return verdicts, receipts, usage
Agent Orchestration Autonomous Agents
2

Related MCP Servers

multivon-mcpofficial
AI & Machine Learning Testing & QA Tools
multivon-ai
A
license
A
quality
B
maintenance
MCP server that gives AI coding agents direct access to evaluation tools.
Updated 18 days ago (2026-08-19 19:01 UTC)
22
Apache 2.0
projscan
Developer Tools Code Analysis Autonomous Agents
abhiyoheswaran1
A
license
Not graded
quality
A
maintenance
An MCP server that provides AI coding agents with AST-accurate, context-budget-aware codebase querying, safety gates, and team policy integration via structured tools and a local plugin layer.
Updated 2 months ago (2026-07-20 08:13 UTC)
562
4
MIT
agent-comm
Autonomous Agents Agent Orchestration
keshrath
A
license
Not graded
quality
D
maintenance
MCP server that enables AI coding agents to communicate, share state, and coordinate work in real time via MCP tools or REST API.
Updated 5 months ago (2026-04-17 08:01 UTC)
159
5
MIT
lxDIG MCP
Code Analysis Knowledge & Memory Agent Orchestration
lexCoder2
F
license
B
quality
C
maintenance
MCP server that gives AI coding assistants persistent memory, structural code graph analysis, and safe multi-agent coordination, enabling them to answer architectural questions, track decisions across sessions, and coordinate safely in multi-agent workflows.
Updated 6 months ago (2026-03-03 05:56 UTC)
39
4
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/noosxe/worker-mcp'

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

worker-mcp

Features

Installation & Usage

1. Install via npm (Recommended)

Option A: Global Installation

Option B: Run ad-hoc via npx

2. Install via Nix

Option A: Run Directly (Ad-hoc)

Option B: Install to User Profile

3. Declarative Installation via Flake Overlay (System / Home Manager)

Step 3.1: Add the Flake Input

Step 3.2: Configure the Overlay and Install

Option A: NixOS Configuration

Option B: Home Manager Configuration

Harness Integration (Antigravity CLI / agy)

Step 1: Register the Server via mcp_config.json (Declarative)

Configuration file schemas:

Option A: If installed globally (via npm or Nix)

Option B: If running ad-hoc via npx

Option C: If running ad-hoc via GitHub Flake

Option D: Declarative Home Manager Configuration

Step 2: Verify and Manage via TUI (/mcp command)

Operational Configuration

Environment Variables

Pre-requisites

MCP Reference

Exposed Tools

Exposed Resources

Local Development

Dev Tasks

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

multivon-mcpofficial

Latest Blog Posts

MCP directory API

Harness Integration (Antigravity CLI / `agy`)

Step 1: Register the Server via `mcp_config.json` (Declarative)

Step 2: Verify and Manage via TUI (`/mcp` command)