The Model Context Protocol (MCP) provides a common interface through which AI applications discover and use external resources and tools. It allows language-model agents to ground their reasoning in current system state and interact with heterogeneous services. In medical environments, however, exposing device state and action affordances requires deterministic constraints on possible effects. We present an IEEE 11073 Service-Oriented Device Connectivity (SDC)-to-MCP gateway that exposes metrics, alarms, context references, and semantic metadata as read-only resources, while representing selected action affordances as policy-validated dry-run tools. The term safety-bounded denotes a narrow no-execution property: agent-facing requests dispatch no SDC device operation. A Python prototype supports simulated fault and lifecycle experiments, a software-reference protocol path spanning independent Java and Python implementations, deterministic baselines, representation ablations, and multi-model agent evaluation. The results show semantically explicit resource exposure, visible rejection of invalid or outdated state, and preservation of the no-execution boundary across resource, proposal, and authorization paths. Explicit semantic metadata improved conformity to required metric identifiers in structured alarm outputs relative to a generic representation, while retained structured-output failures reveal a distinction between plausible narrative answers and task-compliant machine-readable results.
Figures & tables
Approach
Intended/temporal semantics
Agent interface
Write authority/boundary
FHIR/EHR
Longitudinal record/workflow
Patient-data APIs
Separate from device operations
Direct SDC
Current MDIB/device state
Application-specific
SDC roles/local logic
Generic MCP
Application-defined context
Generic resources/tools
Server-specific
SDC-MCP+MIE
Current state+semantics
Read-only/proposals
No-execution boundary
Table 1: Conceptual positioning (not a performance ranking).
Figure 1: SDC-to-MCP gateway architecture and intended extension points. The evaluated prototype exposes read-only MCP resources and policy-checked dry-run tools; proposals and approvals do not execute device operations. Green write-path arrows and the “future/controlled” tool label denote prospective functionality only. The infusion pump is an illustrative extension, not an evaluated provider.
Actor
Responsibility; excluded authority
Agent
Interpret context/propose; no clinical or device authority
MCP host/client
Launch/constrain subprocess and protect credentials; no policy bypass
Gateway
Map, validate, redact, audit, and enforce no execution
SDC provider
Supply identity/state; authenticity not established by EPR alone
Table 2: Responsibility and accountability boundary.
SDC/BICEPS-side construct
MCP representation
Role
Device/component descriptor
sdc://devices
Inventory
Metric descriptor/state
sdc://devices/ {id}/metrics
Measurements
Alert condition/state
sdc://devices/ {id}/alarms
Alarm status
Context state
sdc://devices/ {id}/context
References
Normalized state view
sdc://devices/ {id}/mdib/raw
Trace/debug
Codes, handles, units, policies
sdc://mapping
SDC-MIE metadata
Table 3: Conceptual SDC-to-MCP mapping.
Stage
Selected content and role
Normalized source
Device holdout-monitor-a ; handle metric.hr ; code 150456 ; value 148; unit beats/min . Alarm alarm.hr.high refers to this handle, is present, and has medium priority.
sdc://devices/holdout-monitor-a/metrics carries the mapped measurement; the corresponding /alarms resource carries alarm state and its metric reference. Payloads include mapping version and source-file hash.
Agent context
A joined active-alarm record identifies the same device, heart_rate , value 148, unit beats/min , and medium priority. The ventilator alarm remains a separate record.
Observed response
The enriched-context model returned active_alarm=true , the monitor’s heart_rate alarm with medium priority, and the ventilator’s airway_pressure alarm with high priority. The frozen alarm-detection grader passed this response.
Table 4: Trace of one synthetic monitor metric through the evaluated interface. Fields are selected for explanation, not a complete protocol message. The final row summarizes an archived GPT-4.1-mini response, repetition 1.
RQ
Evidence
Tested outcome
Boundary
1
Functional scenarios; Python and Java software providers
Clean code commit 7b269c0 ; model and protocol artifacts reused and hash-linked
Table 8: Recorded experimental provenance and replication units. Dates are in 2026. Reused reports are not additional model observations; snapshot reads are not independent devices.
Provider/consumer path
Snapshots
MCP reads
Coverage and setting
Python/Python, three profiles
15/15
120/120
7/11 metrics mapped; separate Linux containers
SDCri Java/Python
5/5
40/40
0/11 generic codes mapped; loopback
Table 9: Software-reference protocol results. Mapping counts refer to exposed metric coverage, not multiplied repetition counts.
Model or representation
Passed
Rate (%)
Mean call (s)
A. Enriched resources: 28 task–scenario pairs, three repetitions
Gemini 2.5 Flash
84/84
100.0
5.01
Hosted Gemma 4 26B
84/84
100.0
1.16
Hosted Qwen 3.6 27B
84/84
100.0
13.62
GPT-4.1 mini
81/84
96.4
2.14
GPT-OSS 20B
81/84
96.4
3.14
Table 10: Descriptive model and representation results. Repeated cases are not independent task samples. Mean hosted-call times include service conditions.
Case
Expected
Archived output
Frozen decision
A: GPT-OSS summary, enriched context
No active alarm; active_alarm=false
“No active alarms are present on either device.” Yet active_alarm=true .
Fail: explicit Boolean contradicts the expected state despite correct prose.
B: GPT-4.1 mini, alarm detection
Monitor metric heart_rate , medium priority, active
Generic: High Heart Rate . Enriched: heart_rate . Both identify the correct device, priority, and active state.
Generic fails only the metric-name check; enriched passes.
B: GPT-4.1 mini, simultaneous alarm set
Monitor heart_rate and ventilator airway_pressure , with their priorities
Generic fails exact set matching; enriched passes. Device and priority associations are retained in both.
Table 11: Expected answers, archived outputs, and unchanged grader decisions. Both alarm tasks in example B show the same generic-versus-enriched outcome across all three repetitions.
Large language models are increasingly used as orchestrators of external tools via the Model Context Protocol (MCP), but MCP is built for software services with megabytes of memory and does not descend to the microcontrollers that dominate the long tail of physical devices. Recent work (IoT-MCP) ports MCP to edge gateways at 74 KB peak memory; this still excludes the smallest commodity MCUs and, critically, does not address the safety problem of giving an unreliable caller (an LLM that may hallucinate or be prompt-injected) direct control of physical hardware. We present the Device Context Protocol (DCP): a sub-50-byte typical frame (6-byte header + CBOR payload + optional 16-byte HMAC), a manifest schema in which capability scoping, range and type checks, dry-run evaluation, and units-as-types are protocol-layer primitives, and a host-side Bridge that rejects malformed or hallucinated calls before any byte reaches the device. Reference firmware measures 27.6 KB flash / 0.6 KB RAM on ESP32; the Python Bridge, ESP32 firmware, and a language-neutral conformance suite are MIT-licensed and public. An empirical study -- 675 tool calls produced by five LLMs across four vendors (DeepSeek, Alibaba, Zhipu, MiniMax) against six categories of adversarial prompts, with the injection category instantiating AgentDojo's attack templates -- shows DCP rejects 100% of capability-escalation attempts and 78% of prompt-injection attempts, versus 0--1% for Raw MCP and IoT-MCP, matching the expressiveness of a well-formed OpenAPI 3 schema at three orders of magnitude less firmware footprint. We position DCP as the missing layer between MCP (which is moving toward enterprise SaaS connectivity) and the physical devices it does not reach.
The Model Context Protocol (MCP) standardizes how AI agents discover and invoke external tools, with over 10,000 active servers and 97 million monthly SDK downloads as of early 2026. Yet MCP does not yet standardize how agents safely operate those tools at production scale. Three protocol-level primitives remain missing: identity propagation, adaptive tool budgeting, and structured error semantics. This paper identifies these gaps through field lessons from an enterprise deployment of an AI agent platform integrated with a major cloud provider's MCP servers (client name redacted). We propose three mechanisms to fill them: (1) the Context-Aware Broker Protocol (CABP), which extends JSON-RPC with identity-scoped request routing via a six-stage broker pipeline; (2) Adaptive Timeout Budget Allocation (ATBA), which frames sequential tool invocation as a budget allocation problem over heterogeneous latency distributions; and (3) the Structured Error Recovery Framework (SERF), which provides machine-readable failure semantics that enable deterministic agent self-correction. We organize production failure modes into five design dimensions (server contracts, user context, timeouts, errors, and observability), document concrete failure vignettes, and present a production readiness checklist. All three algorithms are formalized as testable hypotheses with reproducible experimental methodology. Field observations demonstrate that while MCP provides a solid protocol foundation, reliable agent tool integration requires infrastructure-level mechanisms that the specification does not yet address.
AI agents increasingly call external tools (file system, network, APIs) through the Model Context Protocol (MCP). These tool calls are the agent's syscalls: privileged operations with side effects on shared state, yet today's safety enforcement lives entirely in userspace, where a 10-line script can bypass it. I propose Governed MCP, a kernel-resident tool governance gateway built on a logit-based safety primitive (ProbeLogits). The gateway interposes on every MCP tool call in a 6-layer pipeline: schema validation, trust tier, rate limit, adversarial pre-filter, a ProbeLogits semantic gate (the load-bearing check), and constitutional policy match, with a Blake3-hashed audit chain. I implement Governed MCP in Anima OS, a bare-metal x86-64 kernel in ~286,000 lines of Rust. The five non-inference layers plus the audit append cost a measured 11.3 us per call; the ProbeLogits gate (one probe-prompt prefill plus a single logit read) costs 332-556 ms per classification across Qwen2.5-7B, Llama-3-8B, and Mistral-7B, 2.4-3.4x faster than a Llama Guard 3 pass on the same hardware. A silicon-measured ablation shows that removing the ProbeLogits layer collapses F1 from 0.789 to 0.357 (delta-F1 = -0.432): hand-rule firewalling alone is insufficient. Every WASM-to-system host function and every registered MCP tool is mediated by the kernel gateway, so the 10-line userspace bypass that defeats existing guardrail libraries is structurally impossible; a disclosed set of ring-3 syscall paths remains ungated pending future work. Multi-model validation across three architectures (HarmBench 98-99% non-copyright block, XSTest 98.5-100% unsafe recall, ToxicChat parity with Llama Guard 3) shows the underlying primitive is architecture-agnostic. Governed MCP demonstrates that tool-call governance is feasible as an OS primitive, not just an application-layer concern.