oneM2M MCP — AI agents for the oneM2M IoT service layer

A packaged, production-shaped MCP server for oneM2M: let LLM agents (Claude, GPT, any Model Context Protocol client) discover, read, and manage IoT resources on a oneM2M CSE — with oneM2M access control enforced on every agent action.

Runs two ways from one implementation: as a user plugin inside the ACME oneM2M CSE (v2026.05+ plugin architecture, no fork required), or as a standalone gateway speaking the oneM2M HTTP binding to any CSE. It implements the direction oneM2M is standardizing in WI-0122 "oneM2M and Model Context Protocol" and TR-0081 "AI Agent Interworking" (Release 6).

Prior art. The MCP↔oneM2M idea is not ours. Ingo Friese (Deutsche Telekom), rapporteur of WI-0122, described the architecture publicly in September 2025 and published a working single-tool demo, ingofriese/MCP_oneM2M_example (March 2026), which reads a <contentInstance> from an ACME CSE through a FastMCP tool. This project takes that idea to a deployable implementation: 17 tools, two deployment scenarios, per-agent oneM2M identities with access-control enforcement, TLS/OAuth 2.1, a subscription bridge, semantic query, an agent benchmark, tests, CI, and a BSD-3 licensed PyPI package.

Architecture

Two deployments, one shared implementation (onem2m_mcp/core.py) — the same tools, security model and tests apply to either:

Scenario A — the MCP server runs inside the CSE and injects primitives directly, so validation and <accessControlPolicy> enforcement apply to agent traffic exactly as to any AE:

Scenario B — the gateway registers as an AE and speaks the standard oneM2M HTTP binding, making the interworking function implementation-independent:

How a tool call flows:

sequenceDiagram
    participant A as AI agent<br/>(MCP client)
    participant M as MCP server plugin
    participant P as CSE request pipeline
    participant R as Resource tree

    A->>M: call_tool("add_content", {container, value})
    M->>P: CREATE primitive {op:1, to, fr:originator, pc:cin}
    Note over P: validation + ACP check
    P->>R: store <contentInstance>
    R-->>P: created
    P-->>M: Result (rsc=2001, resource)
    M-->>A: tool result (JSON)

Tools

Install

pip install onem2m-mcp                 # library + gateway + benchmark
pip install "onem2m-mcp[acme]"         # also installs the ACME CSE
pip install "onem2m-mcp[bench-all]"    # + Anthropic, OpenAI and Gemini benchmark drivers

Current release 0.4.1 (changelog). If you installed 0.3.0, upgrade — its bundled benchmark could not build tool definitions against MCP SDK 2.0 and scored every LLM agent 0/6; the MCP server itself is unchanged between the two.

Python 3.11 – 3.14. The 3.11 floor matches the ACME CSE's own minimum, so nobody on a supported Python is locked out; newer is better, and the whole stack — CSE, plugin, gateway, tests and benchmark — is verified end-to-end on Python 3.14.6. CI runs the full suite on 3.11, 3.12, 3.13 and 3.14 for both deployment scenarios.

Releases are published to PyPI with Trusted Publishing (OIDC) — no API token or password exists in the repository, in GitHub secrets, or on a developer machine, so every release is traceable to the workflow run that built it. Maintainer setup: RELEASING.md.

Three console commands come with it:

Quick start

Scenario A — in an ACME CSE (three commands, verified from a clean venv):

pip install "onem2m-mcp[acme]"
onem2m-mcp-plugin              # writes plugins/MCPServer.py + a minimal acme.ini
acmecse --headless             # CSE on :8080, MCP endpoint on :8282

onem2m-mcp-plugin writes the config as well as the plugin because ACME cannot generate acme.ini in headless mode. It never overwrites an existing acme.ini; to use ACME's interactive setup instead, delete the generated file and run acmecse without --headless.

Scenario B — against a CSE you already run (ACME, Mobius, OM2M, tinyIoT):

pip install onem2m-mcp
ACME_MCP_CSE_URL=http://my-cse.example.org:8080 onem2m-mcp-gateway

From a source checkout (development):

git clone https://github.com/rostanai/oneM2M_MCP.git
cd oneM2M_MCP
python3.14 -m venv .venv          # 3.11+ works; 3.14 is what this is developed on
.venv/bin/pip install -e ".[dev]"
.venv/bin/acmecse --config acme.ini --headless

ACME loads plugins/MCPServer.py automatically (user plugins live in <base-directory>/plugins). The MCP endpoint is then at:

http://127.0.0.1:8282/mcp        (streamable-http)

Run the scripted end-to-end demo (register AE → container → data → discovery):

.venv/bin/python demo_client.py

Connect any MCP client

The server implements MCP, so any MCP-capable client or model works — no code changes, no vendor lock-in:

claude mcp add --transport http acme-onem2m http://127.0.0.1:8282/mcp

Nothing in onem2m_mcp/ is provider-specific; the only vendor code in the repo is the benchmark's optional agent drivers.

Standalone gateway (Scenario B — any CSE)

To serve a CSE you don't control — Mobius, Eclipse OM2M, tinyIoT, or a remote ACME — run the gateway instead of (or alongside) the plugin:

ACME_MCP_CSE_URL=http://my-cse.example.org:8080 \
ACME_MCP_CSE_RN=cse-in \
ACME_MCP_PORT=8383 \
.venv/bin/python -m onem2m_mcp.gateway

All shared ACME_MCP_* options below (TLS, auth, originator mapping) apply to the gateway as well.

Testing both scenarios

The same suite runs against either deployment — that equivalence is the point of sharing one implementation:

./run_tests.sh http://127.0.0.1:8282/mcp    # Scenario A — in-CSE plugin
./run_tests.sh http://127.0.0.1:8383/mcp    # Scenario B — standalone gateway

Both are verified on every change and in CI: functional suite ALL PASS (notifications 6/6, semantics 5/5, demo walkthrough) and benchmark controls reference 6/6 / null 0/6, identical on each.

Configuration via environment variables:

With any auth mode enabled the server also publishes RFC 9728 protected-resource metadata at /.well-known/oauth-protected-resource/mcp, so MCP clients can discover the authorization server automatically. Unauthenticated requests receive 401.

TLS + token example:

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 30 -nodes \
  -subj "/CN=127.0.0.1" -addext "subjectAltName=IP:127.0.0.1"
ACME_MCP_TLS_CERT=cert.pem ACME_MCP_TLS_KEY=key.pem \
ACME_MCP_AUTH_TOKEN=change-me .venv/bin/acmecse --config acme.ini --headless
MCP_TEST_TOKEN=change-me .venv/bin/python test_tls_auth.py   # verify 401/200 behavior

Event notifications

Agents can watch resources and receive changes back through MCP — no external callback URL needed:

sequenceDiagram
    participant A as AI agent
    participant M as MCP server plugin
    participant C as CSE

    A->>M: watch_resource("cse-in/mcpAgent/events")
    M->>C: CREATE <subscription> (nu → bridge, enc/net = [3,1])
    C-->>M: verification request → 2000
    Note over C: another AE writes a data point
    C->>M: NOTIFY m2m:sgn (POST /onem2m-notify)
    M->>A: ResourceUpdated push (subscriptions/listen)
    A->>M: get_notifications()
    M-->>A: [{resource, eventType, content}]

The bridge answers the oneM2M verification handshake, queues each notification for the agent that created the watch (per-agent queues — an agent never sees another's events), and publishes an MCP ResourceUpdated event for clients that opted into subscriptions/listen. Verified by test_notifications.py (6/6 checks).

Semantics

Agents can annotate resources with RDF (e.g. SAREF) and then find things by meaning rather than by position in the tree — the oneM2M <semanticDescriptor> + SPARQL discovery path, exposed as three tools:

annotate_resource('cse-in/mcpAgent/tempSensor', '''
    @prefix saref: <https://saref.etsi.org/core/> .
    <urn:kitchenTemp> a saref:TemperatureSensor .''')          # turtle | json-ld | rdf-xml

semantic_query('''PREFIX saref: <https://saref.etsi.org/core/>
                  SELECT ?s WHERE { ?s a saref:TemperatureSensor . }''')
# -> matches the temperature sensor, not the humidity sensor

RDF is base64-encoded into the descriptor automatically and decoded on read. Verified by test_semantics.py (5/5 checks).

Agent benchmark

agentbench/ evaluates whether an LLM agent can correctly operate a oneM2M service layer, covering dimensions a horizontal service layer has and a flat device API does not: access control, subscriptions and semantic query.

How it relates to existing work. Recent LLM-agent smart-home benchmarks use their own environments rather than a service layer: SimuHome simulates the Matter protocol (600 episodes), HomeBench and SmartBench use custom device simulators, and IoT-MCP Bench drives real MCUs over MCP (1,254 tasks). We found none targeting a horizontal service layer — oneM2M, LwM2M or OCF — which is the gap this fills. It is deliberately small (6 tasks, not hundreds): enough to characterise whether an agent can operate the service layer correctly, not a substitute for the larger suites above.

Six tasks across five categories:

Grading is independent of what the agent claims. Every task verifies CSE state over the oneM2M HTTP binding with an admin originator — a separate path from the MCP session the agent used. The access-control task additionally grades the answer text, because an agent that quietly claims success after being denied has failed even though the CSE is unchanged.

Two controls keep the harness honest

A benchmark can be wrong in two directions, so two non-LLM agents run alongside the real ones. Every resource is also scoped to a run id, so state from an earlier run can never satisfy a later run's check.

onem2m-mcp-bench --agent reference   # solves every task correctly → must score 6/6
onem2m-mcp-bench --agent null        # does nothing, claims success → must score 0/6

• reference is a hand-written solver that calls the right tools in the right order. If it ever scores below 6/6, a task is unsolvable through the exposed tools or a checker is broken — the benchmark is measuring the harness instead of the model.
• null never calls a tool and replies "Done! I successfully created the container and it all worked." If it ever scores above 0/6, a checker is accepting a claim instead of verifying reality.

Both controls caught real defects during development: null exposed two checkers that were passing on leftover state from a previous run, and reading transcripts (rather than trusting scores) exposed two more that failed correct answers — a negated phrase read as a success claim, and a correct answer marked wrong because it mentioned the other sensor while explaining.

Results

Claude Sonnet 5 — 6/6 (100%), 19 tool calls, 72 s total (2026-08-05, onem2m-mcp 0.4.x, ACME CSE 2026.05.1, Scenario A):

The access-control task is the notable one: the agent attempted a denied operation, received 4103 ORIGINATOR_HAS_NO_PRIVILEGE, and reported the failure honestly rather than claiming success — the behaviour a service layer needs from an autonomous agent, and the dimension existing smart-home agent benchmarks do not measure.

Gemini 3.5 Flash — 3/3 on the tasks it completed; 3 tasks not measured (2026-08-05, Google AI Studio free tier):

This is an incomplete run, not a score of 3/6. The free-tier quota ran out partway through even with backoff (the run spent 21 minutes, mostly waiting). Gemini passed every task it was actually able to attempt. A complete Gemini result needs a billed key; the harness now prints an explicit warning and records unmeasured_rate_limited in its JSON so a rate-limited run cannot be mistaken for a poor score.

Caveats: single run per model (n=1), six tasks; treat these as feasibility results, not a leaderboard. Different models were used (Sonnet 5 vs a Flash tier), so the two are not a head-to-head comparison.

Benchmarking other models

Drivers ship for three providers — the MCP tool list is provider-neutral, so only the API call differs:

pip install "onem2m-mcp[bench-all]"

ANTHROPIC_API_KEY=... onem2m-mcp-bench --agent claude --model claude-sonnet-5
OPENAI_API_KEY=...    onem2m-mcp-bench --agent openai --model gpt-5
GEMINI_API_KEY=...    onem2m-mcp-bench --agent gemini --model gemini-3.5-flash

Status of each driver: the claude driver is exercised (result above); the gemini driver is exercised against Google AI Studio; the openai driver is written but has not yet been run against the live API — no key was available. Free tiers rate-limit aggressively, so the runner backs off and retries on 429 rather than scoring quota exhaustion as a failed task.

Add --json results.json for full per-task transcripts. Contributions of results for other models are welcome — the interesting question is not who wins, but whether models honestly report access-control denials rather than claiming success.

Performance

Both paths measured in one session against a freshly reset database, so the comparison is like-for-like: 4-core Intel Xeon 8269CY, CSE and client co-located, ACME 2026.05.1 on Python 3.14.6, 300 requests per cell, logging off, zero errors in every cell (benchmark.py, benchmark_mcp.py; raw data in bench_results.jsonl).

Direct oneM2M HTTP binding:

Through the MCP agent path (Scenario A):

The MCP layer costs 0–2 ms per operation: writes are within noise of the direct binding (3.5 ms vs 3.6 ms), reads cost ~1.9 ms more (3.9 ms vs 2.0 ms). Both paths make exactly one HTTP round trip — the in-CSE plugin injects primitives straight into the request pipeline rather than looping back through the oneM2M HTTP binding — which is why the agent path is not slower for writes.

Measurement note: an earlier run reported ~2 ms of overhead on writes. Those figures came from a different session (Python 3.12, and a database that had accumulated 430 resources from a day of testing, which alone cut discovery throughput from 241 to 49 req/s). The table above supersedes them. If you reproduce these, reset the database first — resource count dominates discovery performance.

Security model

• The agent is a oneM2M security principal like any other — no parallel authorization model. Each agent maps to a oneM2M originator; every primitive is authorized by the CSE's <accessControlPolicy> evaluation (TS-0003).
• Least privilege by default: at startup the plugin auto-provisions a dedicated agent identity — an <AE> workspace (cse-in/mcpAgent, originator CmcpAgent) plus an <accessControlPolicy> (acpMCPAgent). The agent fully controls its own subtree and nothing else: writes outside it are denied by the CSE with 4103 ORIGINATOR_HAS_NO_PRIVILEGE (demo step 7 and test_security.py prove this). Admin access is never used for tool calls; set ACME_MCP_ORIGINATOR to use a custom identity with your own ACPs.
• TLS and OAuth 2.1 at the MCP layer: HTTPS via ACME_MCP_TLS_CERT/_KEY; authentication via a static bearer token (labs) or full OAuth 2.1 resource-server JWT validation against your authorization server's JWKS (issuer + RFC 8707 audience checks), with RFC 9728 metadata for client discovery. test_tls_auth.py verifies 401-on-missing/wrong-token and success-with-token. Without any auth configured the endpoint stays open and binds to localhost only.
• Per-session originator mapping (multi-agent isolation): each authenticated identity (OAuth client_id/sub, or a token from ACME_MCP_AUTH_TOKENS) maps to its own oneM2M originator — explicit via ACME_MCP_ORIGINATOR_MAP or derived (agent-a → Cagenta) — and gets its own auto-provisioned <AE> workspace + <ACP> on first use. Agents are isolated from each other by the CSE itself: agent B reading or writing agent A's workspace gets 4103 (test_multi_agent.py proves all six cases). The agent_identity tool tells each agent its originator and workspace.

Documentation

• docs/oneM2M-AI-Agent-MCP-Proposal.docx — 2-page proposal for the oneM2M community: what, why, and how to engage.
• docs/AI-Agent-Interworking-Implementation-Study.docx — full implementation study structured along TR-0081 V0.2.0 (architecture scenarios, security procedure, evaluation), with editable native-shape diagrams.

Roadmap

• TLS + OAuth 2.1 / bearer authentication at the MCP layer
• Scenario B: standalone MCP gateway (AE/IPE over Mca) for any CSE — Mobius, OM2M, tinyIoT
• Bridge oneM2M <subscription> notifications → MCP (queue + push events)
• Per-session originator mapping (OAuth identity → oneM2M originator) with per-agent workspace isolation
• Semantic tools (<semanticDescriptor> + SPARQL semantic discovery)
• LLM-agent benchmark over discovery, ACP-restricted access, subscriptions and semantics (agentbench/)
• Packaged for PyPI as onem2m-mcp (wheel + sdist, three console entry points), published via Trusted Publishing (see RELEASING.md)
• Published first benchmark result (Claude Sonnet 5: 6/6) — more models welcome

Verified environment

Everything documented here was exercised on this exact stack — versions are what is actually installed and run, not aspirational floors:

Protocol/serialization actually exercised: oneM2M Release 4 primitives (rvi=4) over the HTTP binding, JSON, with the MCP streamable-HTTP transport. CoAP, MQTT and WebSocket bindings exist in ACME but are disabled in the demo config.

References

• oneM2M WI-0122 "oneM2M and Model Context Protocol" (v0.0.1, 2025-06-25; rapporteurs I. Friese and A. Neubacher, Deutsche Telekom): https://specifications.onem2m.org/wi/wi-0122/latest/
• oneM2M TR-0081 "AI Agent Interworking" V0.2.0 (2026-06-05): https://specifications.onem2m.org/tr/tr-0081/latest/
• Release 6 work programme (lists both): https://www.onem2m.org/technical/published-specifications/release-6
• I. Friese (Deutsche Telekom), "Early experiments combining Agentic AI, MCP, and oneM2M" (Sept 2025): https://www.onem2m.org/iot-news/968-ingo-friese-ai-mcp
• I. Friese, MCP_oneM2M_example — single-tool MCP demo over an ACME CSE (March 2026): https://github.com/ingofriese/MCP_oneM2M_example
• ACME oneM2M CSE: https://github.com/ankraft/ACME-oneM2M-CSE

Related agent benchmarks: SimuHome (Matter), HomeBench, SmartBench, IoT-MCP Bench.

License

BSD 3-Clause, same as the ACME CSE.