Over the past few months I’ve been working on a project I’m genuinely excited about: an MCP (Model Context Protocol) server for Webex Calling.
--> https://github.com/lutztalk/mcp-webexcalling
Seeing how much time I spend inside Webex Calling, this felt like a natural place to start. I design it, migrate it, automate it, and troubleshoot it for real environments on a regular basis. Webex has an enormous surface area of APIs and features, and I plan to expand into other parts of the platform over time. But Webex Calling is a core UC system full of operational data and repetitive admin tasks, and it practically begs for automation.
The short version is that this project lets you talk to your Webex Calling environment in plain English and actually get real work done. Not demos or summaries, but real administrative actions.
Under the hood, this is still powered by the same Webex APIs we all use today. MCP simply gives us a way to expose those APIs as structured tools that AI assistants can understand and safely execute. The result is something I find genuinely powerful: instead of clicking through Control Hub, digging through documentation, or writing one-off scripts, you can just ask questions and issue commands.
“What call queues do we have?”
“Assign phone number 1234 to John Doe.”
“Show me all unassigned numbers in the New York site.”
“Who changed devices this week?”
The assistant can return clean, human-readable answers or perform the change directly. That shift, from dashboards and scripts to conversation, is what this whole project is really about.
Why I Built MCP for Webex Calling
I’ve spent most of my career in voice and collaboration, and anyone who has run real environments knows how much of the job ends up being repetitive administration. Audits, cleanups, onboarding, license checks, device swaps, call flow updates, reporting....the list goes on and on.
None of these tasks are technically hard, but they are time-consuming, click-heavy, and often split across GUIs, APIs, spreadsheets, and tribal knowledge. Every environment eventually runs into the same questions: where a number is actually assigned, which site owns a user, who changed a queue, or why a device does not match what’s in the documentation.
The moment this really clicked for me was after seeing a demo from my friend and former colleague, Jon Snipes. He showed me something he had been working on where he was interacting with real systems from inside Claude using MCP-style tooling for Webex Calling. Watching him query live data and trigger actions conversationally made it obvious this was more than a chatbot answering questions.
That demo stuck with me. I kept thinking about how powerful that model could be. This wasn’t just about letting AI read data. It was about letting AI safely operate systems using well-defined tools.
So I started wrapping Webex Calling APIs into MCP tools. Each tool has explicit inputs and outputs, and each one maps to something an administrator actually does. Listing users, pulling licenses, creating locations, assigning numbers, generating device activation codes, building call queues, fetching call records, and updating voicemail settings are all encoded as structured tools.
Instead of writing glue code every time, the logic now lives in the MCP server. The assistant orchestrates those tools. That’s the real unlock here. MCP turns APIs into an operational layer that an assistant can reason over.
With MCP in place, admins can say things like “list all users with the premium audio license” or “show the last week of call detail records for user X” without writing a single line of code. The server I built currently wraps Webex Calling into roughly eighty-plus specialized tools covering everything from user management to call analytics. It’s still early, but even as a proof of concept it already shows how much faster and smoother administration can be.
What This Looks Like
Architecturally, I think about this in three clean layers.
At the top is the assistant. This is the conversational interface, whether that’s Claude, another hosted model, or a local LLM.
In the middle is MCP. This is the control plane. It exposes structured tools, enforces what actions are even possible, and handles the translation between conversation and execution.
At the bottom are the real systems. In this case, the Webex Calling APIs that actually perform the work.
The assistant never talks directly to Webex. It only talks to MCP. MCP never “thinks.” It just exposes tools. That separation is what makes this model powerful. It keeps reasoning, control, and execution in distinct layers, which is exactly what you want in enterprise environments.
Who It’s For
This server is aimed at people who actually run Webex Calling environments: IT admins, operations teams, partners, service providers, and consultants who spend real time inside Control Hub.
If you are responsible for onboarding and offboarding users, managing phone numbers, maintaining call queues, or cleaning up environments after projects, this tool can save you a lot of time. Consultants and integration specialists can also benefit when demoing, auditing, or maintaining systems. Even people who are not “coding experts” can get real answers.
Using MCP also does not lock you into a black box. The server is open-source and written in Python, so anyone can inspect the code, extend it, or integrate it into other tools. An admin can plug it into an MCP-compatible assistant and immediately start interacting with live Webex data.
What MCP Is Not
This project is not about replacing administrators, and it is not about giving an AI unrestricted control over your phone system.
It is about removing friction between intent and execution. It is about capturing operational knowledge in tools instead of tribal memory or brittle scripts. The goal is to make skilled admins faster, safer, and more effective, not to automate them out of the picture.
If you are looking for a polished, end-user AI product, this is not that. This is infrastructure. It is meant for people who like to build, automate, experiment, and shape how their environments are operated.
Public LLMs vs Local Models: Why This Matters for Enterprises
One of the most important aspects of this approach is that MCP does not require you to hand your environment to a public AI service.
You can absolutely use this server with a hosted model if that fits your use case. Public LLMs are powerful, easy to start with, and great for experimentation. But in enterprise collaboration environments, privacy, compliance, and data control matter. Call records, user data, phone numbers, and organizational structures are not things many teams are comfortable sending to third-party AI endpoints.
Because MCP cleanly separates the assistant from the tools, you can run the entire stack locally.
You can pair this MCP server with a local or privately hosted LLM running on your own infrastructure. That might be a model running on internal GPU servers, in a secured cloud tenant, or inside segmented networks. In that setup, sensitive data never leaves your control plane. Prompts, responses, and API results stay inside your environment.
This significantly changes the risk profile.
Instead of exposing operational data to a public model, you are deploying an internal operations assistant that talks to internal systems and is backed by a model you control. That makes MCP a strong fit for regulated industries, healthcare, government, and enterprises with strict compliance or data residency requirements.
From a security standpoint, MCP is also safer than ad-hoc AI scripting because every capability is explicitly defined. The assistant cannot arbitrarily act. It can only invoke the tools you expose. That means permissions, logging, and auditing can live at the tool layer, where enterprise teams are already comfortable enforcing policy.
MCP does not just make AI more useful. It makes AI governable.
What It Can Do
The MCP Webex Calling server already supports a wide range of real administrative functions. These tools map directly to live Webex Calling APIs and perform real operations.
Core Capabilities (Current)
User & Organization Management
• List users by name, email, location, or license
• Retrieve user profiles, phone numbers, and extensions
• Update user attributes programmatically
• Identify users missing licenses or numbers
Licensing & Entitlements
• Audit license assignments across the organization
• Find unassigned licenses
• Assign or revoke Webex and Webex Calling licenses
• Validate license state for users and locations
Numbers & Extension Management
• List available and assigned phone numbers
• Assign or remove numbers from users and services
• Set, change, and validate extensions
• Identify conflicts and orphaned assignments
Locations (Sites)
• List all locations and services
• Create new locations
• Modify location attributes
• View users, numbers, and services per location
Device Provisioning
• Generate activation codes for devices
• Create devices by MAC address
• Assign devices to users or places
• Check device ownership and registration status
Call Queues
• List and inspect call queues
• View members, routing policies, schedules, and greetings
• Create, update, and delete call queues
• Add or remove agents conversationally
Auto Attendants & Call Flows
• List and inspect auto attendants
• View menus, schedules, and routing logic
• Create, update, and delete auto attendants
• Modify call flow behaviors programmatically
Hunt Groups & Calling Services
• Create, update, and remove hunt groups
• Inspect service configurations
• Manage service memberships
Voicemail
• Retrieve voicemail configuration
• Update voicemail settings and behaviors
• Support voicemail audits and bulk updates
Call Analytics & Reporting
• Retrieve call detail records
• Summarize usage by user, site, or service
• Compare activity over time
• Support conversational reporting queries
Webhooks & Events
• List existing webhooks
• Create webhooks for Webex Calling events
• Support integration with external systems
Every tool returns structured data that the assistant can reason over. Instead of dumping raw JSON, the assistant can generate readable tables, summaries, or filtered results. That structure is what enables higher-level workflows to emerge.
The Power of MCP and Conversational Tools
What makes MCP exciting is that it bridges the gap between data APIs and human language. On one side you have Webex Calling’s APIs. On the other, you have AI systems that understand natural language. MCP sits between them and gives us a way to connect the two safely.
From the admin’s perspective, it feels conversational. Under the hood, it is routing intent into real API calls with defined inputs and outputs.
This reduces human error, standardizes operations, and lowers the barrier for teams to interact with complex systems.
Administrator Experience and Ease of Use
From an administrator’s perspective, the benefits have been immediate. Tasks that used to require navigating multiple pages or running scripts are now questions.
Troubleshooting is faster. Audits are simpler. Bulk changes are safer.
Because the MCP server talks directly to official APIs, the data is always current. That reduces mistakes caused by stale exports or inconsistent documentation.
In practice, this turns Webex Control Hub into a conversational operations layer.
What’s Next
This project is very much a work in progress.
On the Webex Calling side, I’m continuing to expand coverage and depth, including deeper analytics, more service-level controls, and better support for multi-tenant and partner environments.
Beyond Calling, this same approach applies to the rest of Webex. Meetings, messaging, room devices, and contact center all expose APIs that could be wrapped into MCP tools. Longer term, I see this becoming a universal Webex operations layer that can run behind either public or private AI systems.
Because the project is open-source, I want it to evolve with real operators and real needs. If there is a task you hate doing in Webex, it is probably a good candidate for the next tool.
Conclusion
Building the MCP Webex Calling server has been a fascinating journey. It scratches a personal itch because I enjoy automation, but more importantly it represents a shift in how we interact with operational systems.
We have spent decades building better dashboards, portals, and admin interfaces. I think the next shift is building better control planes. Ones you can talk to, reason with, and safely delegate work to. Systems that are driven by intent instead of clicks.
Every time this project answers a real admin question correctly or executes a change cleanly, it reinforces that direction. Administration starts to look less like navigating software and more like operating a system.
This project is still evolving, and I’m excited to see how others use it and what gets built on top of it. If you run Webex Calling and you’re curious, check out the repo, try it out, and let me know what works, what breaks, and what you want to see next.