It is an MCP server that lets multiple AI coding agents work on the same project in parallel by coordinating through a shared board, file locks, notes, and delegation.
Delegate tasks to installed AI CLIs (Antigravity, Copilot, Claude, Codex, Cursor, Gemini, OpenCode, or custom backends) and check status, wait, follow up, or cancel them.
Post, update, and list shared board items so agents can hand off work and stay aligned.
Claim, check, and release file/directory locks to prevent agents from editing the same paths.
Send and read async notes between agents, set presence status, and view an activity timeline.
Get a one-call coordination status: who is online, what is running, what is locked, open tasks, unread notes, and unavailable backends.
Run CLI commands like init, doctor, restart, reset, update, and open a live office dashboard to watch agents work.
Automatically reroute work when a backend hits usage limits, replaying the original brief instead of regenerating it.
Integrates with Windsurf (Codeium's AI coding tool) to enable it to work alongside other agents via the shared coordination server, preventing file conflicts and enabling concurrent work.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@antigravity-mcp-server build the checkout page with Antigravity while you do the payments API"
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.
Let multiple AI agents build your app at the same time — without stepping on each other.
Hand work to Antigravity, Copilot, Codex, Cursor, another Claude — or any CLI you already use. Keep working yourself. Nobody breaks anyone else's files.
Running two AI coding agents on one project sounds like a superpower—right up until they both blindly edit the same file, quietly overwrite each other's work, and gaslight you about who broke the build.
They can't see each other. That's the whole issue.
Related MCP server: asynkor
One small server every agent plugs into. It acts as their shared state, tracking who is doing what and which files are claimed. It gives whichever agent you're talking to the ability to spin up any other AI CLI you have — Antigravity, Copilot, Codex, Cursor, another Claude — to do its chores in the background, while you two keep working in your main window.
YOU talk to whichever agent you already use
│
┌──────────────────────┴───────────────────────┐
│ Claude Code · Cursor · Windsurf · VS Code │
│ Gemini CLI · OpenCode · Antigravity · … │
└──────────────────────┬───────────────────────┘
│ MCP
▼
┌─────────────────────────────────────┐
│ antigravity-mcp-server │
│ │
│ board.json ── shared state │
│ ├─ tasks ..... who does what │
│ ├─ locks ..... files taken │
│ ├─ notes ..... messages │
│ └─ presence .. who is online │
└─────────────────┬───────────────────┘
│ runs in the background
┌──────────────────────┴───────────────────────┐
▼ ▼ ▼ ▼ ▼
agy copilot claude codex your own CLIAny of them can hand work to any other. Nothing here is Claude-only, or Antigravity-only.
Step 1 — have an AI coding tool already installed. Claude Code, the Antigravity CLI, the GitHub Copilot CLI, Cursor, Windsurf, Gemini CLI, Claude Desktop, VS Code, or OpenCode — any one of these is enough to start. If you can already open it in a terminal (or as an app) and chat with it normally, you're set for this step. This package doesn't replace that tool or install one for you — it plugs into whichever one(s) you already have.
Step 2 — install this package and run init:
npm install -g antigravity-mcp-server
antigravity-mcp-server initinit looks at your machine, finds every tool from step 1 that's actually installed, and registers this server into each one automatically — nothing to configure by hand. It also drops a short, self-refreshing note into each tool's global instructions file (~/.claude/CLAUDE.md, ~/.gemini/GEMINI.md, ~/.codex/AGENTS.md, and the like) so the agent keeps knowing what this server is and reaches for it on its own. Pass --no-skill to skip that part.
Step 3 — start a new session. Close and reopen whichever tool(s) you use (a new terminal window, a fresh chat, whatever "restart" means for that tool). A session that was already open won't see the new server until it restarts.
Step 4 — just talk to it normally. That's the whole setup. Open your tool, and say something like "Have Antigravity build the checkout page while you work on payments." Your agent takes it from there — more on that just below.
You'll mostly only ever need the first two.
Command | What it does |
| Find your AI tools and wire them all up. Run again whenever you install a new one. |
| Undo |
| Restart coordination state, terminate hanging UI/workers, and refresh board & clients |
| Open the live office dashboard in your browser |
| Check everything works, and show which AI CLIs are installed |
| Update to the latest version (so you don't have to remember the npm command) |
| Something stuck? Wipe the shared board clean and start fresh |
| Which version am I on? (also |
A host. This is whichever AI coding tool you actually type into day to day — Claude Code, Cursor, Windsurf, Gemini CLI, Claude Desktop, VS Code with Copilot, OpenCode, or even the Antigravity or Copilot CLIs themselves. You need at least one of these already installed; that's what init is looking for when it says it "finds every AI tool on your computer." No host, nothing to plug into.
Delegation backends. This is who your host can actually hand work off to. Presets ship for agy (Antigravity), copilot, claude, codex, cursor-agent, gemini and opencode — and any CLI you have can be added yourself, see Adding your own CLI. You do not need all of them; any combination works, including just one:
Only Copilot CLI and Antigravity installed? Fine — ag_delegate and copilot_delegate both work.
Only a second Claude Code CLI and Antigravity? Same idea — you get ag_delegate and claude_delegate.
None installed yet? You still get the shared board — presence, locks, notes — your agent just can't delegate anywhere until you add a backend.
Tools are only registered for CLIs actually installed on your machine, so your agent is never offered a codex_delegate that can't run. antigravity-mcp-server doctor lists the whole roster and tells you which are present.
When to run init: right after you install this package, and again any time your setup changes — a new host editor, or a new delegation backend CLI you didn't have before. It's safe to run as often as you like: it only touches tools it actually finds on your machine, and it backs up anything it edits first.
You will never need to read the technical tables or learn any new commands.
You simply talk to your agent normally: "Hey, have Antigravity build X while you do Y."
Your agent figures out which tools to call, writes a meticulous brief, politely locks its own files so nobody steps on its toes, fires up the delegated agent in the background, and keeps working with you. Nobody is stuck twiddling their thumbs.
This tool lets you stay in the flow by parallelizing your work. Here is how it makes your life easier:
Work on the backend while another agent builds the UI. Instead of waiting for one agent to finish before starting the next task, split the work.
"Have Antigravity build out the responsive CSS for the header. You stay here and wire up the auth middleware."
Never context-switch to write tests again. You can keep your momentum on feature work and let Copilot handle the tedious parts in the background.
"I need comprehensive unit tests for
store.js. Delegate that to Copilot, and let me know when it's done."
Follow up without repeating yourself. Because the delegated agents keep conversation context, you don't have to write a fresh prompt if something needs tweaking.
"Tell Antigravity to make those buttons we just added actually click properly."
Always know what's happening. If you're curious about a background task, just ask your agent instead of digging through logs.
"What's agy up to right now? Check its status."
Tackle massive tasks with a team of agents. You can delegate anything—not just UI work. Let another agent handle docs, refactors, or backend chores.
"Spin up another Claude instance to document all the public methods in the
/apifolder." "This controller is a mess. Have Antigravity refactor it to use the new service pattern while you and I look at the database migrations."
Avoid editing the same files. The shared board automatically prevents collisions. If you change a core file, you can easily tell the other agent what changed so it adapts.
"We're changing the user schema. Leave a note for the other agent telling it that
idis now a string."
Tell an agent to sit one out.
Running low on Claude usage and want to protect what's left? Just say so — the agent reports itself blocked, hands off whatever it was doing to whoever's free, and the board makes that visible to everyone instead of it just going quiet.
"Don't use Claude for the rest of this task — I'm close to my limit. Hand off what's left to Antigravity."
Want to see your agents actually working? Open the live dashboard:
antigravity-mcp-server uiThis opens a retro pixel-art office at http://localhost:49321. You get a little digital floorplan with one desk per agent identity. You can literally watch them work: their live status, their current task, and who's bossing who around, all driven by the live board.
The sidebar shows a live one-line summary of what everyone's actually doing, right down to their real task:
Run two windows of the same tool at once? They just show up as their own desks — Claude Code, Claude Code 2, Claude Code 3 — instead of quietly fighting over one identity. Click any desk for the full picture: status, task, model, PID, and which directory it's actually working in.
Before an agent edits a folder, it claims it. If an agent tries to take a claimed file, it gets a clear conflict back. No silent overwrites, no broken builds.
my-app/
├── api/ [locked] your agent ← Antigravity is told "taken"
├── db.ts [locked] your agent
├── components/ [locked] Antigravity ← your agent stays away
└── styles/ [locked] AntigravityWhen two agents are building against a shared interface that doesn't exist yet, they can pass messages to each other:
"POST /api/orders is ready. It returns
{ id, status }. Hook the form to it."
Each agent checks what the other is doing before it starts, so it always picks work that fits into the bigger picture.
A finished task releases its own locks automatically — nobody has to remember to clean up after themselves. And if one ever slips through anyway, the next agent to check in sees it immediately: locks tied to work that's already over are called out by name, so it gets fixed instead of silently getting in the way.
Every message between agents costs you money, so the boring stuff is stripped out before it's ever sent. Repeated status checks return "nothing changed" instead of the whole board. A finished agent's 4,000-word answer comes back as a preview until someone asks for the rest. If one agent runs out of budget mid-task, the work moves to another one without rewriting the instructions — they're replayed from disk instead of re-typed by an AI. See Built for speed.
A delegated agent saying it finished doesn't make it true — every agent here is expected to actually check, not just take the other's word for it:
That habit is exactly what catches a delegate that reports success without having really made the change — which happens.
Capability | Single Agent (Vanilla) | Multiple Uncoordinated Agents |
|
Parallel multi-agent coding | ❌ Serial only | ⚠️ Risky (race conditions) | ✅ Full parallel delegation across CLIs |
File collision prevention | N/A | ❌ Silent file overwrites & broken builds | ✅ Exclusive path locks ( |
Shared task board | ❌ None | ❌ None | ✅ Live synchronized state ( |
Inter-agent communication | ❌ None | ❌ Manual copy-pasting by developer | ✅ Native async notes & structured handoffs |
Cross-ecosystem support | ❌ Single IDE/CLI | ❌ Siloed tools | ✅ Claude Code, Cursor, Windsurf, Copilot, Codex, Gemini, OpenCode, Antigravity — any-to-any |
Live visual office UI | ❌ Logs/terminal only | ❌ Logs/terminal only | ✅ Bundled retro pixel-art dashboard ( |
Token & cost optimization | Baseline | High redundant token consumption | ✅ 27–90% payload compression & cached state |
Rate-limit failover | ❌ Task aborts | ❌ Manual re-prompting | ✅ Automatic — work reroutes to a free CLI, brief replayed at zero token cost |
Cross-platform | Varies | Varies | ✅ Windows, macOS, Linux |
AI agents pay for every word they read. This server sits in the middle of a lot of conversations, so it's built to say as little as possible while still saying everything that matters. Real measurements, on a real board:
What was slow or expensive | What changed | Result |
Agents re-read the shared board constantly | Stopped storing each task's full instructions there — they already live on disk, and nothing ever read them back | 113 KB → 50 KB, and it no longer grows forever |
Every reply was pretty-printed for humans nobody was | Send it compact — an AI doesn't need the indentation | ~27% smaller on every single reply |
"Is it done yet?" returned the entire board each time | Ask with a version number; get | Near-zero for a repeat check |
A finished agent returned its full multi-page answer | Head-and-tail preview by default, full text on request | Big answers stop flooding the conversation |
Cost reports came back as a wall of nested numbers | Summarised to what you'd actually read | ~90% smaller |
Moving a task to another AI meant re-writing the brief | Replay the original from disk | A 4,000-token brief moves for free |
Tools offered for CLIs you don't even have installed | Only register what's actually on your machine | Fewer tools, less context, no dead ends |
Two more that aren't about tokens but about not losing your work:
A crashed agent can't wedge the system. File locks now free themselves the moment a task ends, and the shared board can't be corrupted by two agents writing at once — a real bug that was silently losing writes on Windows under load, now stress-tested with six processes hammering it at once.
Nothing blocks. Waiting on another agent never freezes the server; a long job survives your editor restarting.
Can I run Claude Code and GitHub Copilot on the same repo at the same time? Yes — that is what this exists for. Each agent claims the files it is about to edit, and any other agent asking for an overlapping path is told who holds it instead of silently overwriting it. Neither agent needs to know the other exists.
Does one agent have to be in charge? No. Every installed CLI is both a host that can delegate and a backend that can be delegated to. Copilot can hand work to Claude, Codex can hand work to Cursor, Antigravity can hand work to Gemini. There is no privileged agent and no fixed direction.
What happens when an agent hits its usage limit mid-task?
The task moves to another installed CLI automatically. The original brief is replayed from disk
rather than regenerated, so rerouting costs zero tokens, and the reply tells you which backend
picked it up. Pass failover: false on a delegate call if you want it to fail instead.
Does this work on Windows?
Yes — Windows, macOS and Linux. Binary discovery covers Homebrew, ~/.local/bin, npm and pnpm
global prefixes, snaps, Volta, asdf and the usual Windows install locations, and Windows .cmd
shims are launched with proper argument quoting.
Which AI CLIs are supported?
Antigravity (agy), GitHub Copilot CLI, Claude Code, OpenAI Codex, Cursor, Gemini CLI and
OpenCode out of the box. Anything else can be added in ~/.antigravity-mcp/backends.json
without waiting for a release — see Adding your own CLI.
Do I need API keys? No. This coordinates CLIs already installed and signed in on your machine. It never sees a token, never proxies a request, and never talks to a model itself.
Is it another model or a router? Neither. It is an MCP server: a shared board plus a delegation layer. The intelligence stays in the CLIs you already pay for.
How much context does it cost? Only tools for CLIs actually installed are registered — nothing is offered for a CLI you don't have.
Can I see what the agents are doing?
antigravity-mcp-server ui opens a live office dashboard on http://localhost:49321 showing each
agent searching, reading, running commands, editing, or handing work off — never idle while it
is actually busy.
Does memory survive a new session, or a board reset?
Yes — that's the point of it. coop_status (already called before starting work) and brain_read
don't depend on any prior session's own context: a brand-new agent connecting for the first time
sees the same current status and history a session that had been running for weeks would. The
board itself is intentionally the opposite — pruned, and wiped entirely by coop_reset — because
coordination state and durable memory have different lifecycles. See Durable project
memory below.
Why plain markdown for the brain, not vector embeddings or SQLite?
Zero dependencies and total transparency. Markdown files under ~/.antigravity-mcp/brain/ (one
per project) work instantly with no extra installs, no embedding models to download, no Python
toolchain — and can be read, edited, or committed with git like any other project doc. If you
want semantic search instead of substring search, that's a good job for a dedicated memory MCP
server alongside this one; we don't bundle one, to keep working everywhere with zero setup.
The sections below are for developers and the incurably curious. You do not need to read any of this to use the tool!
Your agent picks these on its own using MCP.
Group | Tools |
Hand off to any backend |
|
Shared board |
|
File locks |
|
Talking |
|
Memory |
|
Admin |
|
<prefix> is the backend: ag, copilot, claude, codex, cursor, gemini, opencode, or whatever you named your own. Every lane is symmetric — same shape, same behaviour — so your agent just picks whichever CLI you named, and none of them is a special case. Only lanes whose CLI is actually installed get registered.
claude_delegate launches a fully independent claude CLI process, not a subagent inside the calling session — and because it's a plain claude invocation, it automatically inherits whatever MCP servers are registered at user scope, this one included, so a delegated Claude can call coop_status / claim_paths on itself with no extra setup. The same is true of any backend that speaks MCP, which is what lets agy delegate to Claude, Claude delegate to Copilot, and so on in any direction.
When a backend hits its usage limit, the failure is recognised as a limit rather than a bug, that backend is refused further work until it resets (and shown blocked in the office UI), and coop_status lists it under unavailable_backends with a reset time. The work then moves on its own: a delegation aimed at an exhausted backend is rerouted to another installed CLI before it ever spawns, and a task that dies mid-flight on a limit is picked up by the next available one. Either way the original brief is replayed from disk — it never passes through the model again, so moving a 4,000-token delegation costs nothing — and the reply names the backend that took it. Failover stops after three backends, so a genuinely broken brief can't tour every CLI on the machine. Pass failover: false on a delegate call to opt out, or use task_reassign(task_id, to) to move work by hand for any other reason.
Worth knowing:
coop_status — one call answers everything: who's online, what's running, what's locked, what's unread. It also reaps every running task's real status first, and any lock still standing for a task that's already over is flagged orphaned with the reason why -- a finished task releases its own locks automatically, so a flag here means something slipped through (an old lock claimed without a task_id, say), not routine cleanup. Every response carries a seq; pass it back as since_seq on your next call and, if nothing changed, you get {unchanged: true} instead of the full payload. Empty sections (no locks, no unread notes, nothing active) are omitted from the response entirely rather than sent as empty arrays. Anything board_post'd to you that's still sitting at open shows up here every time, with a nudge in the hint, until you actually move it off open -- an assignment can't just get lost.
board_post — assigning something to another agent also sends them a note automatically, so it doesn't depend on them happening to check board_list.
<prefix>_followup — carries on the same conversation, so you don't re-explain context.
*_task_status / *_task_wait — a long response comes back as a head/tail preview by default, not the whole thing; pass output_mode: "full" when you actually need every character. include_usage_detail: true gets you the backend's raw token/cost breakdown instead of the {input_tokens, output_tokens, total_tokens} summary returned by default.
coop_status, board_post and friends are deliberately ephemeral — the board gets pruned, and coop_reset wipes it entirely. That's the right lifecycle for coordination state, but it means nothing an agent learns survives a reset or a brand-new session on its own. brain_write / brain_read / brain_search are the separate, durable answer: plain markdown, one file per project, that a session with zero prior context can read from its very first coop_status call.
Each project gets one file with three sections:
Current Status — one paragraph, overwritten on every brain_write({section: "status"}) call, not appended. This is the one deliberate exception to append-only in the whole feature: "where does this stand right now" only has one true answer at a time, and a growing log of every past status wouldn't tell a new session which one is current.
Key Decisions — append-only, for the rare, durable architectural call.
Log — append-only, timestamped and agent-attributed, for routine progress notes.
coop_status surfaces a small, capped preview of all three (status first) as project_memory, omitted entirely when a project has no memory yet — so the common case costs nothing. brain_search is scoped to the current project by default, same as brain_write/brain_read — being in one project shouldn't surface another, unrelated one unasked. Pass all_projects: true for "have we hit this before, anywhere," or cwd to search one specific other project.
Files live under ~/.antigravity-mcp/brain/ by default (or ANTIGRAVITY_MCP_BRAIN, if set) — plain files, so they're readable, git-committable, and happen to also be an openable Obsidian vault if you have it (any folder is, via "Open folder as vault") with zero setup on either side. This project never detects or writes into an existing vault of yours; that stays your explicit choice via ANTIGRAVITY_MCP_BRAIN, never something done for you.
~/.antigravity-mcp/
├── board.json shared state, written under a lock
├── runs/
│ ├── <task_id>.json agy's raw result
│ ├── <task_id>.prompt.txt the brief that was sent
│ └── <task_id>.err stderr, if the run failed
└── brain/ durable memory (or wherever ANTIGRAVITY_MCP_BRAIN points)
├── MEMORY.md index, one line per project
└── Projects/
└── <slug>.md one file per project -- status, decisions, logboard.json holds tasks, locks, notes, events, and presence. Every write takes an exclusive lock (an atomically created directory — the one primitive that behaves the same on Windows and POSIX), then lands via write-temp-and-rename, so a crash can't leave a half-written board. Stale locks older than 20s are broken automatically.
There's no SQLite. A native build would break npx on machines without a compiler, and node:sqlite is still experimental and Node 22+. The board takes a handful of small writes per minute, so a JSON file is the right size of tool.
Every brief gets the same short working agreement prepended before your task text: do what was asked and stop (report anything else you spot rather than fixing it), edit the files you were given without stopping to ask, verify with a real build/test before claiming done, hand off cleanly if you run out of room, and make the final message a handoff rather than a transcript. It's five lines because each one is a failure this board has actually seen — a delegate gold-plating a one-file fix, or reporting work it never did.
Each backend is a spec in src/backends.js saying where its binary lives, how to build its argv, and how to read its answer — so <prefix>_delegate, _followup, _task_status, _task_wait and _cancel are generated per backend rather than hand-written five times. A backend whose CLI can't resume a session by id (gemini, currently) simply gets no _followup tool rather than a flag invented for it.
ag_delegate shells out to:
agy --print <brief> --output-format json --print-timeout <n>s \
--add-dir <cwd> --mode accept-edits --dangerously-skip-permissionscopilot_delegate shells out to:
copilot -p <brief> --output-format json --add-dir <cwd> --allow-all-toolsclaude_delegate shells out to:
claude <brief> --print --output-format json --add-dir <cwd> --dangerously-skip-permissionsEvery backend is spawned detached, with output redirected straight to runs/<task_id>.json. That means a long job survives the MCP server being restarted — status is recovered by reading the run file and checking the PID, not by holding a child handle. Output shapes differ (agy and claude each emit one JSON object; copilot streams JSONL terminated by a type: "result" line), so each spec says how to read its own, and all of them are normalised to the same {status, response, conversation_id, usage} before landing on the board. The rest of the server never learns which backend produced them.
ag_followup reuses agy's conversation_id via --conversation; copilot_followup reuses Copilot's session id via --resume; claude_followup does the same via claude's own --resume. Context carries across calls. Note: copilot and claude have no session-level timeout flag (agy's --print-timeout has no equivalent on either) — a hung job just stays "running" until it exits on its own or the matching *_cancel kills it.
The built-in presets are just presets. Whatever coding CLI you use, if it can take a prompt non-interactively and print an answer, you can delegate to it — drop a backends.json in ~/.antigravity-mcp/ (or wherever ANTIGRAVITY_MCP_HOME points):
{
"backends": [
{
"id": "mycli",
"label": "My CLI",
"bin": "mycli",
"args": ["run", "{prompt}", "--json"],
"flags": { "model": "--model", "cwd": "--dir", "resume": "--session", "addDir": "--add" },
"autoApprove": ["--yolo"],
"output": { "format": "json", "response": "result", "session": "id" }
}
]
}Restart your agent and you have mycli_delegate, mycli_followup, mycli_task_status, mycli_task_wait and mycli_cancel, plus a mycli-agent desk in the office UI. {prompt} and {cwd} are substituted; flags are only added when that option is actually used, and output.format is json, jsonl or text (response/session are dot-paths into the CLI's output). Use the same id as a built-in to override it — handy if a preset's flags are wrong for your version, since you don't have to wait for a release to fix it.
Paths are normalised with path.resolve and case-folded on Windows, so C:\Proj and c:\proj can't defeat the same lock. Overlap is checked in both directions — claiming api/routes.ts conflicts with a held api/, and claiming api/ conflicts with a held api/routes.ts.
Each side runs the same binary with a different --agent <id>. That id is what every board entry is attributed to. Two clients sharing one id makes their locks invisible to each other, which defeats the whole point.
Two sessions launched with the same --agent <id> are handled automatically -- the second one gets <id>-2, a third <id>-3, and so on, decided the instant it starts up, the same way a second copy of a file or window commonly gets "(2)" appended. Nothing to configure; it just works, whether the two sessions are two windows of the same tool, or genuinely unrelated processes that happened to pick the same id.
The board itself is still global unless you change its home directory: every project and every session on the machine points at the same shared board.json by default. Auto-numbering keeps sessions from colliding, but the number alone doesn't tell you which is which -- if you'd rather have meaningful, chosen names (claude-code-project-a instead of claude-code-2), give each one a distinct --agent <id> yourself. A tool's config is normally one global file (~/.claude.json and similar), so the same entry applies to every window it opens; getting a different --agent per project means using that tool's project-local config instead (Claude Code, for one, reads a repo-level .mcp.json if present, layered on top of the global one) -- one file per project, not one shared file with two entries:
// project-a/.mcp.json
{
"mcpServers": {
"antigravity": {
"command": "antigravity-mcp-server",
"args": ["--agent", "claude-code-project-a"]
}
}
}// project-b/.mcp.json
{
"mcpServers": {
"antigravity": {
"command": "antigravity-mcp-server",
"args": ["--agent", "claude-code-project-b"]
}
}
}(init doesn't generate project-local configs today -- it only writes the global ones in the table below -- so for now this means editing that file by hand per project. Two windows on the same project, sharing the exact same config, still just get auto-numbered like any other collision -- that's what the automatic handling above covers.)
For full isolation -- not just a distinct identity, but an entirely separate board -- set a different ANTIGRAVITY_MCP_HOME per project the same way, instead of (or in addition to) a distinct --agent.
coop_status also carries an identity_collision field as a backstop, for the rare case two processes end up on the same identity despite the auto-numbering (e.g. COOP_AGENT set directly instead of going through --agent). Look for it and the matching hint text if something still seems to be sharing a slot.
If an identity's status looks permanently stuck, or the board seems to be carrying state from an old version, antigravity-mcp-server reset --yes wipes it clean (tasks, locks, notes, presence -- everything) and tells you to restart your sessions afterward. It resets the whole board, including anything other active sessions or other projects currently have on it, so use it when something is actually stuck, not routinely.
init only touches tools it finds, and backs up any file it edits to <file>.bak-antigravity-mcp.
Alongside the MCP config, init writes a marker-delimited managed block
(<!-- BEGIN antigravity-mcp-server … --> … <!-- END antigravity-mcp-server -->) into
each tool's global instructions file — ~/.claude/CLAUDE.md, ~/.gemini/GEMINI.md
(shared by Gemini CLI and Antigravity), ~/.codex/AGENTS.md, ~/.config/opencode/AGENTS.md,
~/.codeium/windsurf/memories/global_rules.md. Re-running init replaces the block in
place; delete the block to remove it, or run init --no-skill to leave these files
untouched. Tools with no stable global instructions file (Cursor, Claude Desktop, VS Code)
rely on the server's MCP instructions string instead.
Tool | Config path | Key |
Claude Code |
|
|
Cursor |
|
|
Windsurf |
|
|
Gemini CLI |
|
|
Claude Desktop |
|
|
VS Code (Copilot) |
|
|
OpenCode |
|
|
Antigravity CLI |
|
|
Antigravity IDE |
|
|
GitHub Copilot CLI |
|
|
You can also run these variations:
antigravity-mcp-server init --dry-run # show changes, write nothing
antigravity-mcp-server init --all # also write configs for tools you haven't installed
antigravity-mcp-server init --no-skill # register MCP config only, skip the global-memory block
antigravity-mcp-server init --only claude-code,cursor
antigravity-mcp-server init --global # force the direct-command form
antigravity-mcp-server init --npx # force npx, even with a global install presentA global install is worth the extra step over npx: your editor spawns this server on every session, and npx re-checks the registry on each launch and can silently pull a newer version mid-session — which matters here, since both agents need to speak the same board schema. A global install starts instantly and only changes version when you run npm update -g yourself. init detects a global install automatically and writes the direct command into every config; it only falls back to npx if it can't find one. No install (npx antigravity-mcp-server init) is fine if you just want to try it once.
npm v7+ deliberately runs no script when a package is removed, so npm uninstall can't clean up after itself. Run deinit first — it reverses everything init did: unregisters the server from every client config, strips the managed block from every global instructions file (~/.claude/CLAUDE.md, ~/.gemini/GEMINI.md, …), and removes the agy permission rule.
antigravity-mcp-server deinit # then:
npm uninstall -g antigravity-mcp-serverdeinit --dry-run previews it; deinit --skill-only removes just the instructions block and leaves the MCP registration alone. Every file it edits is backed up to <file>.bak-antigravity-mcp first. Package managers that still honour preuninstall (Yarn 1, pnpm with pre/post scripts enabled) run deinit automatically; npm does not. If the package is already gone, the block is plain text between <!-- BEGIN antigravity-mcp-server … --> and <!-- END antigravity-mcp-server --> markers — delete it by hand.
Long jobs are safe. Every backend runs detached. If your editor or the server restarts, the job keeps going.
Delegated agents edit without asking. ag_delegate passes --dangerously-skip-permissions; copilot_delegate passes --allow-all-tools (the documented minimum Copilot needs to write files in non-interactive mode). Pass auto_approve: false on either to make it stop at prompts instead.
One trap init handles for you, for agy. In headless mode agy auto-denies every MCP call unless allow-listed in ~/.gemini/antigravity-cli/settings.json. If that rule is missing, delegation still runs but coordination silently does nothing — the worst kind of failure, because it looks like it works. init adds mcp(coop/*); doctor checks for it. Copilot has no equivalent trap: it was verified working with a plain copilot mcp add --transport http and no extra permission rule.
Some CLIs default to their own scratch project unless the target directory is in their workspace. Every hand-off passes the project root explicitly, both as a flag and in the brief.
You need: Node 18.17 or newer, and at least one delegation target. You get the shared board either way — a missing CLI just means you can't hand work to that one.
antigravity-mcp-server doctor # is everything working?
antigravity-mcp-server doctor --probe # same, plus a real round trip through agy
antigravity-mcp-server update # forgot the npm command? this finds your global install and updates itupdate figures out how you're running this and does the right thing: a real global install gets npm install -g to the latest version (with live output, so you can watch it happen); running via npx already re-fetches latest on every launch, so it just tells you there's nothing to do; running from a git checkout (like this one) tells you to git pull instead, since there's no package to update.
After updating:
Restart your MCP clients so they pick up the new server version.
Run antigravity-mcp-server init if required, to refresh client configs or register newly supported backends and tools.
Run antigravity-mcp-server reset --yes if required, to clear stale locks or stuck tasks from previous versions.
| Path to that binary, if it isn't on your PATH |
| Same, for the other presets |
| Same again, for any backend you add yourself |
| Board location (default |
| Where to look for other agents' transcripts and usage caches (default |
| Durable memory location (default |
| The name this instance uses on the board |
| Add your own CLI, or override a built-in preset |
While antigravity-mcp-server init configures your installed tools automatically, you can also configure any client manually:
npx -y @smithery/cli install antigravity-mcp-server --client claudeclaude_desktop_config.json){
"mcpServers": {
"antigravity": {
"command": "npx",
"args": ["-y", "antigravity-mcp-server", "--agent", "claude-desktop"]
}
}
}~/.cursor/mcp.json or .cursor/mcp.json){
"mcpServers": {
"antigravity": {
"command": "npx",
"args": ["-y", "antigravity-mcp-server", "--agent", "cursor"]
}
}
}~/.codeium/windsurf/mcp_config.json){
"mcpServers": {
"antigravity": {
"command": "npx",
"args": ["-y", "antigravity-mcp-server", "--agent", "windsurf"]
}
}
}~/.claude.json){
"mcpServers": {
"antigravity": {
"command": "antigravity-mcp-server",
"args": ["--agent", "claude-code"]
}
}
}~/.gemini/config/mcp_config.json)Name the server coop, use --agent antigravity:
{
"mcpServers": {
"coop": {
"command": "antigravity-mcp-server",
"args": ["--agent", "antigravity"]
}
}
}And add permission approval in ~/.gemini/antigravity-cli/settings.json:
{
"permissions": {
"allow": ["mcp(coop/*)"]
}
}settings.json or %APPDATA%/Code/User/mcp.json){
"servers": {
"antigravity": {
"command": "npx",
"args": ["-y", "antigravity-mcp-server", "--agent", "vscode"]
}
}
}git clone https://github.com/adeelali4/antigravity-mcp
cd antigravity-mcp
npm install
npm test # 26 checks, two live stdio clients, no CLI credits used
node test/delegation.js # real end-to-end run through agy (uses agy credits)
node test/delegation-copilot.js # real end-to-end run through copilot (uses Copilot credits)
node test/delegation-claude.js # real end-to-end run through another claude (uses API usage)
node src/cli.js init --local --dry-runnpm test spawns two real MCP clients as separate processes against one board, so cross-process locking and messaging are covered for real rather than mocked.
MIT · built by adeelali4
Recent timeline of what both agents have done -- delegations, claims, releases, notes, status changes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It implies the tool is read-only (a timeline), but does not explicitly state it is non-destructive. It also omits details like ordering (presumably chronological), pagination, or whether the timeline is real-time. The phrase 'Recent timeline' suggests a limit, but the limit parameter is not mentioned in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, efficiently conveying the core purpose. It is front-loaded with the key idea ('Recent timeline of what both agents have done'). Every word adds value, though the list of activity types could be slightly trimmed or omitted if the schema already structured them. Overall, it is concise without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (one optional parameter, no output schema, no annotations), the description is minimally adequate. It tells what the tool returns (a timeline of specific activities) but does not specify the return format, ordering, or how to use the 'limit' parameter. For a tool with no output schema, more detail on the structure of the returned timeline would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'limit' (integer) with no description (0% schema coverage). The description does not mention 'limit' or explain its purpose (e.g., 'maximum number of events to return'). While the parameter name is intuitive, the description adds no value beyond what the schema provides, failing to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 'Recent timeline of what both agents have done' and lists specific activity types (delegations, claims, releases, notes, status changes). It distinguishes from siblings like 'board_list' (board posts) and 'notes_read' (notes only) by implying a combined view. However, it lacks an explicit verb like 'List' or 'View', which slightly reduces precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. For example, it does not mention that for agent-specific task status you should use 'ag_task_status', or for board posts use 'board_list'. The description lists included activities but provides no exclusion criteria or context for choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a running delegated Antigravity task and release any paths it held.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that cancelling releases held paths, which is a useful side effect. However, it does not state whether the task must exist, whether cancellation is idempotent, or what happens to associated resources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words that is front-loaded with the key action. Every word earns its place; there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one required parameter, no output schema, no annotations, and moderate complexity (cancellation semantics), the description is too sparse. It lacks necessary details about task state assumptions, error cases, and the effect on the task's lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the parameter 'task_id', and the description does not provide any additional meaning about it (e.g., format, expected values, or how to obtain it). The description adds no value beyond the schema's type and required flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop a running delegated Antigravity task') and the side effect ('release any paths it held'), making the purpose immediately understandable. It distinguishes from sibling tools like ag_delegate (start) and ag_task_status (status check).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for cancelling a running task, but provides no explicit guidance on when to use it versus alternatives (e.g., if the task is already finished, you might use ag_task_status instead). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hand a task to Antigravity. Starts agy headlessly as a detached background job and returns immediately with a task_id -- it does NOT block, so keep working on your own part meanwhile.
Write prompt as a complete, self-contained brief: Antigravity cannot see your conversation or your context. State the goal, the stack and conventions actually in use, the files it owns, what it must NOT touch, and the API/prop contract it must code against.
claim locks paths for Antigravity up front so you stay off them. auto_approve passes --dangerously-skip-permissions so it can edit unattended.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | Absolute path to the project root | |
| mode | No | ||
| claim | No | Paths Antigravity will own | |
| model | No | e.g. gemini-3.1-pro-high for hard UI work | |
| title | Yes | Short label for the board | |
| effort | No | ||
| prompt | Yes | Self-contained brief; Antigravity starts cold | |
| add_dirs | No | ||
| auto_approve | No | ||
| timeout_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly discloses the async non-blocking nature, the detached background job behavior, and the effect of auto_approve on permissions. It could improve by noting whether there are rate limits or resource implications, but covers the key behavioral traits well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and front-loaded with the key async behavior. Every sentence adds value, but it could be slightly more structured by grouping parameter guidance at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 params, no annotations, no output schema), the description does a good job covering the key decisions: async behavior, claim mechanism, prompt construction, auto_approve risk. Minor gaps: no return value description, no error handling guidance, but overall sufficient for a tool that delegates to another agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, so the description must compensate. It adds meaning beyond the schema for key parameters: explains prompt must be a complete brief (schema only says 'self-contained brief'), claim means path reservation, auto_approve means skip permissions. It does not document all 10 parameters (cwd, mode, model, effort, add_dirs, timeout_seconds), but the core behavioral params are well explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb-resource pair ('Hand a task to Antigravity') and immediately clarifies the async, non-blocking behavior ('returns immediately with a task_id -- it does NOT block'). This clearly distinguishes it from synchronous siblings like coop_status or ag_task_wait.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to 'keep working on your own part meanwhile' and explains when to use claim ('locks paths for Antigravity up front so you stay off them') and auto_approve ('passes --dangerously-skip-permissions so it can edit unattended'). It also instructs how to write the prompt as a self-contained brief, providing clear when-to and how-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a follow-up into the SAME Antigravity conversation as a finished task, so it keeps its context (e.g. 'now make the header responsive'). Use this rather than a fresh ag_delegate whenever the request builds on work it just did.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| task_id | Yes | ||
| timeout_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the key behavioral trait that the tool keeps context from the previous task. However, it does not mention required permissions, whether the task must be 'finished' (as stated), rate limits, or any side effects. The description adds some value but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and usage guidance. Every sentence adds value, and there is no extraneous text. The structure is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (2 required), no output schema, and no annotations, the description is insufficient. It does not explain the task_id format, what timeout_seconds controls, or the return value. It also does not clarify whether the 'finished task' condition is a requirement or a hint. The description leaves many critical details undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema provides no property descriptions. The description does not explain the meaning of any parameter (task_id, prompt, timeout_seconds). It only gives an example prompt in the quote. This is a critical failure to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a follow-up into the same conversation as a finished task, using 'prompt' as the follow-up request. It contrasts with the sibling 'ag_delegate' by noting context preservation. The phrasing 'as a finished task' is slightly ambiguous, but the example clarifies the intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use this tool ('whenever the request builds on work it just did') and when not to use it (by contrast with 'ag_delegate'). This is excellent guidance for tool selection, directly addressing the distinction from the most relevant sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a delegated Antigravity task: running / done / failed, plus its final response and conversation_id once finished.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| include_output | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses that the tool returns status, final response, and conversation_id, and implies it can be called while running (since 'running' is a status). However, it does not state whether it is read-only (safe to call repeatedly), what happens if the task_id is invalid, or if there are any side effects. It provides basic transparency 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 18 words, front-loading the purpose and key outputs. Every word adds value; there is no fluff or repetition. It is efficiently structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, no output schema, and no annotations, the description is insufficient. It explains the purpose and return values but omits parameter meanings, error scenarios, and usage context relative to sibling tools. An agent cannot fully determine correct invocation without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 the two parameters. The description does not mention 'task_id' or 'include_output' at all. It only hints at output via 'final response and conversation_id', but the boolean parameter for controlling output inclusion is completely unexplained. This is a critical gap for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks the status of a delegated Antigravity task, listing possible statuses (running/done/failed) and what additional data is returned (final response, conversation_id). It distinguishes from siblings like ag_task_wait (which waits) and ag_cancel (which cancels) by focusing on polling/checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool vs alternatives (e.g., ag_task_wait, ag_followup). It does not mention prerequisites, such as the task_id coming from a delegated task, nor does it advise against calling it before the task starts or how to handle errors. The agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Block until a delegated Antigravity task finishes, or until timeout. Prefer ag_task_status and doing your own work in between -- only wait when you genuinely cannot proceed without Antigravity's result.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| timeout_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly discloses the key behavioral trait of blocking execution ('Block until...'), which is a critical piece of information not captured by any annotations (none provided). However, it could additionally mention what happens on timeout (e.g., error return vs. graceful handling), hence a 4 rather than 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core blocking behavior, and every part adds value. There is zero waste or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no output schema, and no annotations, the description covers the key semantics (blocking, timeout, preference for non-blocking approach). It could benefit from a brief note on return value or error behavior, but overall it is adequately complete for a simple blocking wait tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 the lack of parameter info. The description implies the task_id refers to a 'delegated Antigravity task' and hints at the timeout_seconds parameter via 'or until timeout'. This adds meaningful context beyond the bare schema definitions, but does not fully elaborate on each parameter's format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Block') and resource ('delegated Antigravity task'), clearly distinguishing the tool's synchronous blocking behavior from its sibling ag_task_status. It also specifies the timeout condition, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('only wait when you genuinely cannot proceed without Antigravity's result') and recommends an alternative approach ('Prefer ag_task_status and doing your own work in between'). This provides clear guidance on when not to use it, which is crucial given the blocking nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List board items and delegated tasks. Filter by owner to see just one lane.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| owner | No | Agent id; omit for all | |
| include_done | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It fails to mention whether this operation is read-only, what happens if the board is empty, performance implications of large lists, or any side effects. For a listing tool, the behavior is relatively simple, but the lack of annotations and any safety context leaves the agent without important behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that convey the main purpose and a key filtering option. There is no wasted text, and the information is front-loaded. Every sentence adds value relative to the tool name and title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description should compensate by explaining return format, pagination behavior (if any), and default values for limit and include_done. The absence of these details leaves the agent guessing about how many items are returned and what status items are included by default.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low at 33%, meaning only 1 of 3 parameters has a schema description (owner: 'Agent id; omit for all'). The tool description adds a semantic hint about 'Filter by owner' aligning with the owner parameter, but it does not explain limit or include_done beyond what the schema provides. Baseline 3 is appropriate given the partial coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List board items and delegated tasks' which gives a clear verb and general resource. It also adds scoping detail with 'Filter by owner to see just one lane.' While it doesn't explicitly distinguish itself from siblings like board_post or board_update, the purpose is clear enough to separate it from tools with different verbs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks guidance on when to use this tool versus alternatives. With 15 siblings including board_post, board_update, ag_delegate, and several other listing tools (e.g., check_paths, notes_read), there is no explicit when-to-use or when-not-to-use advice, no prerequisites, and no mention of alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Put an item on the shared board WITHOUT executing it -- a plan entry, a hand-off, or an announcement that you are about to do something, so the other agent can see it. Use ag_delegate instead when you want Antigravity to run it now.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | ||
| owner | Yes | Agent id, or 'unassigned' | |
| title | Yes | ||
| detail | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It clearly states that the action is non-executing (write without running), but does not elaborate on idempotency, overwrites, error handling, or any side effects. It adds some value by saying 'so the other agent can see it' (implying persistence), but lacks depth expected for a mutation tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long. The first sentence effectively states the purpose and gives concrete examples. The second sentence provides a direct alternative. Every sentence earns its place with no verbosity or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters with poor schema coverage, no output schema, and no annotations. The description covers purpose and usage guidelines but omits critical context: what the tool returns (if anything), parameter format guidance, constraints (e.g., limits on board items), and whether posting is additive or overwrites. Given the complexity of a shared-board communication tool, this is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'owner' has a description in the schema). The description adds no additional meaning to any of the four parameters: cwd, owner, title, detail. It does not explain that 'title' is a short subject, 'detail' is optional body text, or how 'cwd' influences behavior. For a tool with this low coverage, the description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('put an item') and clearly identifies the resource ('shared board'). It enumerates typical use cases (plan entry, hand-off, announcement) and distinguishes this tool from the sibling 'ag_delegate' by emphasizing that board_post does NOT execute the item. This provides strong purpose clarity and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (for non-execution items like plan entries, hand-offs, announcements) and when to use an alternative ('Use ag_delegate instead when you want Antigravity to run it now'). This gives the agent clear decision guidance, especially given the presence of ag_delegate in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a board item's status or owner, or attach a progress note. Keep your own items current here so the other agent is not guessing.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| owner | No | ||
| status | No | ||
| task_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It correctly indicates this is a mutation tool ('update'), but doesn't disclose what happens to fields not provided (left unchanged? cleared?), whether a note is required for certain status changes, or any permission/auth requirements. Annotations being empty makes a 3 reasonable – not misleading but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, followed by a usage hint. Efficient and no wasted words. Could be slightly more structured with param details, but good for its compactness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (1 required, 1 enum), no output schema, and no annotations, the description covers the basics but lacks depth. Missing: behavior for partial updates, required note for certain statuses, and return value description. Adequate for a simple tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must compensate. It does mention the three updatable fields (status, owner, note) and groups them, giving some semantics. But it doesn't explain each parameter's meaning, constraints, or interplay (e.g., can you update status without note?). With 4 parameters and no schema descriptions, more param-level context would improve agent usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: updating a board item's status, owner, or attaching a progress note. This distinguishes it from siblings like 'board_post' (which presumably creates) and 'board_list' (which reads). However, it doesn't explicitly name any sibling for differentiation, so it's not a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage hint in the second sentence: 'Keep your own items current here so the other agent is not guessing.' This implies when to use it (for tasks you're working on) but doesn't give explicit when-not-to-use guidance or name alternative tools for specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask whether specific paths are free before touching them. Cheaper than claiming when you only want to read the situation.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It indicates a read-only operation ('before touching them', 'read the situation') and mentions lower cost, but does not explicitly state that it has no side effects or what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero wasted words. The purpose and usage guidelines are front-loaded and immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the core functionality and usage context. However, it does not describe the return value (e.g., boolean per path) or clarify what 'free' means, which would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), so the description must compensate. It explains that 'paths' are the specific paths to check, but provides no further details on format, constraints, or semantics beyond the array of strings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if paths are free, using the verb 'ask' and 'free', and distinguishes from siblings like claim_paths by noting it's 'cheaper than claiming' when only reading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use: 'Ask whether specific paths are free before touching them' and 'Cheaper than claiming when you only want to read the situation.' It also implies not to use it when you intend to claim.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lock files or directories you are about to edit, so the other agent stays off them. A directory lock covers everything under it. Returns granted vs conflicts -- if a path is held by the other agent, do NOT edit it; pick different work or send a note asking for a hand-off.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| paths | Yes | ||
| task_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively covers key behavioral traits: the lock action, scope (directory locks cover subpaths), return value (granted vs conflicts), and required conflict response. It lacks details on async/blocking behavior, authentication, or rate limits, but covers the essential operational behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, no filler, front-loaded with the core action. Each sentence adds essential information: what it does, scope, and what to do on conflict. Ideal length for a straightforward locking tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description briefly notes the return format ('granted vs conflicts') but does not detail the exact structure or error cases (e.g., network failure, already locked by same agent). The sibling context helps disambiguate, but the description leaves moderate gaps in what the agent can expect as a response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description only elaborates on 'paths' (files/directories to lock). It does not explain the 'note' or 'task_id' parameters, leaving their purpose unclear. The agent would need to infer or guess their meaning, which is insufficient for a tool with 3 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lock' and the resource 'files or directories you are about to edit'. It distinguishes itself from siblings like release_paths and check_paths by specifying the action of claiming/locking for exclusive editing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool ('before editing'), what to avoid ('if a path is held by the other agent, do NOT edit it'), and provides alternatives ('pick different work or send a note asking for a hand-off'). No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear the whole board -- tasks, locks, notes, events, presence. Destructive; requires confirm=true. Use when starting a fresh project.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses that the operation is destructive, requires confirm=true, and lists exactly what will be cleared, giving the agent a clear safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tightly worded sentence delivers the purpose, scope, safety warning, and usage context with no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive one-parameter tool with no output schema, the description covers what is cleared, when to use it, and the confirmation requirement; it could explicitly mention irreversibility but the 'Destructive' label suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists no descriptions, but the description explicitly states that confirm=true is required, clarifying the sole parameter's purpose and correcting the schema's optionality.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it clears the whole board and enumerates the elements (tasks, locks, notes, events, presence), distinguishing it from sibling tools like board_update or board_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a specific use case ('Use when starting a fresh project') and warns that it is destructive, but does not explicitly name alternative tools or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-stop situational awareness: who is online, what each agent is running, which paths are locked, open tasks, and unread notes addressed to you. Call this before starting work or editing files so you do not collide with the other agent.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses what information is returned (online status, running tasks, locked paths, etc.), implying a read-only operation. It does not mention whether data is real-time or cached, but for a status tool this is minor. Overall, sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first lists the tool's output, second provides usage guidance. Every sentence adds value, no fluff. Front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists all the categories of information returned (online agents, running tasks, locked paths, tasks, notes). With no output schema, this is fairly complete. It could be slightly more explicit about the output format (e.g., returns a summary object), but for a simple status check it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. Baseline for 0 parameters is 4. The description does not need to add parameter info, and it correctly omits any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'one-stop situational awareness' and lists specific items: who is online, running tasks, locked paths, open tasks, and unread notes. This distinguishes it from siblings like coop_reset, ag_delegate, or presence_set, which are more focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this before starting work or editing files so you do not collide with the other agent.' This gives clear when-to-use context and the rationale, making it easy for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read messages the other agent left for you.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| mark_read | No | ||
| unread_only | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior beyond what structured fields offer. It fails to state whether reading messages has side effects (e.g., marking as read), requires authentication, or is destructive. The description is minimal and does not cover safety or operation traits like idempotency. This is a significant gap for a tool that reads user-specific data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise, but it borders on under-specification. It conveys the core action without any waste, but the structure lacks front-loading of critical details like parameter effects or when to use. It earns a 3 because it is efficient yet misses opportunities to pack key info into the brief format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no output schema, and no annotations, the description is not nearly complete. It does not address return format, pagination (implied by 'limit'), or the effect of 'mark_read'. For a read operation with parameters influencing state, this leaves significant unknowns for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no parameter documentation. The description does not explain any of the three parameters (limit, mark_read, unread_only) or how they affect behavior. Without clarifying these, the agent cannot effectively configure usage. The description adds no semantic value beyond the raw property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads messages left by another agent ('Read messages the other agent left for you'). The verb 'read' and the resource 'messages' are specific. While it distinguishes from 'notes_send' and lists of other tools, it could be more explicit about the source being other agents (not system) and that it retrieves messages addressed to you.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like 'coop_status' or 'ag_task_status'. The description does not mention scenarios for reading messages, prerequisites (e.g., having received messages), or when not to use it (e.g., for sending messages). The sibling tools list provides context, but the description itself lacks usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Leave a message for the other agent -- an interface contract, a hand-off, a heads-up that you changed something they depend on. Make it self-contained and concrete: 'POST /api/orders is live, returns {id, status}. Wire the form to it.'
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Agent id, or 'all' (default) | |
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only says 'Leave a message' without explaining side effects, persistence, whether notes are delivered, appended, or overwritten, or any authorization requirements. The example hints at the content but not at the behavior after sending.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the purpose, and every sentence adds value. There is no wasted words or repetition. The example is compact and illustrative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and only 50% schema description coverage, the description is adequate but not thorough. It explains the purpose and gives a usage example, but does not cover return values, error conditions, or behavior after sending. For a simple tool, it is minimally complete but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'to' has a description). The tool description does not add explicit meaning to the parameters beyond what the schema provides. The example demonstrates usage of 'body' but does not formally describe its format or constraints. The description neither compensates for the missing schema description nor adds significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'leave a message' and specifies the resource 'the other agent'. It elaborates with concrete scenarios (interface contract, hand-off, heads-up) and provides an example. This distinguishes it from siblings like 'notes_read' (reading) and 'board_post' (posting to a board).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: to communicate changes, hand-offs, or heads-ups to the other agent. It advises making messages self-contained and concrete. However, it does not explicitly mention when NOT to use it or point to alternatives (e.g., 'notes_read' for retrieval).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Announce what you are doing right now, so the other agent's coop_status shows it. Call when you start and finish a chunk of work.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | ||
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses that calling this tool updates another agent's coop_status, which is a side effect. However, it does not explain whether it is idempotent, if previous status is overwritten, or any other behavioral traits like auth requirements or error handling. The disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The description is front-loaded with the purpose and ends with usage guidance. Very concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, no output schema, no annotations, and several sibling tools, the description covers the basic purpose and usage timing. However, it lacks parameter descriptions, return value information, and any mention of error conditions or prerequisites. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema has no descriptions for its parameters. The description does not compensate: it mentions 'what you are doing' implicitly referring to the `status` field but gives no details about the `detail` parameter or the meaning of enum values. Parameter semantics are entirely missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool announces the current activity to update another agent's coop_status. It uses specific verb-resource ('announce what you are doing') and the title reinforces this. However, it does not explicitly differentiate from the sibling `coop_status` tool, which likely reads the status, but the distinction is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Call when you start and finish a chunk of work.' This tells the agent when to use the tool. It does not, however, state when NOT to use it or mention alternatives, but the context of cooperation implies it is for status broadcasting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Release path locks you hold. Pass all_mine=true to drop every lock you own -- do this when you finish a chunk of work so the other agent is not blocked.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | No | ||
| all_mine | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool releases the user's own locks and mentions the 'all_mine' parameter behavior. However, it does not describe side effects (e.g., whether releasing non-existent locks causes errors, if the operation is idempotent, or what happens with an empty paths array). Some behavioral context is present ('so the other agent is not blocked'), but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose. The second sentence is slightly long but still clear. There is no unnecessary information. It could be more concise by combining the guidance with the parameter explanation, but it is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and schema descriptions, the description is incomplete. It does not explain what the tool returns (e.g., success/failure, list of released locks), error handling, or the relationship with 'claim_paths'. The agent may not know how to verify the release or handle failures. The description is adequate for a simple use case but lacks depth for a robust interaction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It explains the 'all_mine' parameter ('Pass all_mine=true to drop every lock you own'), but it does not mention the 'paths' parameter at all. The agent has no guidance on how to use the 'paths' array, e.g., what format paths should be in or whether they are required. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Release path locks you hold.' It distinguishes from sibling tools like 'claim_paths' (acquire locks) and 'check_paths' (check status) by specifying the action of releasing. However, it does not explicitly mention what happens if no locks are held, which could be clarified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage guideline: 'do this when you finish a chunk of work so the other agent is not blocked.' This gives clear context for when to use the tool. It does not explicitly mention when not to use it or alternatives like 'check_paths' or 'coop_reset', but the guidance is sufficient for the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0activityag_cancelag_delegateag_followupag_task_statusag_task_waitboard_listboard_postboard_updatecheck_pathsclaim_pathscoop_resetcoop_statusnotes_readnotes_sendpresence_setrelease_pathsEvery tool has a clearly distinct purpose: coordination status/reset, delegation lifecycle, board operations, path locking, messaging, presence, and activity log. There is no overlap or ambiguity.
All tool names follow a consistent snake_case pattern with clear prefixes (coop_, ag_, board_, claim_, release_, check_, notes_, presence_) and verb_noun structure (e.g., board_post, ag_delegate). Even the single noun 'activity' is an acceptable exception.
17 tools is well-scoped for a multi-agent coordination server. Each tool serves a necessary function in the collaboration workflow without being excessive or sparse.
The tool surface covers the full lifecycle of multi-agent coordination: status, reset, delegation (create, check, wait, followup, cancel), shared board (post, update, list), path locking (claim, release, check), messaging, presence, and activity log. No obvious gaps.
Coding agents from Claude Code, Cursor and Codex claim jobs and lock files on one shared board.
Shared control plane for AI coding agents — tasks, memory, decisions, file locks. 12 tools.
Coordination hub for AI coding agents: message teammates, ask humans, audit every event.
The team layer for AI coding agents: shared contracts, collision alerts, E2EE sessions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/adeelali4/antigravity-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
