Antigravity × MCP in Practice — Spotting Dead Servers and Measuring What Tool Definitions Actually Cost

Which official reference servers are still maintained

Running the same check across the entire @modelcontextprotocol scope gives the following. These are registry values as of 2026-08-21.

There is one conclusion to draw. "It's official, so it's safe" has stopped working as a selection criterion. Reference implementations remain as demonstrations of the specification, while integrations meant for production have moved to the vendors themselves — Notion at @notionhq/notion-mcp-server (2.5.1, 2026-07-25), browser automation at @playwright/mcp (0.0.79, 2026-08-06).

For GitHub, GitLab, Slack, and PostgreSQL I will state only the verifiable fact: npm distribution has stopped. Check the vendor's own documentation for where those integrations live now. If I guessed here, this article would rot the same way next year — which is exactly why the verdict belongs in a script rather than in prose.

Measuring what tool definitions cost you

The criterion that actually matters is neither star count nor release cadence. It is how much context disappears the moment you connect a server. An MCP client fetches tools/list on connect and hands the model every tool name, description, and input schema. Those seats are taken before you type anything.

So I measured. Connecting to four official reference servers, serializing the tools/list response, and tokenizing with cl100k_base:

Four servers, 9,426 tokens. All of it loaded before a single instruction.

The sequential-thinking row is the one that changed how I think about this. A single tool costing 1,091 tokens, because its description runs 2,781 characters. Meanwhile everything fits 13 tools into 2,060 tokens — 158 each. Tool count is not a proxy for cost. Description and schema verbosity is the cost.

You can reproduce the measurement with this. Because it observes from the client side, the number reflects what actually reaches the model rather than what the docs describe.

// probe.mjs — measure the token footprint of a server's tools/list
import { Client } from "@modelcontextprotocol/client";
import { StdioClientTransport } from "@modelcontextprotocol/client/stdio";
import { writeFileSync } from "node:fs";
 
const targets = [
  ["filesystem", ["node", "node_modules/@modelcontextprotocol/server-filesystem/dist/index.js", "/tmp/sandbox"]],
  ["memory", ["node", "node_modules/@modelcontextprotocol/server-memory/dist/index.js"]],
];
 
const out = {};
for (const [name, argv] of targets) {
  const transport = new StdioClientTransport({ command: argv[0], args: argv.slice(1) });
  const client = new Client({ name: "probe", version: "1.0.0" }, { capabilities: {} });
  await client.connect(transport);
 
  const { tools } = await client.listTools();
  const json = JSON.stringify(tools);
  out[name] = tools;
 
  console.log(
    `${name.padEnd(22)} tools=${String(tools.length).padStart(3)} ` +
    `bytes=${String(Buffer.byteLength(json, "utf8")).padStart(6)}`
  );
  await client.close();
}
 
// Leave tokenization to a separate process (tiktoken or similar)
writeFileSync("tools.json", JSON.stringify(out, null, 1));

Push the resulting tools.json through any tokenizer and you get the same columns. I used cl100k_base, but encodings differ by model, so the ratios between servers are more actionable than the absolute values.

Where I landed in practice: three servers connected at all times, no more. Anything beyond that goes into a per-project config and gets enabled only when needed. Dropping the habit of connecting things "just in case" changed the quality of responses in a way I did not expect — my read is that a smaller menu makes the choice easier.

npx, or calling the local dist directly

One more place where config style shows up in measurements: whether command says npx or node.

Three runs each against the same server-filesystem, timing connect through tools/list completion, with npx's cache already warm:

About 2.5×, or 369ms in absolute terms. For one server that is noise. But it applies per server — five connected servers means roughly 1.8 seconds spent on package resolution at every startup, and that assumes a warm cache. A cold one adds the download on top.

npx -y has a second property worth naming. Unless you pin the version, resolution can change between launches. That is usually the entry point for "it worked yesterday and doesn't this morning." The closer you get to production, the more it pays to install servers as explicit dependencies and invoke them with node.

Three primitives, and the one you will actually use

MCP defines Tools, Resources, and Prompts. The spec treats them as peers; building with them does not.

• Tools — functions the model calls. You can build almost anything with these alone
• Resources — data the model reads, referenced by URI and loaded into context without a tool round-trip
• Prompts — reusable templates that depend on client-side UI support, so they are fine to defer in your own servers

Start with Tools only. Resources start earning their keep when the same data gets referenced repeatedly — loading it once beats calling a tool each time.

Rewriting a custom server on SDK 2.x

The SDK has moved too. @modelcontextprotocol/sdk sits at 1.30.0 (2026-07-27), and on the same date @modelcontextprotocol/server, /client, /node, and /core shipped as 2.0.0, splitting the package apart. If you are only writing a server, @modelcontextprotocol/server is all you need.

The older pattern — instantiating Server, registering ListToolsRequestSchema and CallToolRequestSchema handlers, then dispatching on tool name with a switch — is now McpServer and registerTool. Hand-written JSON Schema is gone as well. What follows is code I ran and verified.

// inventory-server.mjs
import { McpServer } from "@modelcontextprotocol/server";
import { serveStdio } from "@modelcontextprotocol/server/stdio";
import { z } from "zod";
 
const DB = { "SKU-1001": { tokyo: 12, osaka: 0 }, "SKU-1002": { tokyo: 0, osaka: 5 } };
 
serveStdio(() => {
  const server = new McpServer({ name: "inventory", version: "1.0.0" });
 
  server.registerTool("get_inventory", {
    title: "Inventory lookup",
    description: "Returns stock levels per warehouse for a product ID. Omit warehouseId for the total across all warehouses.",
    inputSchema: z.object({
      productId: z.string().regex(/^SKU-\d{4}$/),
      warehouseId: z.enum(["tokyo", "osaka"]).optional(),
    }),
    outputSchema: z.object({
      productId: z.string(),
      total: z.number(),
      byWarehouse: z.record(z.string(), z.number()),
    }),
    annotations: { readOnlyHint: true, idempotentHint: true, openWorldHint: false },
  }, async ({ productId, warehouseId }) => {
    const row = DB[productId];
    if (!row) {
      // Give the model something it can act on
      return {
        isError: true,
        content: [{
          type: "text",
          text: `Product ID ${productId} not found. Valid examples: ${Object.keys(DB).join(", ")}`,
        }],
      };
    }
    const byWarehouse = warehouseId ? { [warehouseId]: row[warehouseId] ?? 0 } : row;
    const output = {
      productId,
      total: Object.values(byWarehouse).reduce((a, b) => a + b, 0),
      byWarehouse,
    };
    return { content: [{ type: "text", text: JSON.stringify(output) }], structuredContent: output };
  });
 
  return server;
});

Three things changed relative to the older style.

inputSchema now takes a zod schema directly, and the SDK generates the JSON Schema. That removes the failure mode where a hand-written schema and the handler's type annotations drift apart because you updated only one.

outputSchema paired with structuredContent puts types on the return value too. When tools returned text alone, there was always room for the model to mis-parse the JSON.

The readOnlyHint and idempotentHint annotations feed the client's decision about whether to show a confirmation dialog. Skip them on a read-only tool and every harmless lookup gets an extra prompt. Just as importantly: do not put them on anything that writes.

What the model reads when your handler throws

Error handling was the part I could not settle by reading. Does a throw surface as a protocol error that fails the call, or as a tool-level error? Here is what I observed.

Three findings that matter in practice.

First, throw does not propagate — the SDK catches it and converts it to isError: true. The call returns successfully. So the difference between throw and an explicit isError is not whether things break. It is purely the quality of the string the model gets to read. With throw new Error("boom"), that string is four characters, and there is no path to recovery in it.

Second, schema violations are rejected before the handler runs. productId: "nope" is stopped by the regex, and the error message includes the pattern it failed. The model can read that and correct itself. Declaring a narrow schema beats accepting z.string() and validating inside the handler — you write less validation code and get a more recoverable failure.

Third, error messages should be written for the model, not for a human reader. Do not stop at "product not found"; include examples of valid values. The text you log and the text you return are serving different audiences. Since realizing that, the only question I ask when writing an isError message is whether a model reading it could choose its next move.

Where permissions and secrets belong

Least privilege is correct as a principle, but the decision that actually protects you is choosing not to grant something.

A GitHub-style token rarely needs more than repo; admin:org is unnecessary and delete_repo has no justification. Slack-style integrations cover most use cases with chat:write and channels:read. The hesitation usually comes from anticipating a future need. Adding the scope when that need arrives has a strictly lower expected cost.

Keep secrets out of the config file and pass them through the environment.

# .env.antigravity (add it to .gitignore)
GITHUB_TOKEN=YOUR_GITHUB_TOKEN
SLACK_BOT_TOKEN=YOUR_SLACK_BOT_TOKEN
NOTION_API_KEY=YOUR_NOTION_KEY

Before adding any third-party server, inspect it with @modelcontextprotocol/inspector (2.3.0, 2026-08-19). Launch it via npx @modelcontextprotocol/inspector node dist/index.js, run the tools by hand, and watch for unexpected network calls or excessive scope requests. Looking at a server in isolation is safer than wiring it into your config and calling it from Antigravity first.

A note from an indie developer

When I started with MCP, I connected everything. Decide later whether you need it; more options can't hurt — that was the reasoning.

The 9,426-token figure above is what changed my mind. That much context is spoken for before the conversation begins, and most of it describes tools with nothing to do with the day's task. What I had filed under "harmless if unused" was very clearly taking up room.

Working solo, this kind of invisible cost accumulates without anyone flagging it. On a team someone might notice; alone, it resolves into a vague sense that things feel less sharp lately. So my policy now is to build the measurement before I need it. Neither probe.mjs nor mcp-audit.mjs is clever code. But unclever code running on a schedule has helped more than clever code I meant to write.

Checking the throw behavior gave me the same feeling. I had read the documentation and believed I understood it; throwing an actual error said otherwise. Without knowing it converts to isError, I would have kept writing throw new Error() and never noticed the model was receiving four characters.

Verifying something by hand takes about as long as reading one article about it. I still drift toward the reading, and that is something I am working on.

If you want to act on one thing

Three steps are enough.

1. Run mcp-audit.mjs against your current settings.json. It takes about a minute. If it returns exit=2, that config has been carrying dead servers
2. Feed the survivors to probe.mjs and total the tokens for everything you keep connected. Deciding what to drop is much easier with the number in front of you than by feel
3. If you maintain your own server, move it to registerTool and replace bare throw calls with structured isError returns. Half a day covers it

If you want to go deeper on designing your own servers, running a custom MCP server in production picks up where this leaves off.

Measuring before deciding turns out to be the thing that stops the ecosystem's churn from setting your agenda. Thank you for reading.