I Built an MCP Server With 132 Tools So Claude Can Manage Cognigy.AI Agents for Me

I’ve spent some quite of time building conversational AI agents on Cognigy.AI — enterprise voice bots, multilingual flows, NLU training, the works while working at Deloitte. It’s a powerful platform. It’s also a lot of clicking. Create flow, open node editor, configure node, train intents, create snapshot, promote to next environment… and now we live in a world where my coding assistant can write entire applications, but couldn’t touch any of that.

So I fixed it. cognigy-ai-mcp-management-server is a local MCP (Model Context Protocol) server that gives AI assistants like Claude, Claude Code, and Cursor programmatic access to the Cognigy.AI Management API. 132 tools, TypeScript, MIT licensed, on npm.

Instead of clicking through the UI, you can now tell your assistant things like:

• “Create a new intent for order cancellation with these example sentences, then retrain the NLU”
• “Run the regression test playbook and summarize what broke”
• “Diff the current snapshot against production and tell me what changed”
• “Find every flow that uses this deprecated connection”

What’s in the box

The 132 tools span essentially the whole management surface: flows and nodes (full CRUD plus search and AI output generation), intents and NLU training, playbooks and regression testing, snapshots and packages (create, diff, promote across environments), Knowledge AI / RAG stores (21 tools just for that), LLM provider configuration, connections, extensions, contact profiles with GDPR export, analytics, and audit logs. The full list lives in TOOLS.md.

Design decisions I’d defend in a code review

Building an MCP server that can mutate production conversational AI agents forces you to think about safety differently than a read-only integration. A few choices I made:

1. dryRun: true by default on every mutating tool. An LLM with write access to your production agents is a chainsaw. Every tool that creates, updates, or deletes anything defaults to a dry run — the assistant sees exactly what would happen and has to explicitly flip the flag to execute. The destructive path requires intent, not just a hallucinated tool call.

2. Secrets never reach the model. API keys live only in environment variables and memory; connection secrets coming back from the Cognigy API are automatically redacted before the LLM sees them. Your model context should never contain credentials — that’s non-negotiable.

3. Async-aware tooling. NLU training and snapshot operations are long-running tasks on Cognigy’s side. The tools poll task status until completion instead of returning a job ID and leaving the LLM to guess, which keeps multi-step agent workflows from silently desyncing.

4. Zod validation on every input. LLMs produce mostly correct tool arguments. “Mostly” is doing heavy lifting in that sentence. Every tool validates its inputs with Zod schemas before anything hits the API.

5. Peer dependency instead of bundling. Cognigy’s official REST client is published under a proprietary license, so this server declares it as a peer dependency rather than bundling it. You install it yourself and accept Cognigy’s terms directly; my MIT license covers only my code. Licensing hygiene is boring until it isn’t.

Mock-first development

You don’t need a Cognigy account to hack on this. The repo ships with a Prism mock server generated from the OpenAPI spec:

# Terminal 1
npm run mock

# Terminal 2
npm test   # 49 tests against the mock

Enter fullscreen mode Exit fullscreen mode

TypeScript types are also generated from the OpenAPI spec (npm run gen:types), so when Cognigy updates their API, regenerating types surfaces breakage at compile time instead of at runtime in someone’s production tenant.

Getting started

npm install @cognigy/rest-api-client   # official Cognigy SDK, their license
npm install -g cognigy-ai-mcp-management-server

Enter fullscreen mode Exit fullscreen mode

Then point your MCP client at it — for Claude Code, drop this in .mcp.json:

{
  "mcpServers": {
    "cognigy": {
      "command": "npx",
      "args": ["cognigy-ai-mcp-management-server"],
      "env": {
        "COGNIGY_BASE_URL": "https://api-trial.cognigy.ai",
        "COGNIGY_API_KEY": "your-api-key-here"
      }
    }
  }
}

Enter fullscreen mode Exit fullscreen mode

Works with a free Cognigy trial account, SaaS, or on-prem. Configs for Claude Desktop and Cursor are in the README.

The honest footnote

Mid-project, I discovered that NiCE (Cognigy’s parent company) had shipped an official MCP server. Did I consider abandoning mine? For about an hour. Then I kept going, because (a) I was learning an enormous amount about the Management API surface by mapping all of it, and (b) an independent, MIT-licensed, mock-testable implementation with dryRun-by-default semantics is a different artifact than an official one. If the official server fits your needs better — use it! This one exists, it’s open, and the code shows exactly how to wrap a large enterprise API into LLM-safe tooling. That alone made it worth shipping.

(Standard disclaimer: this is an independent project, not affiliated with or endorsed by Cognigy or NiCE. You need your own Cognigy account and API key.)

Try it

If you build on Cognigy.AI — as a developer, solution architect, or SI partner — I’d genuinely love to hear what workflows you’d automate first. And if you’re building MCP servers for other enterprise platforms, the dryRun + redaction + async-polling patterns here are portable; steal them.