How we built an MCP server that can handle complexity, and the engineering decisions that make it safe and powerful.

Lorikeet Coach and Lorikeet MCP are available to use within our app, in Claude, Cursor, ChatGPT and more. The Model Context Protocol ('MCP') has become the standard way for AI agents to interact with external tools. We're now bringing Lorikeet to this ecosystem, letting CX and growth leaders build concierge experiences their customers can access through any MCP-compatible agent. However, as we built our MCP server, we quickly realised our use cases are significantly more complex than most.

The Complexity Problem

Take a look at typical MCP implementations. A project management SaaS product might have a handful of concepts: issues, statuses, projects. A digital workspace product covers pages, comments, and teams. This is relatively simple.

Lorikeet is entirely different. We have tickets, customers, workflows, a knowledge base, integrations, simulations, tools, guardrails, and more. Beyond that, we give AI agents the ability to test their own work by creating and running tool tests and managing simulations. The concept count is an order of magnitude higher than a typical SaaS product.

This creates an engineering challenge. Historically, throwing more tools at a language model was a bad idea. Performance degrades as the tool count increases as models get confused, pick the wrong tools, or hallucinate parameters.

Decision 1: Lean into Tool Search

Modern AI agents have built-in tool search. Claude Code, for example, doesn't load all tools upfront, it searches by keyword and loads what it needs. We designed around this.

Our tool naming and descriptions are deliberately semantic and follow a standard well-documented convention. When an agent searches for "tickets," it finds all ticket-related tools. In Lorikeet, a workflow is the set of instructions and tools that tells an AI agent how to handle a customer enquiry . When an agent searches for "workflow," it gets all workflow-related tools. This seems obvious, but it requires discipline. Every tool name and description is written with searchability in mind.

Decision 2: Semantic Error Messages

Error messages are an underrated steering mechanism.

A typical API returns 404 Not Found. Ours returns something like: "Workflow not found. You might want to call search_workflows with these parameters to find what you're looking for."

Every error message is written to help the model recover. Invalid ID? Here's how to look up the correct one. Missing permission? Here's which scope you need. The model doesn't fail, rather it learns how to succeed on the next attempt.

Decision 3: Encode Processes into Tool Descriptions

Lorikeet lets support teams define workflows that tell the AI agent how to handle specific scenarios. These range from structured workflows that follow exact steps to natural language workflows that give the agent flexibility to adapt. In Coach, our AI assistant, we can guide users through a workflow using a library of skills: first fetch the context, then read best practices, then make your edit. But the MCP predates skills. While the protocol lists resources and prompts, support is patchy and we want our MCP to work with as many AI agents as possible. So we encode processes directly into tool descriptions.

For example, the nudge AI agents trying to edit a workflow are prompted like this: Before calling this tool, you should first get the context of available tools and variables, then read our best practices."

We're essentially programming the agent's behavior through documentation. It sounds like a hack, but it works remarkably well. The model follows the suggested sequence, and the result is more reliable than if we'd left it to figure out the order itself.

Decision 4: Enable Self-Verification

A model works better when it can verify its own work.

This insight drove several design decisions. After an agent configures a workflow, we nudge it to create a test ticket, role play as a customer and verify the workflow behaves as expected. After it configures a tool or a guardrail, we encourage it to add tests and run them.

This isn't just about catching errors. It's about giving the model a feedback loop. When it can test its work and see the results, it can try again and course correct in response to external feedback. We even built regression testing into the flow. Change a tool later? The agent can re-run the existing tests to verify nothing broke.

Simulations are central to this. A scenario defines a customer interaction, mocks the tool responses the agent would normally get from real APIs, and asserts what should happen with the right response, the right tags, the right data extracted. Agents can run these against draft workflows, see what fails, fix the instructions, and re-run until assertions pass.

Security: Scopes, Audit Logs, and Safety Checks

Giving an AI agent write access to your customer support system is a big deal. We took security seriously.

OAuth scopes: Our MCP supports fine-grained scopes. Want read-only access? You can restrict the agent to viewing tickets and workflows without modification rights. The permission model maps directly to our existing user roles: a QA user connecting via MCP has the same permissions they'd have in the web app.

Audit logs: Every action taken through the MCP is logged. If an agent makes a mistake, the agent can look through the audit log and undo its decisions one step at a time. An audit log gives us the confidence to expose powerful capabilities to the MCP by making every tool call reversible.

And we don’t just log what happened, but also why it happened. That last part is important. We require agents to provide a short natural language reason explaining why its calling a tool. This creates an audit trail. When you're reviewing what happened, you don't just see "workflow edited", you see why the agent thought it should make that edit.

Safety checks on dangerous operations: Some operations need guardrails. Deleting a tool? We check if any workflows use it. If they do, the deletion fails with a clear message: remove the tool from those workflows first.

This prevents cascading failures. An over-eager agent can't accidentally break production workflows by deleting a tool they depend on.

The Result

Lorikeet's MCP is, frankly, more complex than most. But complexity doesn't have to mean fragility.

By designing for searchability, writing semantic error messages, encoding processes into tools descriptions, enabling self-verification, and building in real security controls, we've created an MCP that's both powerful and safe.

AI agents using our MCP can configure workflows, build tools, test their work, and iterate while staying within appropriate guardrails. That's the goal: not to limit what AI can do, but to make it safe for AI to do more.

Want to see how Lorikeet Coach and Lorikeet MCP lets you configure AI-powered customer support through conversation?
Book a demo