MCP in gloCOM & Why Your Communications Platform Needs to Talk to AI

Sanjin Lisic

Product Owner

Someone asks their AI assistant to generate a standup from their chats and calls since Monday. Under the hood, the assistant is pulling that person’s message history across their 1-on-1 and group chats, cross-referencing it against their call log (incoming, outgoing, missed) for the same window, and synthesizing that into something coherent.

Start simple, what problem does MCP server actually solve?

An AI assistant that can’t read your call history or your chat threads can’t tell you what you missed yesterday. It can chat with you, but it can’t act as an assistant to your actual communications, because it has no access to them.

MCP server is the layer that changes that because it lets an AI assistant securely query a user’s calls, chats, and meetings and answer real questions grounded in what actually happened, not a generic response.

The difference in practice is the difference between asking an AI “how do standups usually work” and asking it “generate my standup from what I actually discussed since Monday.” Only one of those is useful every single day.

MCP support technically existed in gloCOM 8.0. What was actually missing?

Access existed, but it needed manual configuration before an AI assistant could connect. That’s a bigger blocker than it sounds like. It meant a partner or admin had to know MCP existed, understand what to configure, and do it as a distinct extra step, disconnected from the normal gloCOM rollout.

Realistically, most users and partners never got there. A capability that requires someone to go find it and turn it on might as well not exist for the vast majority of an install base.

Business people with headsets using computers in office

What changes with it being preconfigured in 8.1?

It removes the step entirely. There’s no setup, no admin action, no separate rollout project and it ships as part of gloCOM itself. That’s the difference between a feature partners have to know about, plan for, and sell, and a capability that’s simply part of what gloCOM is out of the box. Every user gets an AI-ready communications layer without anyone deciding to turn it on first.

That matters more for adoption than any individual capability inside it. The best feature in the world doesn’t get used if it needs a configuration step first, because most users never take that step.

Walk through an actual scenario of what does “generate my standup” really touch?

Someone asks their AI assistant to generate a standup from their chats and calls since Monday. Under the hood, the assistant is pulling that person’s message history across their 1-on-1 and group chats, cross-referencing it against their call log (incoming, outgoing, missed) for the same window, and synthesizing that into something coherent.

Before this existed, that’s fifteen minutes of someone manually scrolling through three different views in gloCOM to reconstruct their own week. Now it’s a sentence.

The other examples work the same way: “what did I discuss with John yesterday” is a targeted search across one contact’s message history; “show my missed calls from last week” and “list my meetings for tomorrow” are direct pulls against call history and scheduled meetings.

These are the questions people already ask themselves constantly. The only thing that changed is that now an assistant can actually answer them.

Worried fatigued mature business woman wearing glasses having headache at work.

Why gloCOM first, rather than PBXware?

Because gloCOM is where the user-level data already lives, the individual’s chats, calls, and meetings. That’s the natural first surface for “help me understand my own day.”

PBXware is the system underneath, closer to configuration and system-wide call data. Starting where the immediate, obviously useful queries live was the right sequencing to get people using AI against their own communications first, then extend the same idea to a broader, more administrative surface.

What’s the honest pitch to a client right now, versus what should wait for PBXware-level MCP?

Right now, the pitch is simple and it’s already true: gloCOM ships with an AI-ready communications layer, no setup required. That’s demoable today, and it’s a much easier sell than a feature that needs configuration before a prospect can see it work.

What should wait is any promise about system-wide or administrative AI capability, that’s the PBXware phase which is in the works.

Colleagues sitting at meeting and chatting

Does this matter competitively, or is it table stakes now?

It matters, because “table stakes” assumes everyone else already has it working out of the box, and most don’t. A lot of platforms can point to an AI integration that exists somewhere in their docs behind a setup guide.

Very few can point to it being on by default the moment you deploy. That gap of sold versus actually experienced, is where this creates a real difference in a competitive evaluation, especially for a customer who’s going to try the capability during a proof of concept rather than take a slide’s word for it.

What’s next on the roadmap?

Extending the same MCP support into PBXware itself. Today the access lives in gloCOM, close to the end user’s own data. The next step reaches further into the platform (system-level call data, configuration, administration) giving partners and their customers a broader surface to build AI-driven tools and workflows against.

The gloCOM step was proving the model works and removing friction from adoption. The PBXware step is where it becomes a platform capability rather than a user-level convenience.

Preconfigured MCP support is available now in gloCOM 8.1, alongside PBXware v8.1. Support for pre-configured MCP in PBXware itself is on the roadmap. Reach out to your Bicom Systems contact to discuss timing for your deployment.