What can you do with this server?

This MCP server lets you delegate prompts to local coding agents and query their capabilities and quotas. * Ask a configured agent profile (from BRIDGE_AGENTS_JSON) with optional model, reasoning effort, and tool policy. * Read capabilities and quota information for a configured agent profile. * Delegate a prompt to Antigravity in an isolated temporary workspace, with optional model, reasoning effort, tool policy, and turn timeout. * Delegate a prompt to Codex with optional model and reasoning effort. * Read Antigravity's current models, effort options, and account quota without using an agent turn. * Read Codex's current models, supported efforts, and account quota without using an agent turn.

How do I use agent-shuttle-mcp?

1. Click on "Deploy 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., "@agent-shuttle-mcp ask Codex to explain the project structure" 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.

agent-shuttle-mcp

by Plartex

Overview Schema Source Related Servers Discussions Admin

Python

Local

Agent Shuttle

Tests MIT license A2A Protocol 1.0 MCP Python 3.11+

Russian version / Русская версия

Agent Shuttle gives Python applications one way to work with Codex, Antigravity, OpenCode, and Claude Code. It runs local agent tasks, preserves multi-turn sessions, and exposes the agents through A2A 1.0 JSON-RPC and MCP.

It allows agents and external applications to delegate tasks to peer agents, reuse multi-turn conversations, query live model catalogs and account quotas, and enforce tool permission boundaries—all on local loopback (127.0.0.1) without sharing cloud API keys.

Supported Agent Harnesses

Harness	Primary Integration Mechanism	Auth & Model Access	Key Features
Codex	Official `openai-codex` Python SDK	Local Codex App Server sign-in	Sandboxes (`workspace_write`, `read_only`, `full_access`), model & reasoning effort catalog, quota reporting via `account/rateLimits/read`.
Antigravity	Official `agy` CLI in headless mode (`-p` / `stream-json`)	Signed-in Antigravity account	Real-time models, efforts, and `/usage` quotas. Default settings or full access (`--dangerously-skip-permissions`). Optional legacy SDK backend.
OpenCode	Managed local HTTP server (`--pure serve`)	Local Ollama or cloud providers	Configured via JSON profile, fine-grained tool policies (`no_tools`, `read_only`, `workspace_write`, `full_access`), model variants.
Claude Code	Managed CLI in print mode (`claude -p`)	Local Ollama endpoint or Anthropic	Configured via JSON profile, isolated temporary session configs, resume support, safe mode vs full access.

Related MCP server: pokeclaw

Installation

Agent Shuttle requires Python 3.11+ and runs on Windows, Linux, and macOS.

Install from GitHub

python -m venv .venv
.\.venv\Scripts\python.exe -m pip install "git+https://github.com/Plartex/agent-shuttle.git"

The package is not published on PyPI yet. For development, clone the repository and install it in editable mode.

Install from Local Checkout

You can install Agent Shuttle directly from its repository checkout into your project's virtual environment:

# Create and activate your virtual environment
python -m venv .venv
.\.venv\Scripts\Activate.ps1

# Install in standard or editable mode
pip install C:\path\to\agent-shuttle
# or editable mode during development:
# pip install -e C:\path\to\agent-shuttle

Once installed, the CLI tools (agent-shuttle, agent-shuttle-mcp) and Python API (agent_shuttle) are fully accessible inside that virtual environment. The original checkout directory does not need to stay in place for runtime imports. Existing agent_bridge imports and agent-bridge commands remain supported as compatibility aliases; A2A metadata keys under agent_bridge.* are unchanged.

Quickstart (Windows PowerShell)

Use standard Python packaging, including when developing from a checkout:

python -m venv .venv
& .\.venv\Scripts\python.exe -m pip install -e .
& .\.venv\Scripts\agent-shuttle.exe discover

Point your MCP client's command at the installed .venv\Scripts\agent-shuttle-mcp.exe (use its absolute path). MCP starts a local A2A peer when a request needs one; there is no separate server startup step. See the getting started guide for MCP configuration.

For a persistent server, run agent-shuttle serve codex --workspace . --port 8765 (or serve antigravity on port 8766) in a terminal and stop it with Ctrl+C.

Minimal Examples

1. Python API

import asyncio
from pathlib import Path
from agent_shuttle import ShuttleClient, HarnessLaunch, connect_harness

async def main():
    client = ShuttleClient()

    # Query live model catalog and quota information
    info = await client.info("http://127.0.0.1:8766")
    print("Selected model:", info["capabilities"]["selected_model"])

    # One-shot task
    result = await client.ask(
        "http://127.0.0.1:8766",
        "Explain the project structure and list entry points.",
        model="gemini-3.8-flash-medium",
        reasoning_effort="medium",
    )
    print(f"[{result.state}] Task {result.task_id}:\n{result.text}")

    # Persistent multi-turn session (preserves conversation context)
    async with client.session(
        "http://127.0.0.1:8765",
        model="gpt-5.6-terra",
        reasoning_effort="high",
    ) as session:
        step1 = await session.ask("What database migrations are pending?")
        step2 = await session.ask("Generate SQL to apply the first migration.")
        print("Step 2 response:", step2.text)
        print("Step 2 token usage:", step2.usage)

    # Managed peer lifecycle: reuse existing server or start a temporary one
    launch = HarnessLaunch(
        name="antigravity",
        url="http://127.0.0.1:8766",
        workspace=Path.cwd(),
    )
    async with connect_harness(launch) as conn:
        print("Connected to:", conn.url, "(spawned temporary:", conn.started, ")")

asyncio.run(main())

2. Command-Line Interface (CLI)

# Discover locally installed harnesses without starting models
agent-shuttle discover

# Start an A2A server for Codex
agent-shuttle serve codex --workspace . --port 8765

# Start an A2A server for Antigravity (CLI mode)
agent-shuttle serve antigravity --workspace . --port 8766

# Start an A2A server from a profile (OpenCode or Claude Code)
agent-shuttle serve profile --profile .\examples\opencode-ollama.json --workspace . --port 8767

# Query server capabilities, models, and quota limits
agent-shuttle info http://127.0.0.1:8765

# Send a task from the command line
agent-shuttle ask http://127.0.0.1:8765 "Summarize recent changes" --model gpt-5.6-terra

3. Model Context Protocol (MCP)

Start the stdio MCP server:

agent-shuttle-mcp
# or: python -m agent_shuttle.mcp_server

Available MCP tools:

ask_agent(agent_id, prompt, model?, reasoning_effort?, tool_policy?, workspace?): Reuses a matching local A2A server or starts a temporary one. Built-in IDs are codex, antigravity, opencode, and claude_code; the latter two need a profile or an Ollama model.
get_agent_info(agent_id, workspace?): Fetches live models and quotas, starting a temporary server if needed.
ask_antigravity(prompt, model?, reasoning_effort?, workspace?, tool_policy?, turn_timeout_seconds=300): Starts an Antigravity server if one is not running.
ask_codex(prompt, model?, reasoning_effort?, workspace?): Starts a Codex server if one is not running.
get_antigravity_info(workspace?) & get_codex_info(): Read live capabilities and quota without burning model turns.
submit_task(agent_id, prompt, model?, reasoning_effort?, tool_policy?, workspace?, request_id?): Start a long task and return its ID immediately.
check_task(task_id), wait_task(task_id, timeout_seconds?), cancel_task(task_id): Inspect, wait for, or stop a task.
get_result(task_id, cursor?, limit?), get_transcript(task_id, cursor?, limit?): Read bounded pages of output and history.

Key Concepts

Harness Discovery

Run agent-shuttle discover (or discover_harnesses() in Python) to inspect local executables without launching processes or loading weights. It checks PATH and platform-specific standard installation directories (%LOCALAPPDATA%\agy\bin, npm global directories, etc.). Custom paths can be specified via environment variables (BRIDGE_AGY_COMMAND) or CLI flags (--agy-command, --opencode-command, --claude-command).

Model & Reasoning Selection

Model parameters are passed as A2A metadata keys (agent_bridge.model, agent_bridge.reasoning_effort):

Antigravity: Reasoning effort is embedded in model IDs (e.g. gemini-3.8-flash-medium). If both --model and --effort are passed, they must match.
Codex: Model and reasoning effort are configured independently according to the catalog returned by get_codex_info.
OpenCode & Claude Code: Profiles define allowed_models and optional reasoning_efforts (such as model variants for Ollama or CLI flags).

Workspaces & Session Isolation

Every server binds to a strictly validated, canonical workspace directory.
connect_harness() verifies that an existing server's workspace matches the caller's target workspace before reusing it.
Sessions: BridgeSession maintains a stateful conversation across multiple ask() calls. Conversation settings (model, effort, tool policy) are pinned at session creation and cannot be changed mid-session. Idle sessions are cleaned up automatically after 30 minutes.
Library task lifecycle: TaskManager runs agents directly from Python, with no A2A or MCP server. It owns task IDs, sessions, a SQLite event journal, cancellation, result paging, preferences, and interruption recovery. A2A projects the same task ID and result through its protocol; MCP continues to reach those tasks through managed A2A peers. See the Python API.
Remote task lifecycle: ShuttleClient.submit() returns a remote TaskHandle immediately. Use status(), bounded wait(timeout), events(), result_page(), transcript(), result(), or cancel(); reopen a task by ID with client.task(url, task_id). A wait timeout does not stop the agent. An optional UUID request_id deduplicates retried submissions. Standalone servers can persist tasks with --task-db; MCP task tools do this automatically in the workspace's .agent-shuttle directory. Completed results survive restart; interrupted work is marked failed without replay. See the API reference.

Safety & Tool Policies

Agent Shuttle defines four standardized tool policies:

no_tools: Disables tool invocations entirely.
read_only: Permits non-mutating search and file reading.
workspace_write: Allows editing files within the designated workspace.
full_access: Explicitly unclamps all tool restrictions and approval prompts.

WARNING

full_access grants the worker unrestricted tool access for that task. --agy-dangerously-skip-permissions enables that capability for the Antigravity server. Keep servers on loopback. Antigravity's explicit scoped read_only policy is enforced by its verified PreToolUse hook; an implicit/default CLI policy does not provide the same guarantee.

Testing

Agent Shuttle provides a comprehensive offline test suite using fake backends that execute without network access, credentials, or model quota consumption:

python -m unittest discover -s tests -v

Opt-in integration tests against real models can be executed by specifying target environments (e.g. BRIDGE_LIVE_OLLAMA_MODEL=qwen3.5:9b or BRIDGE_LIVE_AGY_FULL_ACCESS=1). See CONTRIBUTING.md for full instructions.

Documentation Index

Available Tools

6 tools

ask_agentC

Ask a configured agent profile from BRIDGE_AGENTS_JSON.

ParametersJSON Schema

Name	Required	Description	Default
`model`	No
`prompt`	Yes
`agent_id`	Yes
`tool_policy`	No
`reasoning_effort`	No

TDQS

C2.1/5.0

Behavior2/5

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

With no annotations, the description carries full behavioral burden and discloses almost nothing: not whether this invokes an external process, whether it is read-only, latency/cost, or how errors surface. The only added context is the configuration source (BRIDGE_AGENTS_JSON), which is minor.

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

Conciseness3/5

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

The single sentence is front-loaded and free of filler, but its brevity reflects under-specification rather than economy — there is nothing else to trim because nothing useful was said.

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

Completeness1/5

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

Five parameters with zero schema descriptions, no annotations, and no output schema leaves the description wholly insufficient. Nothing tells the agent what a valid agent_id is, what the call returns, or how it differs from the sibling ask tools.

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

Parameters1/5

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

Schema description coverage is 0% for all 5 parameters, so the description must compensate and it does not — agent_id, prompt, model, tool_policy, and reasoning_effort are entirely undocumented. An agent cannot know what values tool_policy or reasoning_effort accept.

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

Purpose3/5

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

The verb 'Ask' plus resource 'a configured agent profile' identifies the operation, and the reference to BRIDGE_AGENTS_JSON hints at where agents are configured. However, it gives no differentiation from close siblings ask_antigravity and ask_codex, which appear to do the same thing against different backends.

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?

There is no statement of when to use this tool versus ask_antigravity, ask_codex, or get_agent_info, nor any prerequisites or exclusions. The agent must guess which 'ask' tool applies.

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

ask_antigravityC

Delegate to Antigravity; workspace starts an isolated temporary Bridge.

ParametersJSON Schema

Name	Required	Description	Default
`model`	No
`prompt`	Yes
`workspace`	No
`tool_policy`	No
`reasoning_effort`	No
`turn_timeout_seconds`	No

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations, the description carries the entire burden and mostly doesn't. It hints at an "isolated temporary" workspace/Bridge (some sandboxing signal), but says nothing about authentication, whether the delegation is synchronous, the 300s default timeout's consequences, or what happens if the turn times out.

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

Conciseness3/5

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

It is a single short sentence with no filler, which is a virtue, but the sentence is cryptic rather than front-loaded with the essential use case. Brevity here reflects under-specification more than disciplined editing.

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 six-parameter delegation tool with no annotations and no output schema, the description is far too thin. An agent cannot tell how to set tool_policy, reasoning_effort, or timeout, nor what a delegated turn returns.

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

Parameters2/5

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

Schema description coverage is 0% across six parameters, so the description must compensate and does not. Only "workspace" is alluded to (and cryptically via "Bridge"); model, prompt, tool_policy, reasoning_effort, and turn_timeout_seconds are entirely unexplained.

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

Purpose3/5

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

The description does give a verb and a target ("Delegate to Antigravity"), so the agent can infer it sends a prompt to that engine. However, it never distinguishes this from siblings like ask_agent or ask_codex, and the second clause ("workspace starts an isolated temporary Bridge") is jargon that obscures rather than clarifies the operation.

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?

There is no guidance on when to choose this over ask_agent, ask_codex, or get_antigravity_info — the sibling set makes that routing decision essential. The reader must guess that this is for delegating a prompt to the Antigravity engine specifically.

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

ask_codexC

Delegate to Codex. model and reasoning_effort select its thread settings.

ParametersJSON Schema

Name	Required	Description	Default
`model`	No
`prompt`	Yes
`reasoning_effort`	No

TDQS

C2.7/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 but discloses very little behavior. It notes that model and reasoning_effort select thread settings, which is a small behavioral hint, but it does not say whether the call is read-only, what side effects occur, how the Codex thread is managed, or what the response contains.

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 description is very short and front-loads the core purpose in the first sentence, with the parameter note following. There is no filler, though the second sentence is cryptic and could be folded more cleanly into the first. It is appropriately sized for a minimal tool definition.

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?

The tool has no annotations, no output schema, and 0% schema description coverage across three parameters. The description omits usage guidance, behavioral details, and most parameter semantics, leaving an agent under-informed for selecting and invoking it among several sibling agent tools. It provides only a bare purpose statement and a fragment about thread settings.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate for all three parameters. It only partially addresses two of them by saying model and reasoning_effort select thread settings, and it never explains allowed values, defaults, or the role of the required prompt parameter. This leaves significant semantic gaps.

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 gives a clear verb ('Delegate') and resource ('Codex'), making the tool's high-level purpose recognizable. It implicitly distinguishes from siblings like ask_antigravity or get_codex_info by naming Codex, but it does not explicitly state what kind of delegation occurs or how it differs from ask_agent.

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 when-to-use guidance is provided. The description does not mention alternatives such as ask_agent, ask_antigravity, or get_codex_info, nor does it explain when an agent should choose this tool over them. There is only a bare statement of delegation with no context or exclusions.

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

get_agent_infoB

Read capabilities and quota information for a configured agent profile.

ParametersJSON Schema

Name	Required	Description	Default
`agent_id`	Yes

TDQS

B3/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 the full behavioral burden. It does signal a non-mutating read that returns capabilities and quota, but says nothing about permissions, behavior for an unknown/unconfigured agent_id, or rate limits. Adequate but thin for a no-annotation tool.

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?

One sentence, front-loaded with the verb and the two things returned. No waste, though it is arguably terse given the missing usage and parameter detail.

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?

There is no output schema and no annotations, so the description must also explain the returned capabilities/quota shape and error cases, which it does not. For a simple single-parameter getter it is minimally sufficient, but leaves real gaps.

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

Parameters2/5

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

Schema description coverage is 0% and the single 'agent_id' parameter is undocumented in the schema. The phrase 'a configured agent profile' loosely contextualizes the id, but the description gives no format, source, or validation hints, so it fails to compensate for the coverage gap.

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?

States a specific verb+resource ('Read capabilities and quota information for a configured agent profile'), so the agent knows exactly what comes back. However, it does not distinguish itself from sibling lookups like get_antigravity_info and get_codex_info, which appear to be the same operation scoped to specific agent backends.

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 when-to-use guidance, no prerequisites (e.g. the profile must already be configured), and no naming of the sibling get_*_info alternatives. The agent must infer that this is a pre-flight lookup from the verb 'Read' alone.

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

get_antigravity_infoB

Read Antigravity's current models, effort options and account quota without an agent turn.

ParametersJSON Schema

Name	Required	Description	Default
`workspace`	No

TDQS

B3.3/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 the full burden. It implies a read-only, no-turn operation and enumerates what is returned, but says nothing about permissions, quota implications, or whether the 'account quota' read has any cost or freshness caveat.

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, front-loaded sentence with no filler; the resource contents are listed compactly and the differentiator is placed at the end where it reads naturally.

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?

No output schema exists, so the description's enumeration of returned data is helpful, and no annotations means the safety profile falls to it (reasonably implied as read-only). The undocumented 'workspace' parameter and absent quota/permission caveats leave gaps.

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

Parameters2/5

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

The single 'workspace' parameter has 0% schema description coverage and no mention in the description, so an agent gets no guidance on what it scopes or what the default (null) means. The description fails to compensate for the coverage gap.

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?

Specific verb ('Read') plus the exact resource contents: models, effort options, and account quota. The phrase 'without an agent turn' implicitly separates it from the ask_antigravity sibling, though no sibling is named explicitly.

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?

'Without an agent turn' implies this is the cheap, side-effect-free lookup as opposed to asking the agent, which is a usable contextual cue. However, it neither names the alternative (ask_antigravity) nor states explicit when/when-not conditions.

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

get_codex_infoA

Read Codex's current models, supported efforts and account quota without an agent turn.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It does disclose one meaningful trait — no agent turn is consumed, so the call is side-effect-free relative to conversation state — but says nothing about permissions, cost, caching, or freshness of the quota data.

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, front-loaded sentence with no filler; the resource and the key constraint are packed into one clause and nothing is repeated.

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 no-arg, no-output-schema discovery tool, naming the three returned categories (models, supported efforts, account quota) plus the no-agent-turn behavior covers what an agent needs. Only minor gaps remain, such as how current the quota information is.

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?

The tool takes zero parameters, so per the baseline rule parameter semantics default to 4. The description correctly implies a pure lookup with no inputs to configure.

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?

States a specific verb ('Read') and resource ('Codex's current models, supported efforts and account quota'), naming exactly what is returned. The qualifier 'without an agent turn' implicitly distinguishes it from the sibling ask_codex, though no sibling is named explicitly.

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 phrase 'without an agent turn' hints that this is the cheap, non-conversational lookup versus ask_codex, but the description never states when to prefer it or when not to use it. Usage is implied rather than spelled out.

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.

6 tool updatesv0.5.0Sep 30, 2026
- First observedask_agent
- First observedask_antigravity
- First observedask_codex
- First observedget_agent_info
- First observedget_antigravity_info
- First observedget_codex_info

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

B3.1/5.0

Scored 2026-09-30 10:20 across 6 tools

Disambiguation4/5

The three ask_* tools target different agents (generic configured profiles, Antigravity, Codex), and the three get_*_info tools mirror that structure. However, the generic ask_agent/get_agent_info could be confused with the specific ask_antigravity/get_antigravity_info or ask_codex/get_codex_info if those agents are also configured, requiring careful reading of descriptions.

Naming Consistency5/5

All tool names follow a clear ask_<target> or get_<target>_info pattern in consistent snake_case. The generic 'agent' target versus specific agent names is a meaningful distinction rather than a naming inconsistency.

Tool Count5/5

Six tools is well-scoped for a delegation server, covering ask and info operations for both generic and specific agents without redundancy. Each tool earns its place.

Completeness3/5

The core ask and info operations are present, but there is no list_agents tool to discover which profiles are available in BRIDGE_AGENTS_JSON. This is a notable gap for a server centered on configured agents, as users must already know the agent names.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

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
toolweaveOAuth
io.github.andreysparish
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
App Automation AI & Machine Learning Agent Orchestration
2
RogerRat A
io.github.opcastil11
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
Communication Agent Orchestration
21
Prompeteer AOAuth
ai.prompeteer
Generate contextual prompts and reusable agent skills, evaluate prompts with the 16-dimension Prompt Score, and manage saved work in PromptDrive. Twelve MCP tools also provide authorized access to private Memory for source-grounded answers. Connect over Streamable HTTP using OAuth 2.1 and PKCE. Generation consumes account quota and automatically saves successful results; Memory access follows account permissions and plan limits.
App Automation Developer Tools Product Management
123

Related MCP Servers

claude-code-mcp
xihuai18
A
license
A
quality
D
maintenance
Wraps Claude Code as tools for MCP clients, enabling autonomous coding tasks via a 4-tool lifecycle with session management, async polling, and permission controls.
Updated 6 months ago (2026-04-15 19:47 UTC)
4
59 npm
20
MIT
pokeclaw
Coding Agents Code Execution Command Line
madebydia
A
license
Not graded
quality
D
maintenance
Enables MCP clients to spawn and control Codex CLI and Claude Code sessions on the host machine, with session management and filesystem access.
Updated 4 months ago (2026-06-08 12:59 UTC)
4
MIT
LightsOut
Agent Orchestration Coding Agents
filipeagg
F
license
Not graded
quality
A
maintenance
Agent orchestration system that runs coding-agent sessions (Claude Code, Codex) with policy mediation and exposes tools via MCP.
Updated 15 days ago (2026-09-17 19:33 UTC)
-
pi-agent-mcp
Coding Agents Agent Orchestration Autonomous Agents
a809384377
F
license
Not graded
quality
B
maintenance
Enables MCP hosts like Claude Code and Codex to spawn, manage, and interact with persistent, reusable Pi coding-agent sessions, supporting task dispatch, status checks, and session lifecycle control.
Updated a month ago (2026-08-22 06:12 UTC)
3 npm
-