What I set up
PubCrawl already had an HTTP mode. I added a container image that runs as a non-root user, shuts down cleanly and is built and smoke-tested in CI on every push. I deployed it to Cloud Run in London with authentication required, and with --functional-type=mcp-server, which is meant to add it to Agent Registry automatically.
The lock-down worked first time. Every request without a Google identity got a 403, on every path, before it reached the server. With an identity token, the health check answered as normal.
What didn’t go as expected
| The automatic registry entry was empty | Cloud Run did create an Agent Registry entry, but it held only a link to the Cloud Run service: no endpoint URL and no tools. An agent browsing the registry could see PubCrawl existed but not how to call it or what it does. The registry reads tools only from servers it can reach publicly, and a server behind sign-in isn’t. The more locked-down the server, the less the registry can learn about it on its own. |
| The tool spec needed input schemas | The fix is to register the endpoint manually with a tool spec. The docs list each tool’s name, description and annotations, so that’s what I sent. The registry rejected all 14 tools: inputSchema is required. In fairness, the docs also say the spec must follow the MCP tool schema, and that schema does require it, but the field list doesn’t mention it. |
| The full schemas didn’t fit | The registry caps a tool spec at 10 KB. With complete input schemas, PubCrawl’s came to 12.5 KB, so required schemas and the size cap were in direct conflict. |
How I fitted it in
Most of the weight was in the parameter descriptions: 2,839 characters of help text written for language models. Dropping those, along with each schema’s $schema line, kept everything an agent needs to call a tool correctly and brought the spec to 8.1 KB:
| Tool spec | Size | Accepted |
|---|---|---|
| Name, description and annotations only | 4.7 KB | No: schemas required |
| With complete input schemas | 12.5 KB | No: over 10 KB |
| Schemas kept: types, required fields, enums, defaults, ranges | 8.1 KB | Yes |
The full descriptions aren’t lost. Once an agent connects, it gets the complete schemas from the server itself; the registry copy is only for discovery. I didn’t write the spec by hand: PubCrawl generates it from its own tool definitions, and a test fails if the committed file drifts from the code or grows past 10 KB, so adding a tool later can’t quietly break the registration.
After that, the registry listed PubCrawl with its endpoint and all 14 tools. As a final check, Claude Code connected through Google’s sign-in and ran a PubMed search on ensifentrine in COPD, which came back with live results, the same as from the public deployment.
What I took from it
- Locked-down and discoverable pull in opposite directions. Requiring sign-in is what an enterprise wants, and it’s also what stops the registry learning anything by itself. Plan to register the endpoint and tools yourself.
- Generate the tool spec, don’t write it. A hand-written spec is a second copy of the tool list that will drift. Building it from the server and testing it in CI keeps the two in step.
- Run the deployment, don’t just document it. None of these three problems showed up in local testing, and the docs only hint at them. Neither did a fourth: both of PubCrawl’s transports had been reporting their version as 2.5.0 for months, from a number hard-coded in two places. That’s now read from the package itself, and it shipped in PubCrawl 2.8.0.
I ran the deployment with Claude as a working partner. The decisions and conclusions are mine. Everything here, including the commands as run, is in PubCrawl’s Cloud Run and Agent Registry walkthrough.