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
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
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"
}
}
}
}
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.
Top comments (2)
The dry-run-first approach is exactly the right pattern for giving agents tool access — explicit intent before action. I've been thinking about this from the opposite angle: agents that are too eager to use tools when they should be thinking. Built Brainstorm-Mode (mehmetcanfarsak on GitHub) that adds PreToolUse hooks to block tool calls during ideation phases. Three modes (divergent, actionable, academic) keep the agent from jumping straight to execution. It's the inverse of your dry-run pattern — instead of 'confirm before acting,' it's 'block acting until thinking is done.'
Love this framing, you're right that they're mirror images, and I think the reason both feel correct is that they intervene at the same architectural seam: the moment right before a tool fires. We just guard it from opposite ends.