CAMARA solves one problem for telecom operators: it standardizes how developers access network capabilities.
MCP solves another: it gives AI agents a standard way to discover and use external tools.
Put them together and a CAMARA API stops being something only an application developer calls directly. It can become a tool an AI agent can select and invoke as part of a workflow.
This is no longer theoretical. CAMARA published its MCP position paper in January 2026, describing an MCP server as the translation layer between AI applications and CAMARA network APIs.
Here is what the implementation looks like.
Step 1: Keep the CAMARA API as the network interface
Do not replace your CAMARA implementation.
The MCP layer sits above it.
CAMARA continues to provide standardized interfaces for capabilities such as Number Verification, SIM Swap, Device Location, Quality on Demand and Edge Discovery.
The MCP server converts those capabilities into tools that an AI application can understand.
The basic flow is:
AI agent → MCP client → MCP server → CAMARA API → network
CAMARA describes the MCP server as an adaptation layer, meaning operators can add agent access without redesigning the underlying network API architecture.
Step 2: Turn each useful API operation into an MCP tool
An AI agent needs more than an endpoint URL.
It needs to understand what the tool does, when it should use it and which inputs it needs.
Take SIM Swap as an example.
Instead of expecting an agent to understand the underlying REST specification, the MCP layer could expose a clearly described tool for checking recent SIM-change activity.
The same principle applies to location verification, number verification or Quality on Demand.
Tool descriptions matter. CAMARA specifically notes that natural-language descriptions, consistent parameter names and clear input/output examples help AI systems select and call APIs correctly.
Do not expose every endpoint simply because it exists. Start with capabilities that make sense inside an agent workflow.
Step 3: Make the tool description precise
This is one place where human work still matters.
A technically correct API description may still be poor instructions for an AI agent.
Instead of:
“Returns SIM swap information.”
Give the agent enough context to know when the tool is appropriate:
“Check whether the subscriber’s SIM has changed recently before approving a high-risk authentication or financial transaction.”
The API schema tells the system how to call it.
The description tells the agent why.
CAMARA is actively working toward standardized MCP tool definitions alongside API specifications so different implementations do not describe the same network capability in completely different ways.
Step 4: Do not bypass authentication and consent
Making an API callable by an AI agent does not mean giving the model unrestricted network access.
Authorization still sits between the agent and the telecom capability.
CAMARA’s proposed architecture has the MCP server using an authorization token to call the network API. Its current security profile is based around OAuth 2.0/OpenID Connect, while the MCP layer has to handle the additional complexity of AI-driven authorization flows.
Consent also remains critical.
A network location check, for example, should not become available simply because an agent decides the information would be useful. Purpose, scope and user consent still have to travel through the workflow.
In other words: MCP changes how the tool is discovered and invoked. It does not remove the operator’s security controls.
Step 5: Keep billing outside the agent
An AI agent should not need to understand the operator’s billing infrastructure.
It calls a tool.
The CPaaS or API monetization layer records the usage and applies the commercial model.
That separation matters because AI-generated API consumption can be far less predictable than traditional application traffic.
In hSenid AI CPaaS, monetization can be structured around usage-based, message-based, session-based or subscription-based models.
So a CAMARA API exposed through MCP can remain part of the same commercial model as other network APIs.
The agent calls. The platform meters. The operator monetizes.
Step 6: Test with a real agent before production
Orange has already shown what this looks like.
In July 2026, Orange released the first provider implementation from CAMARA’s MCP Enablement initiative: a working TypeScript MCP server exposing CAMARA-compliant Orange Network APIs as tools.
Its implementation includes capabilities such as device location, SIM swap detection, identity verification and Quality of Service. It can connect to MCP-compatible clients including Claude Desktop, Cline and Goose.
That gives operators a useful testing pattern:
Start with a sandbox.
Connect an MCP client.
Give it one or two network tools.
Test successful calls, invalid parameters, authorization failures, consent cases and unexpected agent behaviour.
Then expand.
What we are doing differently in our own platform
In our own AI CPaaS architecture, MCP is not treated as a separate AI demo.
Core telecom capabilities including SMS, OTP, charging, USSD, IVR, voice and location are exposed through a structured platform layer as callable capabilities. The goal is to avoid rebuilding integrations every time a new application or AI workflow needs access to the network.
That design comes from operating at telecom scale. Across hSenid Mobile systems, nearly 50 million transactions are handled daily.
When AI agents become another consumer of network APIs, the difficult part is not making one tool call work.
It is making authentication, consent, billing, logging and governance work every time.
CAMARA standardizes the network. MCP makes it agent-ready.
The practical architecture is straightforward.
Keep the CAMARA API.
Put an MCP server in front of it.
Describe the capability as a clear tool.
Preserve authorization and consent.
Meter every invocation through the commercial platform.
Then test the complete workflow with real AI agents.
That is how a network API moves from being developer-accessible to agent-accessible without rebuilding the network layer underneath it.
