Search for a Gemini Notebook MCP server — the product called NotebookLM until Google renamed it in July 2026 — and you find at least five projects, four of them alive, plus a layer of directory pages ranking them without measuring anything.
So here are the measurements, taken the same afternoon, with the commands to retake them. This project is one of the five, and it is not the biggest: that is stated below rather than buried.
There is a Rust crate and a Ruby gem for Gemini Notebook (formerly NotebookLM), both built from this server's REST API. If your language is neither, you do not have to wait for someone to write one. The server publishes a specification, and a specification is a client generator's input.
Search RubyGems for a NotebookLM client and you get an empty array. Search GitHub and you get two repositories, one star between them, neither published as a gem. For the consumer product — the Gemini Notebook you log into with a personal Google account, not the Cloud Enterprise one — the Ruby shelf is bare.
That is not because Ruby is unsuited to the job. It is because the hard part of this problem is not HTTP.
The NotebookLM automation projects that work tend to be written in Python,
and ours is not — it is TypeScript. That turns out not to matter, because the
thing you integrate against is an HTTP endpoint on localhost, and Python
talks to those perfectly well.
There is no official SDK for the consumer product. What there is: a local
server you run, and ordinary requests calls into it.
Search crates.io for a NotebookLM client and you find one crate, nblm-core.
It targets NotebookLM Enterprise — the Google Cloud product, not the
Gemini Notebook you log into with a personal account — it has not been published since
November 2025, and it served 41 downloads in the last ninety days. For the
consumer product, the Rust shelf is empty.
That is not because Rust is unsuited to the job. It is because the hard part of this problem is not HTTP.
MCP gives an agent a server to talk to. UTCP — the Universal Tool Calling Protocol — gives it a description and gets out of the way. There is no protocol server, no wrapper process, no second hop: the client reads a manual once at startup, and from then on it calls your API directly, the way any other HTTP client would.
That difference is the whole protocol, and it decides what "supporting UTCP" means. It is not something you implement. It is something you publish.