Friday night, I opened the IDE and found red squiggles stacked down my MCP config file. One per registered server, all carrying the same sentence: Additional properties are not allowed ('$typeName' was unexpected).
My hands stopped. I assumed the weekend batch I had lined up was about to fall over.
On a hunch I gave the agent a small errand, and the tools from that very server came back exactly as they always had. The red lived in the editor's display. The execution path had lost nothing at all.
Check before you fix. I had the order backwards, and I only noticed after burning half an hour.
The red squiggle is answering a different question
Those squiggles come from validating your config file against a JSON schema that ships inside the editor. The thing that actually starts an MCP server and holds the connection open takes a separate path, and that path never consults the schema.
When a schema is written with additionalProperties: false, meaning no keys beyond the declared ones are allowed, a single unrecognized key turns the whole server definition red. Whether the values inside are correct never enters into it.
The editor is telling you whether your file matches a declared shape. It is not telling you whether anything is running. Mixing up those two questions is what cost me thirty minutes.
The status rings in /mcp answer the running question
Per the official docs, typing /mcp in the prompt panel and pressing Enter opens the MCP Manager overlay. It shows live status rings for active, disconnected, and loading servers, along with real-time connection logs. That overlay is about connections, not about how the file looks.
The sequence I follow now is only four steps.
- Open
/mcp. - Find the server whose config was flagged and look at its status ring.
- If it's active, park the red as a display problem for now.
- If it's disconnected, open the connection log right there.
Once I've read the log and then go back to the config file, the number of lines worth touching is usually one or two. Skip the log and start editing the file, and you end up changing things that were working fine.
The ring is also worth a second glance rather than a glance. Loading is not the same as active, and on a cold start a stdio server that spawns a process can sit in loading long enough that you conclude it failed. I give it one manual reload from the overlay before I accept a verdict, because a server that comes back on reload is telling me something about timing, not about my configuration.
If tools were missing from the very start of a session, deciding whether to continue at all is a separate call, and I wrote that one up in When a session starts with MCP tools missing, where do you stop?.
Two applications were reading the same single file
The official MCP docs split configuration into two places. Global setups live in ~/.gemini/config/mcp_config.json, and workspace-local setups live under your active project at .agents/mcp_config.json.
The catch shows up when Antigravity 2.0 and the Antigravity IDE are both installed on one machine, because they share that global file.
In the reported case, 2.0 writes a $typeName key, a Protobuf type identifier, and the schema bundled with the IDE rejects it as unknown. What actually lands on disk looks roughly like this.
{
"mcpServers": {
"github": {
"$typeName": "…",
"serverUrl": "https://api.githubcopilot.com/mcp/",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Delete the $typeName line and the red goes away for the moment. Then 2.0 rewrites the file, the key returns, and so does the red. Clearing it by hand buys you one quiet evening per deletion.
So I stopped deleting. My rule now is that before editing a config file, I work out who is writing it. Lines I wrote, I fix. Lines another application generates, I leave red and trust the /mcp status instead.
You can follow the report in antigravity-cli issue #986. The proposed fix teaches the schema to permit $typeName explicitly, which means the display stays red until that lands.
The quiet failures are the ones that worry me
The mirror image exists too: the editor says nothing, and the server isn't there. That one takes far longer to notice.
The easiest version to walk into is the key name for remote connections. The docs are explicit that SSE, Streamable HTTP, and websocket-based servers must declare serverUrl, and that legacy fields such as url or httpUrl are not supported.
{
"mcpServers": {
"my-remote-server": {
"url": "https://api.example.com/mcp/"
}
}
}{
"mcpServers": {
"my-remote-server": {
"serverUrl": "https://api.example.com/mcp/",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}Copy a config snippet from somewhere else and that single word can survive the move. Nothing about the JSON is malformed, so the editor stays quiet, and the agent simply proceeds as though the server were never declared.
Two more of the same kind: a disabled: true you set once and forgot, and a disabledTools entry still withholding a tool you now need. Both are documented, supported keys, so validation passes cleanly. Passing cleanly is exactly what keeps them off your list of suspects.
Permissions sit in the same blind spot. Unconfigured MCP tools run in Ask mode by default, so a rule you wrote months ago with mcp(server/*) can quietly widen or narrow what the agent reaches for without a single character changing in mcp_config.json. When a tool is present in the list and still never gets used, I look at the policy before I look at the config.
If you'd rather catch file-level problems before startup instead of after, I put a small pre-flight check in Find the one broken MCP entry before Antigravity starts, with 40 lines of Node.
The order I follow when something turns red
I sort it into four symptoms. Here they are side by side.
| What you're seeing | Where to look first | What that tells you | Next move |
|---|---|---|---|
| Config flagged, tools still returning | Status ring in /mcp |
Active means the problem is in the display | Leave it alone; identify what writes the file |
| Config flagged, tools not returning | Connection log in /mcp |
You get the line that actually failed to start | Change only the line the log names |
| No flag, server missing from the list | Key names (serverUrl) and disabled |
A substitution that passes schema validation | Walk the official config structure property by property |
| No flag, only some tools missing | disabledTools and your permission rules |
Whether the absence was deliberate | If you can't recall why, put it back |
Laid out like that, none of the rows start with "open the config file." I keep this order on a sticky note at the edge of my monitor, because the moment a squiggle appears my hand reaches for the file on its own.
Running a set of sites alongside my own apps, I hit this pair of mistakes with almost every tool I use: the thing that looks broken and works, and the thing that looks fine and doesn't. The display is a hint. Evidence that something ran is the real answer. I may be missing a better method, but that distinction has held up for me so far.
Next time a squiggle shows up, close the file and type /mcp before anything else. That single step gave me a weekend back.
I appreciate you sitting through the small print on this one.