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

> Source: <https://dev.to/tsvetang2/i-built-an-mcp-server-with-132-tools-so-claude-can-manage-cognigyai-agents-for-me-2dd0>
> Published: 2026-06-12 20:48:31+00:00

I've spent some quite of time building conversational AI agents on [Cognigy.AI](https://www.cognigy.com/) — 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.

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

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](https://github.com/TsvetanG2/cognigy-ai-mcp-management-server/blob/master/TOOLS.md).

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

**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.

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.

```
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.

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.)*

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.