Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
initA

READ THIS FIRST. Reports what this server can reach and how to drive it: permitted tools, the default model, models available per provider, and the recipes for delegating. Every other tool refuses until this has been called once.

spawnA

Delegate a task to a pi agent running in the background. Returns a sessionId immediately, so nothing blocks. Poll with status, redirect with steer, answer its questions with answer. Use this for anything that might take more than a minute.

spawn_batchA

Fan out several delegates in one call. Each task inherits the batch-level model, cwd, tools and extensions unless it overrides them. The whole batch is validated before any delegate starts, so a bad model name or a duplicate id fails everything instead of leaving half a fan-out running. Poll the result with sessions, which reports all of them at once, rather than one status per delegate.

runA

Delegate a task to a pi agent and wait for the final answer. Blocks until done. Prefer spawn for long work; this is for quick questions.

statusA

Check a background pi session. Returns state, turn count, tools used, latest text, and any pending questions the agent is waiting on. A non-empty questions array means it is blocked until you call answer. toolCalls traces every tool the delegate ran, in order.

steerA

Redirect a running pi agent mid-task. The message lands after its current tool call finishes, before the next model call. Use this instead of aborting when the agent is going the wrong way.

answerA

Answer a question raised by a pi agent. Get requestId from status. Only pi extensions can ask, so questions appear only for delegates spawned with extensions: true; the MCP adapter's tool-approval and elicitation prompts are the usual source. A delegate waiting on one is blocked until you answer it.

follow_upA

Send another prompt to a delegate that has already finished, keeping everything it read and said. Use this instead of spawning a fresh delegate and re-explaining the task: the session still holds its own context, which yours never had to absorb. Returns immediately; poll with status as usual. For a delegate that is still working, use steer instead.

abortA

Stop a running pi session. Partial output stays readable via status.

sessionsA

List pi sessions held by this server, running and finished. Finished ones stay readable for review until evicted (keeps the newest 50).

forgetA

Drop a finished session from the review history, freeing its id for reuse.

modelsA

List models this delegate may use: pi's own scoped set plus any custom provider. Use to pick a model value.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.2/5.0

Scored across 12 tools

Disambiguation5/5

Each tool targets a distinct phase of the delegate lifecycle: starting (spawn, run, spawn_batch), monitoring (status, sessions), interacting (steer, answer, follow_up), and cleanup (abort, forget). Descriptions clearly differentiate async vs sync and running vs finished states, so misselection is unlikely.

Naming Consistency4/5

Most tools use imperative single-word verbs (spawn, steer, abort) or compound verbs (spawn_batch, follow_up), but two are bare nouns (sessions, models) instead of list-style verbs like list_sessions. This is a minor deviation from an otherwise predictable, straightforward naming scheme.

Tool Count5/5

At 12 tools, the server is well-scoped for its purpose—managing delegated pi agents. Each tool covers a necessary operation without redundancy, and the count falls comfortably within the 3–15 ideal range for a focused MCP server.

Completeness5/5

The tool surface provides full lifecycle coverage: launch, monitor, interact, redirect, follow-up, abort, clean up, and list. It also includes init and models for setup and model selection. There are no obvious gaps that would cause agent dead-ends.

Maintenance

ActivityMaintained
ResponsivenessNo issues