Skip to main content
Glama
felkru

handoff-mcp

by felkru
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

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": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
handoffA

Hand a task off to a peer coding-agent CLI and return its answer (blocking).

Use this for tasks that finish in a few minutes. For long/agentic work,
prefer `handoff_start` + `handoff_status` so you get progress and don't block.

Choosing a backend (see `handoff_guidance` for detail):
  - `codex` (OpenAI): code review, bug hunting, refactors, terminal-agentic
    work, second opinion on code/text. Text & images (not PDFs).
  - `antigravity` (Google Gemini 3): visual feedback (screenshots, diagrams,
    PDFs), very-long-context reads (whole repos / huge docs), cheap bulk.

Hand off aggressively when the Claude/Fable usage limit is close — each
backend bills to a separate subscription pool.

Args:
    prompt: What to do. The peer agent has NONE of this conversation's
        context — be explicit and self-contained.
    backend: "codex" or "antigravity".
    files: Absolute/~ paths to attach. codex: text + images. antigravity:
        text, images, and PDFs.
    model: Optional model id override; empty = the CLI's own default
        (e.g. "gpt-5.3-codex", "gemini-3.1-pro-preview").
    cwd: A project directory the agent may read for extra context. The
        process itself runs in a throwaway temp dir; originals are never
        modified unless you set `approve=True`.
    approve: Allow the agent to actually make edits (codex: workspace-write
        sandbox; antigravity: --dangerously-skip-permissions). Default False
        = read-only, right for reviews/opinions.
    timeout: Seconds before abort.

Returns:
    The peer agent's response, or a clear "[handoff error] …" string.
handoff_startA

Start a handoff as a background job and return a job id immediately.

Use this for long or agentic handoffs (deep reviews, multi-file refactors,
reading a huge document). Then poll `handoff_status(job_id)` to watch
progress stream in and collect the result when it's `done`. This is the
async path — it lets you keep working / check in periodically instead of
blocking on one long call.

Args mirror `handoff`. Returns a short job id string (pass it to
`handoff_status`). The job's own timeout is generous (default 30 min).
handoff_statusA

Poll a background handoff job: state, elapsed time, live progress, result.

Args:
    job_id: The id returned by `handoff_start`.
    tail: How many lines of streamed progress log to include.

Returns JSON with: `state` (running|done|error), `elapsed_s`, `backend`,
`log_tail` (the peer agent's streamed activity so far), and — once done —
`result` (or `error`). Call repeatedly until `state` != "running".
handoff_jobsB

List recent handoff jobs (id, backend, state, elapsed, prompt preview).

handoff_backendsA

Report each backend's install + auth readiness, its quota pool, and a freshness note for the routing guidance.

Call this first if a handoff returns an auth/not-found error. The output
includes a `staleness` banner reminding the maintainer to refresh the model
guidance when new models ship.
handoff_guidanceA

Return the model routing guide: which backend is best for which task, and when to hand off aggressively to preserve the Claude/Fable usage limit.

NOTE TO MAINTAINER: this reflects the model landscape as of
core.MODEL_INFO_UPDATED. Update core.ROUTING_GUIDE when new models/CLIs ship.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a distinct job: synchronous handoff, async start, status polling, job listing, backend readiness, and routing guidance. The sync vs async pair is clearly differentiated by blocking versus job-id-returning behavior.

Naming Consistency4/5

The handoff_ prefix creates a clear and consistent family, and all names are lowercase snake_case. The lone exception is the bare `handoff` tool, which is a minor deviation from the otherwise uniform pattern.

Tool Count5/5

Six tools is well-scoped for a narrow handoff-oriented MCP server. Each tool covers a necessary part of the workflow without redundancy or bloat.

Completeness4/5

The server covers the core lifecycle: blocking handoff, async start, polling, listing, backend readiness, and routing guidance. The main missing operation is a way to cancel or abort a long-running background job.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources