docs(celina): add the read-only Telegram bot

[andrewkimjoseph]

The hole, and the fix

The Celina page lists the SDK, MCP server, hosted MCP, and REST API, and the Build with AI overview repeats that list. Celina now also has a live read-only Telegram bot, @thecelinabot, which calls the public Celina API on Celo mainnet (balances, quotes, governance) and does not hold a key or sign.

This adds a Telegram card and a Resources row on build-on-celo/build-with-ai/mcp/celina.mdx (t.me, https://www.usecelina.xyz/bot, and the celina-bot repo), and extends the existing Celina sentence on build-on-celo/build-with-ai/overview.mdx with the same surface. The page description matches.

The command catalog stays on usecelina.xyz/bot and the bot repo. Those two already disagree on --human vs --json, so this page does not restate commands.

What this does NOT do / residual risk

• Does not add a new page or change docs.json. The Celina page is already in nav.
• Does not document slash commands, flags, or the worker host bot.usecelina.xyz.
• Does not claim the bot can prepare or sign transactions. Signing stays on the local MCP server and the SDK.
• Bot behavior can drift from this sentence if the bot repo changes what the public read catalog covers.

Judgement calls

• Fifth card in the existing 2-column CardGroup, icon telegram, rather than a new section or a new nav page. One-line reversal if a maintainer wants it dropped.
• No GitHub issue. Same as docs(build-with-ai): add Celina SDK, MCP, hosted MCP, and API pages #2287.

Issues

Closes #
Refs #

Stacking / conflicts

Branched off current celo-org/docs main, independent of other open PRs. Touches build-on-celo/build-with-ai/overview.mdx and build-on-celo/build-with-ai/mcp/celina.mdx.

Verification evidence

$ mint broken-links
success no broken links found

Ran with mint 4.2.823 on this branch head after the edits. No code examples.

Remaining ops steps

• none

Checklist

• Title is the commit message I want on main
• mint broken-links passes on this branch head (see Verification evidence)
• No secrets in the diff
• Judgement calls flagged above
• N/A: test/mutation-count/lockfile/wallet-tree/money-path checklist items — this is a docs-only content PR, no code changes
• Questions for the maintainer: none

Made with Cursor

[GigaHierz]

Approving. The card makes one claim that actually matters — "No keys and no signing" — so I verified it at source rather than from the README, because that sentence is the reason a reader will feel safe pointing an LLM at it.

Four independent lines of evidence, all consistent:

• No signing library is present at runtime. package.json has exactly one dependency, hono. No viem, ethers, or web3. celina-sdk is a devDependency used only by the alias-sync script.
• No key material can be configured. The whole env surface is TELEGRAM_BOT_TOKEN, optional TELEGRAM_WEBHOOK_SECRET, optional CELINA_API_BASE_URL, and a KV namespace. There is no private-key or mnemonic variable to set even by accident.
• The only network path is HTTP to the public API — three fetch calls to /v1/tools and /v1/<tool>. Nothing builds, signs, or broadcasts a transaction.
• The upstream catalog cannot offer a write path. Since /call <tool> forwards arbitrary tool names, I checked the backend: api.usecelina.xyz/v1/tools returns 50 tools, all reads (get_*, verify_*, lookup_*, check_*, resolve_*, and call_contract_function, which is an eth_call). No transfer, swap, vote, stake, approve, prepare, or execute tool exists.

One note for anyone auditing this later: /setaddress stores a public address in KV, and grep hits for "key" in that repo are KV key names (wizardKey, addressKey) plus the Telegram KEYBOARD constant — not cryptographic keys. That is the one thing that looks alarming at a glance and isn't.

All three links return 200 and the bot profile is live, with a bio matching the card.

Also agreed with the call not to restate the command catalog here, given the two upstream surfaces currently disagree on --human. That keeps the inconsistency out of our docs entirely. Worth reconciling those two on your side when you get a chance, but it doesn't touch this diff.

[GigaHierz]

Heads-up: this is approved and merge-ready — it is held by an unrelated CI outage, not by anything in your diff.

npx mintlify resolves the latest dist-tag at run time, and latest is currently 4.2.931, which carries a transitive dependency on @mintlify/auth-edge@0.0.51 — a package that is not on the npm registry:

$ curl -s -o /dev/null -w '%{http_code}' 'https://registry.npmjs.org/@mintlify%2Fauth-edge'
404

So the required check dies during install, before it reads a single file. This is repo-wide right now, not specific to you.

#2335 pins the CLI version and fixes it. I will merge this the moment that lands — nothing needed from you.