Exposing CAMARA Network APIs as MCP Tools: Orange’s Provider Implementation

TL;DR

Orange has contributed the first Provider Implementation (PI1) to the CAMARA MCP Enablement initiative: a fully working MCP server written in TypeScript that exposes Orange’s CAMARA-compliant Network APIs as native tools for AI assistants. Connect Claude Desktop, Cline, Goose, or any MCP-compatible agent to real telecom capabilities — device location, SIM swap detection, identity verification, quality of service — in minutes. The code is open-source and available at github.com/camaraproject/MCPEnablement_PI1.

Background: MCP meets telecom

The Model Context Protocol (MCP) has emerged as the de-facto standard for giving AI assistants access to external tools and data sources. An MCP server is a lightweight process that speaks a well-defined JSON-RPC protocol over stdin/stdout, exposing capabilities — called tools — that an LLM host (Claude Desktop, Cursor, Goose…) can invoke autonomously during a reasoning chain.

On the telecom side, CAMARA — the Linux Foundation project backed by major operators — defines a family of standardized Network APIs: device location, SIM swap, quality on demand, KYC match, population density, and more. These APIs expose operator-grade network intelligence through simple, secure REST interfaces.

The natural question: what happens when you wire MCP to CAMARA?

In early 2026, the CAMARA Technical Steering Committee launched the MCP Enablement Program (tracked in Governance #210) to define how Network APIs should be documented, designed, and exposed for AI agent consumption. Workstreams cover API Design Guide enhancements for AI readability, security and consent guidance, and — critically — pilot tool definitions built against real implementations.

Orange contributed the first concrete answer to that last point.

What the PI1 server actually does

The PI1 repository contains a Node.js/TypeScript MCP server that bridges AI assistants to the Orange Network APIs Playground. The Playground is a stateful mock environment: same request/response shapes as production, but driven by synthetic data you fully control (see the Playground deep-dive article for setup details).

The server registers 27 MCP tools in two categories.

Network API tools (reading real network state)

Tool	CAMARA API	What it does
get-device-location	Location Retrieval v0.3	Returns a circular or polygonal area where a device is located
verify-device-location	Location Verification v1	Returns TRUE / PARTIAL / FALSE / UNKNOWN against a provided circle
get-device-reachability-status	Device Reachability v0.6	CONNECTED_DATA, CONNECTED_SMS, or NOT_CONNECTED
get-device-roaming-status	Device Roaming Status v0.6	Roaming flag, country code, country name
get-sim-swap-date	SIM Swap v1	Timestamp of the most recent SIM change
check-sim-swap	SIM Swap v1	Boolean: was a SIM swap performed in the last N hours?
kyc-match	KYC Match v0.2	Compares user-supplied identity attributes against operator records
get-population-density-data	Population Density v0.3	People/km² density estimates for a geographic area and time window
retrieve-qos-profiles	Quality on Demand v0.11	Lists available QoS profiles for a device
create-qos-session / get-qos-session / delete-qos-session / …	Quality on Demand v0.11	Full CRUD lifecycle for QoS sessions

Playground administration tools

Nine additional tools wrap the Admin Playground API: create/read/update/delete test phone numbers and set their simulated state (location, reachability, roaming, SIM swap timestamp, KYC data). This lets an AI agent initialize a complete test scenario before running network API calls — without ever touching real subscriber data.

Architecture walkthrough

Managing large events, from concerts to sports games, requires real-time monitoring to ensure safety A few implementation choices worth explaining:

• Stdio transport. MCP’s stdio mode makes the server a simple subprocess. No port to bind, no TLS termination, no reverse proxy — the host process owns the lifecycle. This is ideal for local developer tooling, which is the primary target for a playground implementation.
• Zod input validation. Every tool validates its input before making any network call. Phone numbers are checked against E.164 regex, coordinates against valid ranges, timestamps against ISO 8601. This matters for agent robustness: LLMs can hallucinate parameter formats, and an informative validation error is far more useful than an opaque 400 from the upstream API.
• Human-readable responses. All tool responses are formatted as markdown text, not raw JSON. The AI assistant’s context window benefits from structured prose (“Device is currently roaming in Germany (country code: DE)”) rather than parsing nested objects.
• Retry with exponential backoff. The client retries up to 3 times with delay min(1000 × 2^(attempt-1), 5000) ms. Transient network errors do not abort an agentic workflow mid-task.
• Proxy support. HTTP_PROXY / HTTPS_PROXY / NO_PROXY are honoured via undici‘s EnvHttpProxyAgent. Corporate environments that require proxy chains for outbound HTTPS are fully supported.

Getting started in five minutes

Prerequisites:

• Node.js ≥ 24,
• credentials from developer.orange.com/apis/camara-playground

bash
git clone https://github.com/camaraproject/MCPEnablement_PI1
cd MCPEnablement_PI1
corepack enable          # activates Yarn 4.13.0
yarn install
yarn build
        
        Copied 
      Code language: PHP (php)

For Claude Desktop, add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):

json
{
  "mcpServers": {
    "orange-network-api": {
      "command": "node",
      "args": ["/absolute/path/to/MCPEnablement_PI1/dist/index.js"],
      "env": {
        "CLIENT_ID": "your_client_id",
        "CLIENT_SECRET": "your_client_secret"
      }
    }
  }
}
        
        Copied 
      Code language: JavaScript (javascript)

The same pattern works for any MCP-compatible host: Cline, Goose, MCPJam, Cursor. Point command at the compiled dist/index.js, inject credentials via env, done.

Three concrete use-cases

1. Fraud detection in a banking assistant

A customer service agent receives a contactless payment dispute. The LLM autonomously calls:

1. check-sim-swap — was the SIM swapped in the last 48 hours? If yes, flag as high-risk.
2. verify-device-location — is the phone currently near the payment terminal location? If not, flag as suspicious.

Both signals arrive in the same reasoning step, without the developer writing a single line of orchestration code. The operator’s network becomes a real-time fraud sensor plugged directly into the AI decision loop.

2. Real estate foot-traffic analysis

A small business owner asks an AI assistant to compare two Paris addresses for a future bakery (as detailed in this earlier article). The agent calls get-population-density-data for each coordinate, cross-references the bakery’s planned opening hours (7am–1pm, 4pm–8pm), and delivers a data-backed lease recommendation — without the user knowing an API was ever called.

3. Device lifecycle management

An IoT platform operator wants to verify device connectivity before sending a firmware push. The agent calls get-device-reachability-status for a list of device MSISDNs and get-device-roaming-status to skip devices in countries with restricted update policies. Quality on Demand tools can then establish a guaranteed-bandwidth session for the transfer. All coordinated by the model, zero custom integration code.

The CAMARA context: why this matters beyond Orange

The PI1 is deliberately not a normative CAMARA spec. It is a working implementation that informs what a spec should say.

The CAMARA Commonalities Working Group is currently working on:

• API Design Guide enhancements (Commonalities #587): how OpenAPI descriptions should be written to be AI-readable — clear tool names, actionable error messages, unambiguous parameter semantics.
• MCP Security & Consent guidance: how operator-grade authentication (OIDC, PKCE, consent management) maps to the MCP trust model.
• MCP Readiness Checklist: criteria that a CAMARA API must satisfy to be safely exposed as an MCP tool.

PI1 provides empirical data for all three workstreams. The two-OAuth-flow pattern, the Zod validation decisions, the response formatting choices — each one encodes a real engineering trade-off that the spec authors can learn from.

CAMARA’s multi-operator model means that an MCP tool definition standardized here could, in principle, work across any operator implementing the same CAMARA API. A developer building an anti-fraud agent today against the Orange Playground could point the same agent at a Deutsche Telekom or Telefónica endpoint tomorrow with minimal changes.

What’s next

The PI1 targets release r1.1, aligned with CAMARA Commonalities r4.1 and ICM r4.1. Upcoming work includes:

• Extending tool coverage as new Playground APIs reach maturity
• Aligning tool descriptions with the Commonalities API Design Guide enhancements as they are finalized
• Contributing learnings back to the CAMARA MCP Enablement workstreams

Contributions and feedback are welcome through the Commonalities Working Group mailing list (wg-commonalities@lists.camaraproject.org) or directly via GitHub issues in the PI1 repository.

Ready to try it?

1. Get your Playground credentials
2. Clone the PI1 repository
3. Configure your AI assistant and start prompting

The gap between “AI assistant” and “network-aware AI agent” is now a few lines of JSON.