PostMQ in Antigravity.
Antigravity is the agentic coding client whose CLI is agy and whose state lives under ~/.gemini, and it connects to PostMQ the way every other MCP client does — one server, one scoped credential, the same catalogue of tools. The session protocol installs into its own surfaces too: the two skills under .agents/skills and the two scripts under .agents/tools, from the same files the other three installs write. One thing makes this install different from the others, and it is worth knowing before you set it up: nothing here is wired to an event.
one session in Antigravity
~/.gemini/config/mcp_config.json → mcpServers.postmq
.agents/skills · .agents/tools · no wiring
start_build_session → resumed · project · branch
end-session runs the reporter · one row
An MCP server Antigravity calls — the same one every client sees
PostMQ is a standard MCP server. Antigravity connects to it over Streamable HTTP with a scoped, once-disclosed credential, and sees the same 87 tools every other client sees — the same names, the same arguments, the same catalogue. Nothing on this page is an Antigravity-specific protocol, and PostMQ does not run inside Antigravity.
One difference is worth stating because it looks alarming and is not: Antigravity does not give each MCP
tool its own name. It dispatches them through a single built-in tool, call_mcp_tool, taking
a server name and a tool name. It resolves the mcp__postmq__send spelling onto that
correctly — which is why the kit's skills are the same file here as on every other client, rather than a
rewritten copy that could drift. If you see mcp(postmq/send) in its settings or in a
permission error, that is the permission-rule spelling, not the tool's name.
Five steps
Credential, the MCP server entry, the kit, the reporter's own credential, one restart. There is no hook to wire and no flag to turn on — and the step that catches people is the fourth, because nothing fails loudly when it is missed.
-
Create a workspace, then issue Antigravity a credential
Sign up, then create an AI account for your Antigravity — a credential belongs to one, and POST /v1/credentials takes its ai_account_id. Give it the write_session_state scope — both kit components require it, and the dashboard starts with nothing selected. The six-call session further down also sends and receives, so add send, get_pending and ack if you want to run it; the session-state protocol alone does not need them. Issue it in the mcp_config form: the response, and the dashboard reveal, carry the URL, the headers and the once-disclosed plaintext. That block is a flat descriptor rather than any one client file format, so take the URL and the credential from it into the entry in the next step. The plaintext is shown once, so copy it before you close it.
POST /v1/credentials · form: mcp_config -
Register the MCP server in Antigravity
Antigravity reads MCP servers from ~/.gemini/config/mcp_config.json, in the same top-level mcpServers shape Claude Code uses — the server name, a url, and a headers object carrying the bearer. Paste the entry below with your own credential in place of the placeholder. It carries no type field, deliberately: the live working config this was read from carries none, and adding one would be a claim about Antigravity nobody has checked.
mcpServers.postmq -
Install the session kit for Antigravity
Ask the agent you just connected. PostMQ returns an instructions string on connection telling it to read the kit manifest and offer the components, so “set up the session protocol for me” is enough — and it asks before writing anything. What lands: the skills at .agents/skills/start-session/SKILL.md and .agents/skills/end-session/SKILL.md, and the two scripts under .agents/tools/. Note what does NOT land: no hooks directory, and no settings file. There is nothing to wire here. To do it yourself instead, every file is served at postmq.com/kit/ — copy each to the .agents paths the manifest names. pmq kit install --all --client antigravity writes the same tree in one command, but the CLI is not a download today: it ships in no package manager and has no release workflow, so it is reachable only by building it from source.
ask your agent: “set up the session protocol for me” -
Give the reporter the credential too
The MCP entry you just pasted authenticates Antigravity. It does NOT authenticate the usage reporter, which is an ordinary script the end-session skill runs — it reads its credential from POSTMQ_CREDENTIAL in the environment. Put it somewhere the client will inherit — your shell profile, or whatever launches Antigravity — not just the terminal you happen to be in: a one-off export reaches only a client started from that shell, and an IDE launched from the desktop will not see it. Without it the report is built, found to have nowhere to send, and dropped: a hook must never block a session, so it logs one line to stderr and exits 0. On the other three clients this is easy to miss and still works out, because a hook inherits the shell you launched from; here it is the difference between usage being recorded and silently not.
export POSTMQ_CREDENTIAL=pmq_… -
Restart, then run the skills yourself
Antigravity reads skills at start-up, so a client that was running when you installed will not see them. Restart it once, then run /start-session — it should name the active build session, or start one, and print the drift block. That block appears because the skill runs the script; nothing prints it for you. The same is true at the other end: /end-session is what records the session’s token usage, and it is worth checking get_usage once to confirm a row actually landed.
restart once, then /start-session
{
"mcpServers": {
"postmq": {
"url": "https://mcp.postmq.com/",
"headers": { "Authorization": "Bearer pmq_…redacted…" }
}
}
} There is no step here that turns a hook on, and that absence is the thing to carry into the rest of the page. On Claude Code, Codex and ZCode the kit merges a block into a settings file and an event does the work. On Antigravity it merges nothing, so a reader who expects the familiar shape will sit waiting for drift signals and usage rows that were never going to arrive. The next section says why.
How we run it: one set of files, four clients, and one that wires nothing
The session-state kit installs into all four clients we run,
from one set of source files. On Antigravity that is the two skills as SKILL.md directories
under .agents/skills — the same paths the Codex install writes — and the drift-signal
script and the usage reporter under .agents/tools. The shared pieces really are one file
each rather than four copies that drift: one source installed per client, not four that have to be kept
in step. Two details keep that honest rather than tidy. The trees as a whole are not identical and we do
not describe them that way — each client's wiring differs, and this one has none. And the skill paths
are not one-per-client either: Codex and Antigravity read them from the same directory. What is
per-client is the wiring, and here there is none of it.
They land under tools/ rather than hooks/ on purpose. They are not hooks on
this client, and naming a directory after something that never runs is how an install comes to look
finished while doing nothing. The skills run them instead: start-session runs the
drift-signal script, end-session runs the usage reporter.
All 87 in the catalogue — the protocol ones first
Five of them carry the session protocol's spine — the calls a session opens and closes with. The two skills reach for more as a session needs them (filing a backlog item, correcting an entry, asking which rules apply, updating the lead for the next session), so this is the shape rather than the whole list:
Every one is in the catalogue, with the same
arguments whichever client calls it — reached here through call_mcp_tool rather than by
name, which changes nothing about the arguments or the result.
The reviewer's session, in six calls
The complement of the ZCode page's builder's half: this agent picks work up, reviews it, and hands back an assessment.
The last call is the one that matters most on this client. end_build_session closes the
session, and the same skill run records its token usage — because nothing else will.
8 things that go wrong, and why
Each row names the mechanism. Most of them are the same fact wearing a different hat: nothing here is wired to an event, so nothing happens unless a skill makes it happen.
| Symptom | Why |
|---|---|
| You installed the kit and no usage is ever recorded. | That is the expected behaviour on Antigravity, not a fault. No hook fires here, so nothing reports on its own — the end-session skill runs the reporter. A session you never formally end records no usage at all. On the other three clients an event covers that case; on this one the skill is the only route. |
| You wired a hook yourself and it never runs. | We could not get one to fire either, across seven ways of declaring it. The machinery is in the binary and the global hooks file at ~/.gemini/config/mcp_config.json’s sibling ~/.gemini/config/hooks.json is genuinely read — its loader reports how many it loaded — but a project-scoped .agents/hooks.json was never loaded at all, and nothing we bound ran. We drove the CLI in print mode; we did not test the IDE, so this is what we measured rather than a statement about the product. |
| The reporter says it found no conversation. | It refuses rather than guessing which conversation you are in. It matches on the workspace the conversation recorded and on file times, and it declines when the newest thing that could be your session cannot be identified, when two were written in the same moment, or when nothing has been touched recently. Pass the database path yourself — it prints the one it read as `transcript` in a dry run, and that is the path to hand back on the send. |
| The drift block never appears at the start of a session. | Nothing prints it for you. On Claude Code, Codex and ZCode a SessionStart hook does; here the start-session skill runs .agents/tools/postmq-session-start.sh itself. If the skill did not run it, there is no block — and if the file is missing, the kit’s session-state component is not installed for this client. |
| Cache-write tokens are always zero. | Nothing in Antigravity’s conversation store records a cache write, so the reporter reports zero rather than inventing one. That is absence, not coarseness — unlike Codex and ZCode, where the figure exists but is not split by lifetime. |
| sidechain_turns is always 0. | Antigravity writes sub-agent work into the same trajectory as the parent rather than a separate transcript, so there is no second file to attribute. An honest zero rather than a guess. |
| You see mcp(postmq/send) in a permission error and wonder if that is the tool name. | It is not. That is the permission-rule spelling used by settings.json permissions.allow and permissions.deny. Antigravity dispatches MCP tools through one built-in tool, call_mcp_tool, taking a server name and a tool name — and it resolves the mcp__postmq__send spelling onto that correctly, which is why the kit’s skills are the same file here as everywhere else. |
| Skills are missing after an install. | Antigravity reads them at start-up, so a client that was running when you installed will not see them. Restart it once. |
Last verified 2026-09-03 at c36f170 — against Antigravity 2.8.0 and the kit as shipped, including the seven hook-binding spellings that did not fire.
Give your Antigravity a record that survives the window.
One MCP entry, one kit install, and the session protocol runs in the client you already use.