Zoho Agent Suite

The problem

An MCP server that lets an agent write to a production CRM is one bad tool call away from real damage — duplicate leads, a botched bulk update, a burned OAuth integration. Most MCP examples expose raw tool calls with no guard rails. This one had to actually be safe to run against a live Zoho org.

What I built

A FastMCP agent server exposing roughly 78 tools across five mounted domain routers — CRM, Books, Analytics, Desk, and cross-domain — plus a background Gmail→Zoho listener that routes inbound events straight into CRM. The router pattern means a domain can be mounted or disabled without touching any other domain’s tools.

Decisions worth noting

• Scope-gate decorator. Every tool call is restricted to a declared permission set, so an agent only ever sees the minimum tool surface for the job it’s doing — not the whole server.
• Single-flight OAuth refresh with retry/backoff. Zoho caps how often a refresh token can be issued. Without single-flight protection, a burst of concurrent calls each triggers its own refresh — a thundering herd that blows through the cap and bricks the integration. Tenacity retry/backoff plus a single-flight refresh keeps it to one refresh at a time.
• Human-in-the-loop preflight/plan/execute/rollback for bulk writes. No mutation lands without a human seeing the proposed plan first: preflight checks it, plan lays it out, execute runs it, rollback undoes it if it’s wrong.

My role

Sole architect and engineer, built at Alyne. Source is private — tied to live Zoho and Gmail orgs — so there’s no repo link here. The patterns are the story: this is the safety stack I’d point to if asked how I think about giving an agent write access to something that matters.