The support team's tier-one workflow was a folder of scripts: look up an account, check invoice state, resend a webhook, read the error log. Every new hire learned the folder. Every incident meant someone pasting script output into a ticket.
40-person B2B SaaS · 1 backend engineer, part-time · Forge MCP · 2 weeks from clone to production, agents answering tier-one lookups in week 3.
The problem
The team wanted an AI assistant that could answer "what's the state of account X" directly in the support tool — but handing an agent raw database access was a non-starter, and the hello-world MCP examples had no answer for auth, rate limiting, or "who asked for what, when".
The build
Forge's typed tool registry turned each script into a declared tool with an input schema, an auth requirement, and a per-client rate limit:
registry.register('lookup_account', {
input: z.object({ email: z.string().email() }),
auth: ['oauth'],
rateLimit: { perClient: 30, window: '1m' },
handler: async ({ email }) => accounts.summary(email),
});OAuth came from the starter's built-in flow, so support staff authenticated with their existing workspace accounts, and every tool call landed in the structured log with the caller's identity attached.
Results
The registry pattern is the whole product. We stopped debating how to expose things safely and just declared them. — Backend engineer
Where it went next
Month two added write-tools behind a second auth scope: resending webhooks and re-running failed jobs, still rate-limited, still logged. The support agent graduated from read-only lookups to actually fixing the easy half of tickets.
Golam Mostafa builds the ACP, UCP, and MCP products behind these results. Planning something similar? Talk it through first.