From API Layer to AI-Native OCS: Exposing Charging Intelligence via MCP

A few weeks ago, I shared how I built a RESTful API layer over Oracle’s OCNCC billing engine using decoded Escher protocol flows. The response from operators, MVNEs, and BSS/OSS teams was overwhelming—and it led to a simple but powerful question:

Could this API layer be exposed to AI agents?

The answer is yes, and the implications for Online Charging Systems (OCS) are far bigger than I initially anticipated.

The Problem: OCS Platforms Are Still Black Boxes

Most OCS platforms, whether Oracle OCNCC, Matrixx, or legacy IN stacks, remain hidden behind proprietary protocols (like Escher) and limited integration surfaces. Even basic operational queries often require:

• Deep platform-specific knowledge.
• Custom-built tooling or SDKs.
• Manual intervention for troubleshooting or automation.

This creates a barrier to innovation. While modern telecom networks (especially 5G) demand agility, real-time intelligence, and automation, the charging layer often lags behind, locked in a specialist-driven model.

The Solution: MCP as a Bridge to AI-Native OCS

To solve this, I’ve been experimenting with Model Context Protocol (MCP), an open standard for exposing tools, data, and capabilities to AI agents in a structured, machine-readable way. Here’s how it works:

Architecture Overview

Key Design Principles:

1. Non-Invasive: The MCP layer sits in front of your existing API and Oracle query layers, leaving the underlying OCNCC stack untouched. No re-architecture required.
2. Tool-Centric: Instead of exposing raw endpoints, the system presents meaningful, self-descriptive tools that AI agents can reason about, not just execute.
3. Standardised: MCP provides a common language for AI to interact with OCS capabilities, regardless of the underlying platform (OCNCC, Matrixx, etc.).

What Does an AI-Native OCS Look Like?

By exposing OCS capabilities via MCP, AI agents gain the ability to:

• Understand what operations are possible (e.g., subscriber lookups, balance adjustments, policy controls).
• Reason about when and why to use them (e.g., “This subscriber’s session failed, check their balance and profile”).
• Execute actions with structured, auditable precision.

Example Tools Exposed via MCP

Here’s a snapshot of the OCS capabilities currently exposed in the prototype:

Why This Matters:

• No More Silos: AI agents can query and act across charging, policy, and network layers without jumping between systems.
• Natural Language Interfaces: Tasks like bundle resets or subscriber diagnostics, which previously required SDKs or APIs, can now be triggered via conversational queries (e.g., “Why did MSISDN 447123456789’s session fail?”).
• Automation-Ready: Routine operations (e.g., balance adjustments, profile updates) can be automated via AI workflows.

Use Cases: How AI-Native OCS Changes Operations

1. Support Workflows: Diagnose Issues in Seconds

Before:

• A support agent receives a complaint: “My data isn’t working.”
• They manually check OCNCC logs, subscriber profiles, and network alarms, often requiring multiple tools and logins.

After (with MCP):

• The agent (or a customer-facing chatbot) asks the AI:“Diagnose why MSISDN 447123456789 can’t access data.”
• The AI:
  1. Calls lookup_subscriber → Finds the subscriber has insufficient balance.
  2. Calls inspect_profile → Confirms no barring is active.
  3. Calls query_network_topology → Verifies the subscriber’s serving node is operational.
  4. Conclusion: “Subscriber has £0 balance. Top up required.”
• Result: Faster resolution, fewer escalations, and happier customers.

2. Network Operations: Correlate Alarms and Charging Events

Before:

• A network alarm fires for a billing engine node.
• NOC teams manually cross-reference alarms with subscriber sessions and charging logs to identify impact.

After (with MCP):

• The AI automatically:
  1. Calls correlate_alarms → Links the alarm to 1,200 failed charging sessions on that node.
  2. Calls query_network_topology → Identifies the node is overloaded.
  3. Action: Triggers a load-balancing adjustment or node restart (if automated).
• Result: Proactive issue resolution before subscribers are impacted.

3. 5G Policy Control: Dynamic, AI-Driven Charging

Before:

• 5G Policy Control Function (PCF) makes static charging decisions (e.g., “Allow this slice if balance > £10”).
• No real-time intelligence: Can’t adapt to network congestion, subscriber behaviour, or business priorities.

After (with MCP):

• The PCF queries the AI:“Should I allow a new 5G slice for MSISDN 447123456789? They’re roaming in Spain with £5 balance.”
• The AI:
  1. Calls lookup_subscriber → Confirms £5 balance.
  2. Calls check_service_eligibility → Checks roaming agreements for Spain.
  3. Calls query_network_topology → Sees high congestion in Spain.
  4. Decision: “Deny slice. Suggest downgrading to 4G to avoid overage charges.”
• Result: Smarter policy control, reduced revenue leakage, and better subscriber experience.

4. MVNO Operations: Self-Service Charging Management

Before:

• MVNOs rely on manual requests to the host operator for bundle resets, balance adjustments, or reporting.

After (with MCP):

• MVNOs interact with the OCS via AI:“Reset monthly bundles for all subscribers on the ‘Premium’ plan.”
• The AI:
  1. Calls reset_bundle for all ‘Premium’ subscribers.
  2. Logs the action for audit and billing reconciliation.
• Result: Faster operations, reduced errors, and lower OPEX.

The Bigger Picture: Why This Matters for Telecom

1. Democratising OCS Access

• Today: OCS platforms are specialist-driven. Only engineers with deep platform knowledge can extract insights or automate workflows.
• Tomorrow: With MCP, anyone (support agents, NOC teams, even subscribers via chatbots) can query and act on charging data—without writing code.

2. Enabling AI-Driven Automation

• Predictive Charging: AI can anticipate balance depletion and proactively notify subscribers or trigger auto-top-ups.
• Anomaly Detection: AI can flag unusual patterns (e.g., fraud, misconfigurations) in real time.
• Dynamic Pricing: AI can adjust pricing based on network demand, subscriber loyalty, or competitor offers.

3. Future-Proofing for 6G and Beyond

• As networks evolve toward 6G, AI-native architectures will become the norm.
• MCP provides a standardised way to expose any OCS or IN platform (OCNCC, Matrixx, legacy IN) to AI, without vendor lock-in.

What’s Next? The Roadmap for AI-Native OCS

This started as a personal R&D exercise, but the architectural pattern is universal. Any OCS or IN platform with a queryable data layer and a billing interface can be exposed via MCP. Here’s what’s left to do:

1. Expand the Tool Surface

• Add more OCS capabilities as MCP tools (e.g., refunds, shared balance groups, QOS adjustments).
• Support bulk operations (e.g., “Apply a discount to all subscribers in region X”).

2. Tighten Security Boundaries

• Role-Based Access Control (RBAC): Restrict which AI agents can call which tools (e.g., a support chatbot can’t adjust balances).
• Audit Logging: Track every AI-driven action for compliance and debugging.
• Rate Limiting: Prevent abuse (e.g., an AI agent spamming lookup_subscriber).

3. Ensure Full Observability

• Logging: Capture all MCP requests/responses (e.g., via Prometheus).
• Tracing: Correlate AI actions with OCNCC logs and network events.
• Alerting: Notify operators of failed AI-driven operations (e.g., “Balance adjustment failed for MSISDN 447123456789”).

4. Integrate with AI Orchestration Layers

• Connect MCP to AI orchestration platforms (e.g., LangGraph, Microsoft Autogen) for multi-step workflows.
• Example: “If a subscriber’s balance is low AND they’re roaming, send them a top-up reminder via SMS.”

The Future: From API-Enabled to AI-Native OCS

We’re at an inflection point. APIs made OCS platforms programmable. MCP makes them AI-native.

• Phase 1 (Now): APIs expose OCS capabilities to developers.
• Phase 2 (Emerging): MCP exposes them to AI agents.
• Phase 3 (Future): Fully autonomous OCS, where AI manages charging in real time, optimising revenue, reducing churn, and enabling self-healing networks.

This isn’t just about efficiency. It’s about unlocking the full potential of your OCS platform, whether it’s Oracle OCNCC, Matrixx, or a legacy IN stack.

Let’s Collaborate

This is still early days, but the direction is clear: AI-native OCS is coming, and MCP is the key to getting there without replacing your existing infrastructure.

If you’re working with OCNCC, Matrixx, or similar platforms and exploring how AI fits into your operational model, I’d love to compare notes. Here are some questions to kick off the discussion:

• Have you experimented with AI-driven telecom operations?
• What OCS capabilities would you prioritise exposing to AI?
• How do you see MCP (or similar protocols) fitting into your roadmap?

Reach out or connect with me on LinkedIn.