MCP: a protocol must for telecommunications

Many telecom vendors and operators are working with AI teams, aiming to enable AI agents to handle more than simple chat interactions. The challenge is that AI can understand the customer, but it can’t reliably place an order, check a catalog, or retrieve a customer profile without custom code.

Telecom’s business support systems (BSS) landscape is a tangle of systems: CRM, BSS, OCS, provisioning, fault management, each with its own protocols. A single task, like correlating alarms to predict outages, will involve SNMP, REST, SOAP, and files, each requiring custom code and weeks of testing. Model context protocol (MCP) solves this by acting as a universal plug between AI agents and business systems. Instead of building a different connector for every use case, MCP provides a single, standard way to expose telecom APIs to agents.

For BSS, this means agents can finally interact with the same TM Forum Open APIs that our applications already utilize

Why should BSS teams care about MCP?

BSS is where the money flows. If AI agents are going to help customer service and sales, they need safe and structured access to:

• Commercial product catalog
• Order management
• Customer records
• Inventory

Until now, every vendor has built or will have to build its own connectors. MCP fixes this by introducing three simple building blocks:

1. Tools that are more like actions, such as creating a product order.
2. Resources that act like data lookups, e.g., retrieve customer profile.
3. Prompts or safe request templates that guide AI on what to send.

This structure enables agent behavior to be predictable, testable, and auditable.

The TM Forum APIs that matter most

• TMF620 Product Catalog: search offers, price plans
• TMF622 Product Ordering: create or manage orders
• TMF629 Customer Management: get customer details
• TMF637 Product Inventory: check active services

These APIs already follow TMF630 design rules, which define how CRUD operations, tasks, and notifications work. MCP simply wraps them in a way that AI agents can discover and use without hard-coding.

How MCP fits into an ODA architecture

1. The MCP server resides within the integration layer of the BSS, i.e., on the Open Digital Architecture (ODA) Canvas.
2. AI agents connect to it as clients. They discover what tools/resources are available at runtime.
3. The server translates those calls into TM Forum Open API requests via your API gateway.
4. Policies and security sit in between: OAuth2, scopes, masking of personal data, and logging.

The result: AI agents use the same APIs as other apps, but with a simplified interface designed for them.

Handling events and notifications

TM Forum APIs also send notifications; for example, when an order changes status. In real telecom setups, these notifications often flow through event-driven systems, such as Kafka and AsyncAPI.

The MCP server can bridge these by subscribing to those events and exposing them as streams or feeds that agents can safely consume. This way, an AI assistant can tell a customer: “Your order has just moved to ‘in progress’” without polling or custom glue.

A simple example

Imagine a customer says, “I want to order a new fiber plan for my home.”

Here’s how it plays out with MCP:

1. The agent uses the search_offers tool, which is mapped to TMF620 Product Catalog.
2. The agent confirms the details with the customer, i.e., address, plan.
3. The agent calls the create_product_order tool, which is mapped to TMF622.
4. The system replies with an order ID and status.
5. The MCP server listens for order update events and feeds them back to the agent.

Everything is logged, secured, and tested against TM Forum’s API conformance.

Guardrails telcos must build in

AI integration will never be just calling a TM Forum API. Governance is the most critical layer.

• Only expose tools you’re ready to automate
• Apply rate limits to avoid flooding the BSS
• Keep a full audit trail
• Reuse TM Forum’s CTKs, i.e., the conformance test kits to validate mappings

What’s missing in MCP for telecom domination?

Telecom thrives on real-time messages and events. MCP’s current request/response model doesn’t handle push-driven data well. Adding an “events” verb or integrating CloudEvents headers could allow Kafka topics to flow seamlessly, enabling AI to react to live network signals.

Multi-tenancy is another must. A single MCP server might front multiple MVNO brands, each with distinct rate limits and data scopes. Additionally, regulators demand traceability, which can be resolved using OpenTelemetry.

What is the horizon for MCP?

MCP empowers telecoms to make AI agents first-class citizens in BSS without bypassing standards. It turns agent integration from ad-hoc experiments into structured, governed, and repeatable actions.

It is the missing piece: the USB-C of AI in telecoms, finally letting agents plug into TM Forum APIs the right way.