Repository navigation
Bug: [Antigravity] Editing tools (add_cell, run_cell) fail to dynamically register after successful connection #50
Description
Describe the bug:
After successfully running the open_colab_browser_connection tool and seeing the "I have successfully re-established the connection" message, the MCP client (Cursor/Claude) does not list the other notebook editing tools (like add_cell, run_cell, etc.). The AI continues to say it doesn't have the tools to write directly to the notebook.
Steps to reproduce:
Configure colab-mcp in the MCP settings.
Open a Google Colab notebook in the browser.
Call the open_colab_browser_connection tool.
Attempt to ask the AI to "create code in colab".
Expected behavior:
After connection, the server should expose the full suite of notebook editing tools so the AI can write and run code directly.
Actual behavior:
The AI only sees the connection tool and suggests manual copy-pasting because it cannot find the hidden tools even after a successful handshake.
Environment:
OS: Windows 11
MCP Client: Google Antigravity
Browser: Chrome
Activity
anthony-maio commentedon Mar 20, 2026
I got this. on_call_tool waits for WebSocket connection but never verifies that the browser-side tools are actually queryable. It also doesn't send tool_list_changed itself that only happens in on_message after the tool result is already returned. And the success response text is just "true", giving the AI zero information about what tools became available. This was not tested really. I can fix it.
fix: wait for remote tools to be queryable before reporting connectio…
[-]Bug: Editing tools (add_cell, run_cell) fail to dynamically register after successful connection[/-][+]Bug: [Antigravity] Editing tools (add_cell, run_cell) fail to dynamically register after successful connection[/+]anthony-maio commentedon Mar 27, 2026
My fix is correct for spec-compliant clients, and the maintainers closed it because it doesn't fix a bug that is arguably in Antigravity's client, not in the server. That's a pretty frustrating reason to reject a PR, But if they prefer to have a non-functional mCP server for days after release, that's their prerogative. Best of luck
fix: pre-register notebook tool stubs for clients that ignore tool_li…
fix: wait for remote tools to be queryable before reporting connectio…
fix: pre-register notebook tool stubs for clients that ignore tool_li…
Gyasu commentedon Mar 27, 2026
tried running the fork by @anthony-maio 's . It works with Claude code.
fix: pre-register notebook tool stubs for clients that ignore tool_li…
fix: register tools directly on mcp server instead of via proxy/middl…
anthony-maio commentedon Apr 1, 2026
I understand wanting to wait for a client-side fix in an ideal world, but the reality is that this server is currently completely non-functional for end users in production. Rejecting a working server-side patch while leaving the community with a broken release is a very frustrating user experience. I strongly recommend implementing a hotfix until the client side is updated.
I have to admit, I don't understand why this repo exists at all.
coezbek commentedon Apr 9, 2026
Can confirm that
codexalso doesn't work.How to use your fork @anthony-maio?
ats05 commentedon Sep 9, 2026
I ran into the same limitation and ended up implementing support for existing notebooks in an unofficial community fork:
https://github.com/ats05/colab-mcp
"open_colab_browser_connection" now accepts an existing Colab HTTPS URL:
open_colab_browser_connection(
notebook_url="https://colab.research.google.com/drive/"
)
It also supports "open_new_tab=false" when you want to connect the MCP server to an already-open Colab tab.
Ideally this capability would be available upstream, but I’m sharing the fork here in case it helps anyone currently blocked by this issue.