phys-MCP: A Control Plane for Heterogeneous Physical Neural Networks Stefan Fischer∗ , Maliheh Hariri† , and Sebastian Otte‡ ∗ University of Luebeck, Institute of Telematics, Email: [email protected] † University of Luebeck, Institute of Telematics, Email: [email protected]
arXiv:2605.04256v1 [cs.DC] 5 May 2026
† University of Luebeck, Institute of Robotics and Cognitive Systems, Email: [email protected]
Abstract—Physical neural networks (PNNs) promise new operating regimes for AI by embedding computation directly into material dynamics, including molecular, chemical, biological, photonic, memristive, and mechanical substrates. They are particularly attractive for edge computing, especially at the extreme edge, where computation can be placed directly at the interface to sensing, actuation, or the physical process itself. However, such systems remain difficult to integrate into broader edgecloud software stacks because each substrate exposes distinct interfaces, timing characteristics, observability limits, and lifecycle requirements. This paper argues that the missing systems component is a common control plane for heterogeneous PNNs in edge computing and distributed AI settings. We present PHYS -MCP, a substrate-aware orchestration architecture that exposes physical neural substrates as discoverable and invocable resources for edge, fog, and cloud workflows while preserving the fact that the substrates themselves may reside at the extreme edge. PHYS -MCP defines a uniform capability model, lifecycle semantics, telemetry interfaces, and digital-twin bindings while preserving substrate-specific properties such as latency regime, resetability, plasticity, and I/O modality. We instantiate the architecture through a reference prototype with three representative backend classes, an HTTP-backed externalized execution path, and an integrated Cortical Labs adapter that exposes a real wetware-facing API path through the same control model. The evaluation combines controlled experiments on representative backends with a compact end-to-end validation of the Cortical Labs path. Results show descriptor-portable integration across heterogeneous backends, improved runtime-aware matching over simpler baselines, telemetry-aware recovery under representative faults, successful execution against the API-backed wetware path, and small local control-path overhead for the core backends. These results provide prototype-level evidence that substrateaware control can span heterogeneous physical AI resources, representative twin-backed backends, and a real wetware-facing API path.
I. I NTRODUCTION Physical neural networks (PNNs) perform neural computation directly in physical substrates rather than only through numerical simulation on conventional digital hardware. Recent work has shown that this design space is materially diverse, ranging from DNA and chemical reaction systems to living neural tissue, memristive devices, photonic circuits, and mechanical or fluidic architectures [1]. For edge systems, this heterogeneity is not incidental: it determines where computation can be placed and which physical constraints can be exploited. In particular, many PNNs naturally occupy what we call the extreme edge: the physically immediate interface
to sensing, actuation, or the material process itself. Different substrates can place computation directly at that boundary, exploit domain-native physics, and operate under latency, energy, bandwidth, or environmental constraints for which conventional digital accelerators are often a poor fit. PNNs are therefore not merely alternative AI hardware; they are potential extreme-edge computational resources whose value depends on locality, timing, and deployment context. The same diversity also makes PNNs difficult to integrate into conventional software stacks. A PNN is not just another backend for tensor execution, but a physical resource with its own I/O modality, timing behavior, calibration requirements, and observability constraints. Some substrates can be programmed repeatedly, others must be configured more cautiously; some can be reset quickly, others drift, degrade, or require substantial re-initialization. Using a PNN in practice is therefore not only a question of how to execute inference, but also of how software can understand and manage the operational constraints of the underlying substrate. This becomes a systems issue as soon as such extremeedge resources must be integrated into broader edge, fog, and cloud hierarchies rather than treated as isolated laboratory demonstrations. A PNN-aware application therefore needs more than an inference endpoint. It must determine which substrates are available, whether their modality and time scale fit the task, whether their current state is still valid, and whether they can be reused immediately or first need calibration, reset, or synchronization with a digital twin. What is missing is therefore not another model format or backend API, but a control-layer abstraction that exposes the operational semantics of physical substrates to software-level resource management in edge-cloud computing systems. Existing interfaces cover only parts of this problem. The Neuromorphic Intermediate Representation (NIR), for example, supports model portability across neuromorphic toolchains, but not orchestration across materially different physical substrates with explicit lifecycle and telemetry semantics [2]. The Model Context Protocol (MCP), in contrast, standardizes how tools and resources can be described, discovered, and invoked through machine-readable interfaces [3]. This interaction style is attractive for physical AI systems because heterogeneous resources should be discoverable and callable through a common software interface. However, plain MCP does not yet capture the properties that matter for PNN
This work has been submitted to the IEEE for possible publication. Copyright may be transferred without notice, after which this version may no longer be accessible.
deployment, such as modality constraints, timing contracts, resetability, calibration state, or observability limits. We therefore argue that heterogeneous PNNs require a substrate-aware control plane. Its purpose is not to hide substrate differences behind a lowest-common-denominator interface. On the contrary, these differences must remain explicit, because they determine whether a given physical system is suitable for a task and under which conditions it can be operated safely and effectively. A useful control plane must let software discover substrate capabilities, match tasks to suitable backends, invoke computations, monitor runtime state, and keep digital twins in sync with physical execution. This is the point at which MCP becomes useful, but only after extension: we use its discovery-and-invocation model as a foundation and extend it toward the semantics of physical computing. This paper introduces PHYS -MCP, a control-plane architecture for exposing heterogeneous PNNs as discoverable, invocable, and supervisable computational resources. PHYS -MCP preserves the general MCP style of structured discovery and invocation, but augments it with explicit capability descriptions, lifecycle and timing semantics, telemetry channels, and digital-twin bindings. It also separates control-plane reasoning from twin-plane synchronization and substrate-specific dataplane execution. In our setting, the substrates themselves may reside at the extreme edge, while the control plane can be placed at the edge, fog, or cloud depending on deployment constraints. The goal is not to replace substrate-specific runtimes, compilers, or laboratory interfaces, but to provide a common orchestration layer above them so that conventional software systems can use physical backends without ignoring their material differences. Our focus here is not a broad performance study of mature physical substrates or distributed deployments, but a first reference architecture and prototype-level validation of the control abstractions needed to integrate heterogeneous, lifecyclesensitive, and only partially accessible PNN resources. Our main contributions are as follows: We identify the core systems obstacle in integrating heterogeneous PNNs into edge computing and distributed AI workflows: not inference execution itself, but the absence of a control-plane abstraction that exposes substratespecific operational constraints to software. • We present the PHYS -MCP architecture, which separates control-plane, twin-plane, and data-plane concerns and defines how heterogeneous PNN resources are discovered, invoked, monitored, and managed across their lifecycle in edge–fog–cloud settings, including cases in which the substrates themselves reside at the extreme edge. • We define a substrate-aware capability model that captures signal modality, timing regime, resetability, observability, programmability, and training mode instead of hiding physical backends behind a generic accelerator abstraction. •
We implement a reference prototype with representative twin-backed backends, an externalized execution path, and a real wetware-facing integration target, and we use it for controlled prototype-level validation of descriptor portability, runtime-aware matching, fault handling, and control-path cost. The rest of this paper is structured as follows. Section II reviews the relevant background and sharpens the architectural gap. Section III derives the requirements for a PNN control plane. Section IV presents the PHYS -MCP architecture, followed by the capability model in Section V and representative substrate bindings in Section VI. Section VII describes the prototype and experimental setup, Section VIII reports the evaluation, Section IX discusses related work, and Section X concludes the paper. •
II. BACKGROUND AND P ROBLEM S TATEMENT A. PNNs as Heterogeneous Physical AI Substrates PNNs do not form a single hardware class. Rather, they comprise a broad set of computational substrates based on very different physical mechanisms. Recent survey work places under this umbrella DNA strand-displacement systems, reaction–diffusion media, living neural tissue, memristive and ferroelectric in-memory devices, photonic circuits, and mechanical, microfluidic, or iontronic architectures [1]. Across these substrates, familiar neural functions such as weighted propagation, nonlinearity, memory, and adaptation are realized through different carriers, state variables, and engineering constraints. This diversity is central to the appeal of PNNs for embedded AI. Depending on the substrate, computation can be placed close to sensing, coupled tightly to the underlying physics of the application domain, or carried out under latency, energy, bandwidth, or environmental constraints for which conventional accelerators are a poor fit. Many of the most compelling deployment scenarios, therefore, place PNNs at the extreme edge, i.e., at the physically immediate boundary to the sensed or influenced process. The potential of PNNs lies largely in substrate diversity rather than in uniformity. At the same time, this diversity makes integration difficult. A PNN is a physical resource with its own I/O modality, timing behavior, calibration requirements, reset conditions, and observability limits. A photonic substrate, a DNA-based circuit, and a wetware system may all implement neural computation, but they differ substantially in how they are configured, when their outputs can be trusted, how drift appears, and what a supervising software stack can realistically observe or control. Once such substrates are treated as deployable resources in edge, fog, and cloud hierarchies rather than as isolated laboratory demonstrations, these differences become a systems concern. B. MCP as a Baseline Discovery and Invocation Model One useful reference point for this systems concern is the Model Context Protocol (MCP). At a high level, MCP defines a standardized way to describe external capabilities
in machine-readable form and to make them discoverable and invocable by AI systems [3]. Its contribution is therefore not a model representation, compiler, or runtime. Instead, it provides a common interaction structure for exposing resources and tools to software. This abstraction matches how many current AI systems are assembled. Many systems are no longer built as monolithic applications, but as orchestrated workflows in which an agent or supervisory component inspects available capabilities at runtime, selects a suitable external resource, and integrates the returned result into a larger reasoning loop. In that setting, explicit and machine-readable resource descriptions are preferable to hidden, application-specific integrations. For PNN integration, MCP is relevant because it already captures two properties that are also needed here. First, heterogeneous resources should be discoverable rather than hardcoded. Second, invocation should proceed through a uniform software-visible interface rather than through ad hoc glue logic. For physical AI systems, these two properties cover the software-facing part of integration but not the substrate-facing one. However, MCP does not by itself express the physical semantics that determine whether a substrate is actually usable for a given task. C. Why Existing Interfaces Still Leave an Integration Gap The limitation becomes visible when MCP is compared with existing PNN-facing interfaces and deployment tools. Intermediate representations and mapping toolchains such as NIR and EdgeMap improve portability across neuromorphic models and backends [2], [4]. This is valuable for model exchange and backend interoperability, but it does not answer operational questions such as whether a substrate can be reset quickly, how long it takes to reach a valid operating state, which telemetry is available during execution, or how recalibration affects the validity of the result. An intermediate representation captures computational structure, but not the full operational view of a physical resource. Substrate-specific stacks address other parts of the problem. BioCRNpyler supports structured compilation for chemical systems, while DishBrain and the Neuroplatform show how wetware substrates can be accessed in closed-loop or remote experimental settings [5], [6], [7]. They solve essential substrate-specific problems, but their assumptions remain local to the substrate family they target. Their assumptions about signals, timing, controllability, and observability are embedded in the interface itself. A concentration-driven DNA workflow, a spike-based organoid experiment, and a conductanceprogrammed crossbar differ in signals, lifecycle, state validity, and in the degree to which their behavior can be tracked by a digital twin [1], [8]. MCP addresses yet another layer. It supports discovery and invocation, but plain MCP does not define how to express modality constraints, timing contracts, reset semantics, calibration confidence, or twin validity for physical substrates [3]. It standardizes how software can communicate with an external
resource, but not what software must know in order to operate a materially embodied computational system correctly. From the viewpoint of an embedded or distributed application, a PNN-facing interface must expose at least the following information: which signals a substrate can consume and produce, under which latency regime it operates, whether it must be initialized or recalibrated, whether it can be reset or only replaced, how far it remains programmable at runtime, and which telemetry is available to detect drift or loss of validity. Existing interfaces usually expose only part of this picture, and usually only within one substrate family. Conventional software stacks, therefore, still lack a proper control-plane abstraction for heterogeneous PNNs. What is needed is an orchestration layer that keeps substrate differences explicit and makes them usable for software-level discovery, matching, invocation, supervision, and digital-twin coupling. This is the design space in which we position PHYS MCP. III. D ESIGN R EQUIREMENTS FOR A PNN C ONTROL P LANE The gap identified above is a systems problem: heterogeneous PNN substrates can only be used reliably if their relevant physical and operational properties are exposed at the control-plane level. From the viewpoint of an orchestrator or supervisory application, the control plane must therefore support discovery, selection, invocation, monitoring, and lifecycle management in a substrate-aware manner. R1: Capability discovery and task-to-substrate matching. A PNN resource must be discoverable by more than endpoint presence. Software needs machine-readable information about which computational functions a substrate supports, under which input/output modalities, and under which operational conditions. This information must also support principled taskto-substrate matching: an orchestrator should be able to decide which substrate fits which task under constraints such as modality, latency, energy, autonomy, or lifecycle cost. Without such structured descriptors, placement remains ad hoc. R2: Typed multi-physics I/O descriptions. Many PNNs do not simply consume and produce tensors. Their interfaces may involve molecular concentrations, spike trains, optical intensities, conductance states, or mechanical excitation patterns. The control plane must therefore describe I/O in typed, substrateaware terms, including carrier, encoding, admissible ranges, sampling assumptions, and required transduction steps. R3: Time and synchronization semantics. Timing is intrinsic to PNN behavior. Substrates differ widely in latency, observation windows, settling behavior, and freshness constraints. A usable control plane must expose these semantics explicitly so that orchestration and digital-twin coupling can judge whether results are still valid for the task at hand. R4: Lifecycle and reset control. Many substrates are not always-ready resources. They may require warm-up, priming, flushing, calibration, thermal cycling, or replacement, while others support rapid reset or near-continuous reconfiguration. The control plane must therefore represent lifecycle states
explicitly, rather than collapsing them into a simple notion of availability. R5: Telemetry and digital-twin coupling. A physical substrate requires more observability than a final output alone. The control plane should expose telemetry for supervision, debugging, recalibration, and failure analysis, while also providing clear bindings to digital twins. Relevant metadata includes calibration timestamps, divergence indicators, and estimates of twin validity. R6: Training- and programmability-aware operation. PNNs differ substantially in configurability. Some are fixed after ex-situ training, others allow limited retuning, hybrid update procedures, or in-materio adaptation. The control plane must make these distinctions explicit, since they affect deployment, rollback, validation, reproducibility, and update handling. R7: Safety, isolation, and tenancy constraints. Physical substrates may be fragile, hazardous, biologically sensitive, expensive, or shared. The control plane must therefore support policies for concurrent access, admissible stimulation ranges, cooldown periods, hygiene or biosafety constraints, and authorization. A shared PNN cannot be exposed as an unconstrained stateless service. Overall, a PNN control plane must provide more than transport-level interoperability. Its role is not to hide substrate differences, but to expose them in a structured form that software can use for discovery, selection, invocation, supervision, and lifecycle management. The next section presents the PHYS -MCP architecture built around this idea. IV. T HE PHYS -MCP A RCHITECTURE Figure 1 places PHYS -MCP within the overall system stack and shows its role as the substrate-aware interface between conventional digital AI/IT components and heterogeneous physical neural substrates, many of which may naturally reside at the extreme edge. At this level, PHYS -MCP appears as the software layer through which edge, fog, or cloud systems discover available substrate capabilities, submit execution requests, receive runtime information, and exchange state with digital-twin services. This view clarifies the architectural role of PHYS -MCP: it is not a substrate-specific runtime, but an orchestration layer between software-level intent and materially embodied computation. We now move from this external placement view to the internal organization of PHYS -MCP. We do not treat PHYS MCP as a single middleware block, but instead decompose it into three coordinated planes that separate orchestration, twinstate management, and substrate access. Figure 2 summarizes this internal structure and the main control, telemetry, and feedback paths across it. A. Control Plane, Twin Plane, and Data Plane The main architectural decision in PHYS -MCP is to separate software-facing control logic from substrate-facing execution and from the management of twin-visible runtime state. This yields a three-plane design. The Control Plane handles software-level decisions and session coordination. The Twin
Fig. 1. High-level system architecture of phys-MCP.
Plane maintains synchronized, validity-aware state associated with the substrate. The Data Plane performs the actual interaction with physical or emulated backends. This split keeps responsibilities clear without isolating the planes from one another: invocation decisions depend on twin state, twin state depends on telemetry, and lifecycle actions ultimately affect substrate access. Control plane. The control plane is the entry point for applications, orchestrators, and supervisory agents. It handles discovery, capability negotiation, policy enforcement, invocation, and lifecycle management. When a request is capabilitydriven, the control plane selects a suitable substrate from the available candidates. When a client already addresses a specific backend, the same plane validates feasibility, policy, interface, and readiness constraints for that target. In both cases, the control plane does not execute physical computation itself; it prepares, authorizes, and supervises the corresponding session. Twin plane. The twin plane maintains the digital representation associated with a substrate. Depending on the backend, this may take the form of a high-fidelity simulator, a reduced behavioral model, a calibration record, or only a besteffort validity estimate. The twin plane tracks synchronization metadata, confidence, and drift-related status. This separation matters because the twin is not the substrate itself. Its value depends on how current it is, how well it matches observed behavior, and whether the surrounding software can still rely on it for scheduling or control decisions. Data plane. The data plane comprises the substrate-specific execution path. It includes stimulation, actuation, sensing, readout, and low-level telemetry transport between adapters and the physical or emulated backend. This plane is deliberately not uniform across substrates. A chemical backend may use concentration-valued inputs and fluorescence readouts, whereas a wetware backend may exchange stimulation patterns and spike recordings. PHYS -MCP does not hide these differences. It makes them accessible through software-visible descriptors and contracts so that higher-level systems can
Fig. 2. Internal PHYS -MCP three-plane architecture. Internal three-plane architecture of phys-MCP. phys-MCP separates control-plane orchestration, twinplane state and validity management, and data-plane substrate access. The control plane handles capability discovery, task-to-substrate matching, invocation, lifecycle control, and policy enforcement. The twin plane aggregates telemetry from substrate adapters, maintains synchronized substrate state, and estimates calibration validity and drift. The data plane contains substrate-specific adapters that execute physical I/O and readout for heterogeneous PNN backends.
reason about them. The result is a control structure in which orchestration remains software-visible, twin maintenance remains explicit, and physical execution remains substrate-specific. This is the layer that is missing in conventional software stacks when materially diverse PNNs have to be integrated into a larger system. B. Core Components Figure 2 sketches the main building blocks. In the architecture proposed here, the control and twin planes are realized through the following core services. Capability registry. The registry stores descriptors for known PNN resources and their exposed capabilities. These descriptors support discovery queries such as “find a substrate that accepts spike-like event input and supports low-latency repeated invocation” or “find a substrate that supports insample molecular processing under slow assay semantics.” Task-to-substrate matcher. Based on resource descriptors and current operating state, this component ranks candidate substrates when a request does not yet specify a concrete backend. It is the point at which capability compatibility, timing constraints, deployment locality, lifecycle cost, and twin state become operational selection criteria. If a client already targets a known substrate, the role of this component reduces to compatibility, readiness, and admission checks rather than open-ended selection. Invocation manager. The invocation manager turns a request into a concrete session. It establishes the relevant execution context, negotiates timing, lifecycle, and telemetry expectations, activates the appropriate adapter, and tracks
whether a request is running, paused, completed, rejected, or invalidated. Lifecycle manager. This component supervises warm-up, priming, calibration, reset, cooldown, recovery, and related transitions. For physical substrates, these state changes are often as important as the compute step itself, especially in slow, fragile, or drift-prone systems. Telemetry handling. PHYS -MCP collects runtime signals that matter for control and supervision. Depending on the substrate, this may include final outputs, intermediate observations, health indicators, calibration state, or drift warnings. These signals are forwarded to local or remote consumers as needed and also provide input to the twin plane. Twin synchronization manager. This manager associates telemetry with the corresponding twin state and updates synchronization metadata. It can flag stale twin state, unexpected behavioral deviation, or situations in which additional measurements are required before the resource should be used again. Policy and safety manager. The policy layer enforces admissible operating regions, authorization, tenant isolation, and substrate-specific safety rules. This becomes essential as soon as PNN resources are shared, fragile, hazardous, or biologically sensitive. C. Task-to-Substrate Matching Matching in PHYS -MCP is optional rather than mandatory. Some requests are capability-driven and leave substrate selection to the control plane. Others explicitly target a known backend, for example, because the physical substrate itself is part of the intended experimental or application design. In the
latter case, the matching stage collapses to feasibility, policy, interface, and readiness checks rather than multi-candidate ranking. When selection is required, the scheduler in PHYS -MCP is intentionally simple at first. It does not solve a universal optimization problem; instead, it scores candidate substrates against the request and the current operating state. A generic selection score can be written as S(t, s) = αC(t, s) + βT (t, s) + γL(t, s) + δD(t, s) − ϵO(s), (1) where t denotes a task and s a substrate. The terms capture different dimensions: C reflects capability compatibility, T timing suitability, L lifecycle cost, D twin confidence and deployment locality, and O orchestration overhead. The weights α to ϵ are policy-dependent. A tightly coupled embedded loop may assign high weight to timing suitability, whereas a bio-integrated assay may place more emphasis on modality compatibility and low transduction cost. Equation 1 is illustrative rather than prescriptive. Its role is to make the selection criteria explicit, so that scheduling depends on exposed substrate properties rather than on endpoint presence alone. A flat endpoint interface would not suffice, because timing, resetability, observability, lifecycle cost, and twin state would remain implicit. D. End-to-End Workflow A typical PHYS -MCP workflow starts in one of two ways. In a capability-driven workflow, a client first discovers suitable resources and then submits a request at the level of desired functionality and constraints. In a directed workflow, the client already names a specific substrate and asks the control plane to validate and invoke it. To make this less abstract, consider a closed-loop wetware experiment against a cultured neuronal network exposed through the public Cortical Labs CL API / CL SDK Simulator [9]. The practical goal is simple but representative: test whether a candidate stimulation pattern elicits a reliable response fingerprint within a short observation window while staying within session-health bounds. In the capability-driven variant, the client discovers wetware resources that expose spike/stimulation I/O and recording telemetry. In the directed variant, it explicitly addresses the Cortical Labs backend. In both cases, the submitted task request states the stimulation pattern or task intent together with constraints such as modality, latency target, required telemetry fields, acceptable twin age, and fallback policy. The task-to-substrate matcher evaluates compatible resources using both static descriptors and dynamic state such as readiness, drift, health, and twin confidence. The control plane then prepares the selected adapter and establishes the corresponding execution, lifecycle, and telemetry context. The return path is equally important. The selected adapter interacts with the underlying backend and receives substratenative output together with runtime metadata from the resource or gateway layer. In the Cortical Labs case, this means mapping stimulation and recording primitives of an existing
wetware-facing API into the normalized PHYS -MCP result format. The adapter enriches the returned payload with telemetry such as response timing, health-related status, and readiness signals, and passes it upward through the control plane. At the same time, relevant observations update the twin plane, so that synchronization state, confidence, and drift information remain current for later decisions. The interaction style remains close to standard MCP usage. A client discovers resources or addresses a known one, submits a structured request through a common interface, receives a normalized response, and can inspect machinereadable auxiliary state. What changes in PHYS -MCP is the semantics of that state: timing, resetability, observability, twin quality, and recovery actions become explicit software-visible concerns rather than remaining hidden inside substrate-specific glue code. This becomes especially visible in the Cortical Labs example, because the same control-plane contract can either drive a wetware-facing external API or fall back to a compatible synthetic wetware backend when the external path is unavailable. We will show a concrete version of this workflow in Section VII-B. V. A S UBSTRATE -AWARE C APABILITY M ODEL A. Resource and Capability Descriptors The capability model in PHYS -MCP distinguishes between two kinds of description. A resource descriptor identifies a concrete substrate instance and its operating context. A capability descriptor states what that resource can do and under which conditions it can be used. The resource descriptor captures relatively stable information such as substrate class, physical location, adapter type, tenancy constraints, and the identifier of the associated twin model. It describes what kind of resource is being exposed and under which operational conditions it exists. The capability descriptor is closer to execution. It records the properties that matter when software has to decide whether and how a resource can be used: signal modality, admissible I/O types, timing regime, programmability, observability, lifecycle affordances, and telemetry availability. These are the computational and operational semantics that the control plane must see. Table I summarizes the descriptor categories used in our initial model. These descriptors are not meant as passive documentation. They are machine-readable inputs to matching, admission control, invocation setup, and supervision. A scheduler may reject a candidate whose descriptor signals assay-style timing when the request expects repeated low-latency invocations. A policy layer may refuse access when exclusivity, safety, or biosafety constraints are incompatible with the request. B. Timing, Lifecycle, and Telemetry Contracts Descriptors alone are not enough, because several important properties depend on the session rather than only on
TABLE I C ORE CATEGORIES IN THE PHYS -MCP CAPABILITY MODEL . Category
Representative fields
Substrate identity
substrate class, adapter type, location, twin binding input/output modality, encoding, admissible ranges, transduction needs latency regime, observation window, freshness expectations, trigger mode warm-up, resetability, calibration need, recovery and cooldown states fixed, configurable, tunable, in-situ adaptive output channels, internal telemetry, drift indicators, twin confidence exclusivity, safety bounds, authorization, concurrency limits
Signal semantics Timing semantics Lifecycle semantics Programmability Observability Policy and tenancy
the resource. PHYS -MCP therefore introduces three explicit contracts that are established at invocation time. Timing contract. This contract states when outputs become meaningful and how they should be interpreted. It includes the expected latency regime, the relevant observation interval, and whether outputs are sampled, streamed, or event-driven. For slowly relaxing systems, it can also specify that observations taken before a minimum stabilization time are not authoritative. Lifecycle contract. This contract specifies which state transitions are required around a session. It covers preparation, priming, calibration, reset, cleanup, and any mandatory recovery phase. For physical substrates, these transitions are often not secondary overhead, but part of the effective execution cost. Telemetry contract. This contract defines which observations are available during and after execution, how they are delivered, and which of them are linked to the twin plane. It separates final outputs from health, calibration, and driftrelated signals, allowing supervisory logic to reason about validity and readiness rather than only about completion. Taken together, these contracts expose assumptions that would otherwise remain hidden in substrate-specific code. This is also where PHYS -MCP moves beyond plain MCP. MCP already defines lifecycle management at the protocol level, capability negotiation during initialization, and standardized ways to expose resources, tools, prompts, and related client/server features [3]. What it does not define is the domain-specific semantics needed for embodied computation: physical reset cost, observability limits, drift-aware readiness, or invocation decisions conditioned on twin validity. In that sense, PHYS -MCP is best understood as an MCP-inspired, domain-specialized control plane for physical AI substrates. VI. R EPRESENTATIVE S UBSTRATE B INDINGS We now move from the abstract capability model to the substrate bindings realized in the reference prototype. Their purpose is not to reproduce the full physics of the corresponding substrate classes. Instead, they are chosen to exercise the control-plane abstractions under clearly different operating
conditions. In particular, they differ in signal modality, timing behavior, lifecycle cost, telemetry richness, and deployment setting. The core bindings are aligned with the classes chosen as examples in Figure 1: DNA/chemical, biological/wetware, and memristive/photonic substrates. In addition, the code base includes an optional wetware-facing adapter for the public Cortical Labs CL API / CL SDK Simulator, which serves as an existing API-backed integration target rather than as one of the quantitatively evaluated core regimes—even though it also belongs to biological/wetware class. A. DNA/Chemical Backend The DNA/chemical backend represents concentration-driven and assay-style computation, including the kind of molecular processing that would arise in DNA-based neural or logicstyle systems. In the prototype, this class is realized as an ODE-based digital twin wrapped by a chemical adapter. The adapter exposes concentration-valued input and output contracts, slow timing semantics, explicit reset modes such as flush and recharge, and telemetry fields including contamination level, convergence time, calibration confidence, and drift score. This backend captures the kind of systems behavior for which PHYS -MCP is particularly useful: slow execution, nontrivial cleanup and recovery, and strong dependence on twin validity. A client does not simply issue an inference request and read back a result. It may first have to prepare the substrate, submit concentration-style task parameters, wait for delayed completion, inspect convergence-related telemetry, and then reset or recalibrate the resource before it can be used again. The DNA/chemical binding therefore provides a direct test case for lifecycle-aware invocation and telemetry-driven supervision. B. Biological/Wetware Backend The biological/wetware backend represents closed-loop stimulation and observation scenarios of the kind encountered in biological neural systems. In the prototype, this class is implemented through a synthetic spike-response twin together with a wetware adapter that exposes spike-oriented input contracts, millisecond-scale timing, viability-sensitive state, and recovery operations such as rest and recalibrate. Its telemetry includes firing-rate summaries, response delay, noise level, viability score, and a drift proxy. Compared with the DNA/chemical backend, the main challenge here is different. The issue is not slow equilibration, but repeated interaction with a state-sensitive resource whose usefulness depends on health and observability. The backend is still discovered and invoked through the same software-facing interface as the other bindings, but the meaning of a valid session changes substantially. Successful operation depends on backend health, closed-loop observation, and lifecycle metadata that would be irrelevant for an ordinary acceleratorstyle abstraction. This is exactly the kind of difference that PHYS -MCP is meant to preserve.
Beyond the synthetic wetware twin used in the controlled quantitative evaluation, the code base also contains an integrated adapter targeting the public Cortical Labs CL API and its CL SDK Simulator [9]. Through the path PHYS -MCP → CorticalLabsAdapter → CLClient → CL SDK / Simulator, the current prototype can discover, select, invoke, and monitor a real wetware-facing runtime through the same control-plane contracts as the other backends. In this paper, we use this path as a compact end-to-end integration case rather than as a broad wetware benchmark. C. Memristive/Photonic Backend The memristive/photonic backend represents comparatively device-like physical AI resources that still benefit from an explicit control plane. This class covers, for example, memristive in-memory substrates and photonic processing elements that may support low-latency repeated execution while still exhibiting calibration drift, reprogramming overhead, or locality constraints. In the current prototype, this class is instantiated as a lightweight vector/tensor-oriented twin with low-latency inference, drift-aware telemetry, and reset or reprogramming semantics. The corresponding adapter exposes digital-vector and tensor-style input contracts, millisecond-scale timing, support for repeated invocation, and telemetry such as drift score, execution latency, and an energy proxy. This binding shows that PHYS -MCP is not only useful for slow or fragile substrates. Even when a backend resembles a conventional edge accelerator, the control plane still adds value by making calibration age, drift, programmability, telemetry, and locality constraints software-visible in a uniform form. In the prototype, this backend also serves as the main vehicle for demonstrating fallback behavior and drift-triggered recovery. D. Comparison of the Implemented Bindings Table II summarizes the three core prototype bindings together with the optional Cortical Labs integration target. The goal is not broad coverage, but contrast: one slow DNA/chemical backend, one state-sensitive biological/wetware backend, and one low-latency memristive/photonic-style backend. The Cortical Labs row is different in purpose: it demonstrates that the same control-plane model can also describe an existing wetware-facing API. The HTTP-backed externalized fast path used later in the evaluation is not a fourth substrate class, but an externalized execution path for the same fast deviceproximate capability profile. Together, these bindings provide a small but deliberately diverse test bed for the proposed controlplane abstractions. Accordingly, the empirical goal of the prototype is not broad substrate benchmarking, but controlled validation that the proposed control-plane abstractions remain stable and useful across deliberately contrasting backend regimes.
TABLE II OVERVIEW OF CORE AND OPTIONAL PROTOTYPE BACKENDS .
Backend
I/O
Timing
Lifecycle
Deploy.
DNA/ Chemical
concentration slow (s) flush, recharge, recalibration
lab
Biological/ Wetware
spikes / stimulation
fast (ms)
rest, recalibration, health-aware use
lab
Memristive/ Photonic
vector/tensor
fast (ms)
reprogram, reset, drift recovery
device/ edge
Cortical LabsCL API (opt.)
spikes/ stimulation
fast (ms)
session reset, rest, recalibration
sim./lab
into edge-oriented software systems. The implementation is intentionally small and mostly single-machine: the goal is to validate the control-plane abstractions and their applicability to the integration of extreme-edge resources into broader software-managed workflows rather than to build a distributed production runtime. First, the task model and matcher combine static descriptors with runtime state. A task can now express a direct backend preference, a maximum admissible twin age, required telemetry fields, and whether human supervision is available. Correspondingly, the matcher consults lightweight runtime snapshots such as health_status, drift_score, and age_of_information_ms in addition to descriptor metadata. Second, the orchestrator validates postconditions after invocation and may reroute to a fallback backend after preparation or invocation failures as well as after telemetry or validity violations. Third, the prototype includes an HTTPbacked externalized fast adapter and service, introducing an explicit software boundary between control plane and backend rather than keeping all execution paths in-process. The implementation, therefore, comprises a typed descriptor layer, a task model, a registry for backend adapters, an explainable matcher, an orchestrator with postcondition-aware fallback logic, telemetry collection, three local twin-backed substrate adapters, one externalized HTTP-backed fast adapter, one integrated adapter targeting the public Cortical Labs CL API / CL SDK Simulator, and lightweight evaluation scripts. The quantitative core of the paper still relies on representative twin-backed regimes for controlled comparison. The Cortical Labs path is exercised end-to-end through the real API-backed runtime. This lets us validate that the same PHYS -MCP control model can drive an external wetware-facing backend, return runtime telemetry, and emit structured recording artifacts without changing the client-visible interaction pattern. B. Concrete Closed-Loop Wetware Workflow and Backend Set
VII. P ROTOTYPE AND E XPERIMENTAL S ETUP A. Reference Prototype We implemented PHYS -MCP as a Python-based reference prototype to integrate heterogeneous physical AI backends
For evaluation, PHYS -MCP operates on a small but heterogeneous set of backends comprising a chemical backend, a synthetic wetware backend, a local fast backend, and an HTTP-backed externalized fast backend. In addition, the pro-
Fig. 3. Concrete closed-loop wetware workflow centered on the Cortical Labs integration target.
totype includes a real API-backed wetware path through the Cortical Labs interface [9]. This makes it possible to discuss the workflow not only in terms of internally defined twins, but also against an existing wetware-facing runtime. Our running example is a closed-loop evoked-response screening task. A researcher wants to test whether a cultured neuronal network responds to a candidate stimulation pattern within a short observation window while preserving explicit control over readiness, health status, and recording support. The request is therefore expressed to PHYS -MCP in substrateaware terms: spike/stimulation I/O, millisecond-scale observation, health-aware execution, and a backend preference for the Cortical Labs path. Depending on the experiment, the same client-visible request may either be directed to that backend explicitly or left to capability-based matching, optionally with fallback to a compatible synthetic wetware backend. Operationally, the workflow proceeds in three stages. First, the client or agent discovers the available resources and submits a structured task to the PHYS -MCP control plane. Second, the control plane validates the request against published backend capabilities, selects the Cortical Labs path, prepares the session through the corresponding adapter, and triggers the stimulation/recording cycle. Third, the backendspecific outcome is normalized into a common control-plane result consisting of execution status, runtime telemetry, and a structured recording artifact descriptor, after which the client receives a stable response contract independent of the concrete backend used. Figure 3 summarizes this interaction pattern as a highlevel sequence. The same control-plane structure can serve both conventional clients and agent-facing ones. In the current prototype, we exercised this boundary with a Geminibased Python client that performs resource discovery through PHYS -MCP, submits a structured request, and summarizes the normalized result in natural language. This client is included as a usage example of the control-plane interface rather than as a core evaluated contribution. A local Ollama-based variant exists as well.
C. Experimental Questions and Setup All experiments were run on a single machine. This is a deliberate design choice: the goal of the evaluation is not to benchmark distributed deployment performance, but to isolate the behavior of the proposed control plane under heterogeneous backend conditions while keeping the underlying execution environment controlled. Accordingly, the local backends are in-process, the externalized fast backend is accessed over HTTP as a separate service on the same machine, and the Cortical Labs path serves as a real API-backed feasibility anchor. The evaluation, therefore, asks three questions about the control layer itself. RQ1: Does PHYS -MCP provide a unified yet substrateaware control abstraction across heterogeneous backends? Here we examine descriptor and invocation portability, the stability of the client-visible API, and the extent to which the same control-plane model covers local backends, an externalized service-backed backend, and an existing wetware-facing API adapter. RQ2: Do runtime-aware matching, postcondition validation, and fallback improve robustness under heterogeneous runtime conditions? Here we compare the full matcher against simpler baselines and run a fault campaign that exercises stale twin state, degraded health, missing supervision, preparation failure, and telemetry loss. RQ3: What is the local control path cost of PHYS-MCP relative to backend execution in the current prototype? Here we measure local orchestration overhead across the three core local backends and the round-trip cost of the externalized backend path. The evaluation scripts write machine-readable JSON and CSV outputs. For local overhead, we compare direct adapter access to orchestrated execution over 25 runs per backend. For portability, we inspect descriptor consistency across five registered backends and invocation consistency across the four executable backend families in the current environment, while separately recording readiness information for the optional Cortical Labs adapter. For selector quality, we evaluate four selectors on a curated suite of seven tasks: a random admissible selector, a modality-only selector, a latency-only selector, and the full PHYS -MCP matcher. For robustness, we execute a five-scenario fault campaign. For the externalized backend path, we measure 15 HTTP-backed invocations. VIII. E VALUATION A. RQ1: Unified Yet Substrate-Aware Abstraction Table III first positions PHYS -MCP analytically against adjacent mechanisms. The comparison is deliberately coarsegrained: it is not a protocol-conformance claim, but a compact summary of which systems concerns are explicitly represented at the control-plane level. The table shows why a substrateaware control plane is needed in addition to plain MCP, WoT, NIR, or substrate-specific experiment APIs. The prototype results are consistent with this architectural claim. Across all five registered backends—chemical, synthetic
TABLE III C OMPARISON OF CONTROL - PLANE CONCERNS COVERED BY ADJACENT APPROACHES .
Approach
Dis.1 Inv.2
I/O Time Lc.3 Tel.4 Twin5 S/R6
Plain MCP W3C WoT NIR / mapping Substrate APIs PHYS -MCP
yes yes part. no yes no no no yes yes part. part. no part. no no no part. part. no no no no no part. yes yes part. part. part. part. part. yes yes yes yes yes yes yes yes
1 Discovery, 2 Invocation, 3 Lifecycle, 4 Telemetry, 5 Digital twin coupling, 6 Selection/Recommendation
wetware, local fast, externalized fast, and the Cortical Labs adapter—the descriptor shared-key ratio is 1.0, indicating that the same top-level descriptor structure is reused even when one backend targets an existing external API rather than an internal twin. Across the four executable backends in the present environment, the invocation shared-key ratio is likewise 1.0. Backend-specific task metadata remains small but non-zero: one metadata key for the chemical, local fast, and externalized fast runs, and two for the wetware run. This is the intended behavior. PHYS -MCP keeps the client-visible control structure stable while still allowing semantically different modalities and payloads. The externalized fast backend preserves this interaction style across a real software boundary. It is reached through the same orchestrator entry point and returns the same normalized result keys as the local backends, but it does so through an HTTPbacked adapter and service. The Cortical Labs adapter is exercised end to end through a real API-backed runtime path and returns normalized execution results through the same controlplane contracts. In other words, the prototype demonstrates a single control-plane model spanning local twins, a servicebacked externalized backend, and a real wetware-facing APIbacked backend. A compact runtime validation strengthens this point beyond descriptor publication and nominal API compatibility. Across three directed screening runs, PHYS -MCP selected the cortical-labs-backend, completed execution successfully without fallback, exposed readiness and health state before and after execution, and returned a structured recording artifact through the same normalized result structure used elsewhere. This is not presented here as a broad wetware benchmark, but as evidence that the proposed control-plane abstraction is sufficient to drive a real wetware-facing runtime end to end while preserving stable client-visible contracts. The same architectural boundary also supports agent-facing access. In the current prototype, a Gemini-based client performs resource discovery through PHYS -MCP, submits a structured request, and summarizes the normalized result in natural language. We treat this client only as a usage example of the interface; backend selection, policy enforcement, invocation, telemetry interpretation, and fallback remain inside the PHYS -MCP control plane.
TABLE IV R EPRESENTATIVE FAULT- CAMPAIGN SCENARIOS AND OBSERVED PHYS -MCP BEHAVIOR .
Scenario
Expected response
Outcome
Observed behavior
Drifted local fast backend
prefer healthier externalized fast backend
success
externalized backend selected directly; no fallback needed
Local prepare failure
recover through fallback
success
externalized backend used after local preparation failure
Wetware without supervision
reject before execution
expected reject
no acceptable backend candidate returned
Stale chemical twin state
reject on freshness bound
expected reject
no acceptable backend candidate returned
Missing required telemetry after invocation
recover through fallback
success
postcondition check failed and externalized backend was used
B. RQ2: Robustness Under Runtime Faults and Simplified Selectors We first compare the full matcher against simpler alternatives on a curated suite of seven tasks. The full PHYS -MCP matcher achieves 7/7 correct selections, whereas the random admissible baseline reaches 4/7, and both the modality-only and latency-only baselines reach 3/7. The decisive cases are precisely those that require runtime-aware control semantics rather than static endpoint presence: selecting the externalized fast backend when the local fast backend is too drifted, rejecting a stale chemical twin despite nominal modality compatibility, and rejecting a wetware request when required human supervision is absent. We then evaluate the full control path under five representative fault scenarios. Table IV summarizes the outcomes. All five scenarios produced the expected control-plane behavior. Two scenarios triggered fallback to the externalized fast backend after a local preparation failure or after postcondition validation detected missing required telemetry. Two scenarios were rejected before execution because policy/safety or freshness constraints were violated. In the remaining scenario, the matcher directly preferred the externalized fast backend because the local fast backend reported a degraded runtime state with excessive drift. Taken together, the baseline comparison and the fault campaign show that the added runtime semantics are not decorative metadata. They affect backend choice, admissibility, and recovery behavior in exactly the cases that a flat discovery-
and-invocation layer would handle poorly. C. RQ3: Control-Plane Cost For the three local backends, the mean additional wall-clock overhead of orchestration over 25 runs is small in absolute terms: 0.361 ms for the chemical backend, 0.194 ms for the wetware backend, and 0.189 ms for the local fast backend. The corresponding relative factors are 1.17×, 3.67×, and 2.43×. The multipliers for the wetware and fast twins appear comparatively large only because the underlying direct local invocations are extremely short; the absolute control-plane cost remains below one millisecond in all three cases. For the externalized backend path, 15 HTTP-backed invocations yield a mean backend latency of 3.95 ms and a mean round-trip time of 8.96 ms, corresponding to an average transport and boundary cost of 5.01 ms. This is still a same-machine experiment rather than a realistic network deployment. Its purpose is therefore modest: not to benchmark distributed performance, but to show that the PHYS -MCP control path continues to function across an explicit service boundary while keeping the added cost moderate relative to backend execution in this prototype. The Cortical Labs runtime path exposes an additional timing distinction that is important for real wetware-facing backends. Across three successful runs, the observed backend latencies lie between 6.94 and 7.73 s, whereas the reported observation latencies are only 16.4–49.7 ms. This should not be interpreted as a general wetware performance claim. Rather, it shows that in the current setup the dominant cost lies in backend/session handling around the short observation cycle, not in the observation step itself. This is precisely why PHYS -MCP should expose structured runtime telemetry instead of collapsing all timing into a single latency value. D. Limitations The presented system is a research prototype intended for controlled validation of the PHYS -MCP control-plane abstractions rather than a production-ready deployment platform. In its current form, the implementation is primarily realized as a single-process solution with selected externalized interfaces, and the evaluation is designed to validate the control-plane abstractions under controlled heterogeneous conditions rather than to benchmark large-scale distributed deployment. Consistent with that scope, most experiments use representative twin-backed backends, while the Cortical Labs path serves as a real API-backed feasibility case. Accordingly, the paper does not claim substrate-level performance results. The reported findings concern the orchestration layer, its abstractions, and its interaction patterns with heterogeneous backends. Consequently, the present results support the feasibility and usefulness of the proposed control abstraction, but they should not be seen as a comprehensive empirical characterization of real heterogeneous physical-neural substrates in deployed settings.
IX. R ELATED W ORK The closest prior work lies at the intersection of physical neural computing, neuromorphic deployment toolchains, device description standards, tool invocation, and digital-twin management. These lines are complementary, but none of them, taken alone, provides a control plane that combines cross-substrate discovery, task matching, lifecycle control, telemetry, and twin coupling for heterogeneous PNNs. Physical neural computing and substrate-aware execution. Survey work on physical neural computing has documented the breadth of relevant substrates and their different carriers, time scales, and engineering constraints [1]. Within this broader space, physical reservoir computing is especially relevant because it frames computation as the exploitation of intrinsic material dynamics rather than parameterheavy digital simulation; Tanaka et al. show that substratespecific nonlinearity, temporal response, and memory properties are central to performance [10]. Recent work on scalable memristive-friendly reservoir computing further underscores that reservoir-style approaches remain closely tied to emerging in-memory and memristive hardware pathways for efficient temporal processing [11]. More generally, Marković et al. argue that progress in neuromorphic computing increasingly depends on exploiting device physics itself rather than merely emulating neural computation on conventional electronics [12]. For PHYS -MCP, these observations motivate a key design principle: a PNN backend cannot be treated as a generic tensor executor, because its operational behavior depends on material effects such as drift, stochasticity, plasticity, and modality-specific stimulation and readout. Our capability, timing, lifecycle, and telemetry abstractions are therefore closer to an operational model of physical computation than to a conventional accelerator interface. Intermediate representations, compilers, and substratespecific interfaces. Several existing systems expose important parts of the deployment stack without providing a crosssubstrate control plane. NIR offers a shared intermediate representation for brain-inspired computing, while EdgeMap addresses mapping and optimization for deploying SNNs to edge-neuromorphic hardware [2], [4]. In biomolecular computing, BioCRNpyler supports compilation from high-level descriptions to chemical reaction networks [5]. For biological neural substrates, API-facing platforms already demonstrate that wetware systems can be exposed as digitally accessible experimental resources: Cortical Labs provides a programmable interface together with a simulator-backed software stack, and the FinalSpark Neuroplatform exposes remotely accessible neuronal substrates through a Python-facing environment [7], [13]. These systems are important building blocks, but they remain tied to particular substrate families and experimental environments. PHYS -MCP is positioned above such solutions as a substrate-aware orchestration layer that aims to make chemically, biologically, and device-based backends comparable under shared control-plane semantics for discovery, matching, invocation, telemetry, and lifecycle handling.
MCP, agentic tool use, and physical execution semantics. MCP contributes a useful and increasingly adopted protocol for machine-readable discovery and invocation of tools and resources [3]. Tool-use work such as Toolformer shows why normalized tool interfaces matter for higher-level AI systems [14]. However, both lines leave a gap that becomes decisive for PNNs. Their primary concern is that external capabilities are callable; our primary concern is that materially embodied capabilities are operable. Physical substrates are not purely stateless APIs: they have preparation costs, non-trivial timing, limited observability, and validity conditions that must be surfaced to the orchestrator. This is why PHYS -MCP extends MCP-style interaction with substrate-aware descriptors, lifecycle semantics, telemetry, and twin bindings instead of treating invocation alone as sufficient. Description, invocation, and twin management. On the systems side, the W3C Web of Things shows how heterogeneous resources can be described and discovered through machine-readable metadata without prescribing a single transport stack [15]. MCP contributes a similarly important idea for discovery and invocation of tools and resources [3]. Both are highly relevant to PHYS -MCP, but neither captures the domain-specific semantics required for embodied computation: modality constraints, reset cost, calibration validity, observability limits, drift-aware readiness, and invocation decisions conditioned on twin state. Digital-twin research complements this perspective by showing that synchronization is itself a control problem, and recent work on declarative lifecycle management makes lifecycle stages explicit within the twin [8], [16]. These insights are directly relevant because many PNN substrates are neither always-ready nor stable over long periods; they require warm-up, priming, recalibration, reset, or replacement. Our twin plane and lifecycle semantics build on this line of work, but specialize it to heterogeneous PNN resources and to task placement decisions that depend on current substrate validity. In summary, related work already offers strong building blocks for substrate taxonomies, neuromorphic representations, substrate-specific runtimes, device-description standards, tool invocation, and twin synchronization. The missing piece is their integration into a single control-plane abstraction for heterogeneous physical neural substrates. To our knowledge, the combination of cross-substrate discovery, task-to-substrate matching, lifecycle-aware invocation, telemetry, and twin coupling has not been addressed in one architecture before. X. C ONCLUSION This paper argued that the practical use of physical neural networks in edge computing and distributed AI systems is limited not only by substrate maturity, but also by the absence of a common software control plane. We presented PHYS -MCP as a first architecture for that missing layer and showed how it can expose heterogeneous physical neural resources through explicit capability, timing, lifecycle, telemetry, and twin semantics rather than through a lowest-common-denominator accelerator API. In particular, we positioned many relevant
PNN resources at the extreme edge and treated PHYS -MCP as the software layer that integrates such resources into broader edge-, fog-, and cloud-oriented workflows. Beyond the architecture itself, the paper includes a reference implementation with runtime-aware matching, postconditionchecked fallback, an HTTP-backed externalized backend path, and an integrated Cortical Labs execution path. The controlled evaluation remains centered on representative backends, where the full matcher outperforms simpler selectors and representative faults are handled through rejection or fallback as intended. In addition, the Cortical Labs path shows that the same client-visible control model can drive a real wetwarefacing API end to end, expose telemetry before and after execution, and return structured recording artifacts. We view these results as a first reference-architecture and prototype-level validation of the PHYS -MCP idea rather than as a comprehensive benchmark of physical substrates or edge deployments. The main result is that a substrate-aware control plane can expose heterogeneous, lifecycle-sensitive, and only partially accessible physical AI resources through a stable software-visible contract while preserving the semantics needed for matching, supervision, and recovery. An important next step is to broaden the empirical scope of PHYS -MCP towards additional physical AI substrate families, including iontronic, microfluidic, mechanical/acoustic, and other mixed-signal neuromorphic systems, as well as, in the longer term, adjacent hybrid quantum-classical platforms, in order to test how well the capability, lifecycle, and telemetry abstractions generalize across further combinations of modality, timing, and observability constraints. Further priorities are to strengthen security and authorization for shared physical resources, improve twin fidelity, and evaluate the approach in more distributed deployment settings. E THICAL C ONSIDERATIONS While our current evaluation relies on simulation and existing APIs, the PHYS -MCP architecture is explicitly designed to orchestrate biological neural substrates. The integration of living tissue into computational stacks necessitates rigorous ethical oversight [7]. We address this through requirement R7 (Safety and Tenancy), which provides technical enforcement for admissible stimulation ranges and mandatory human-inthe-loop supervision. Furthermore, by improving the fidelity of digital twins and simulation-based pre-validation, PHYS MCP contributes to the principle of replacing animal-based testing with ethically governed in-vitro alternatives [9]. U SE OF AI AND S OFTWARE AVAILABILITY ChatGPT and Gemini were used during technical development of the prototype and linguistic refinement of the overall paper. Fig. 1 contains parts generated by Gemini NanoBanana. The authors reviewed and edited all generated content and take full responsibility for the final manuscript. Code and data of the described experiments are available on GitHub (https://github.com/fischesn/phys-mcp) and Zenodo [17].
R EFERENCES [1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
S. Fischer et al., Beyond silicon: Materials, mechanisms, and methods for physical neural computing, 2026. DOI: 10.48550/arXiv.2604.09833 [Online]. Available: https://arxiv.org/abs/2604.09833 J. E. Pedersen et al., “Neuromorphic intermediate representation: A unified instruction set for interoperable brain-inspired computing,” Nature Communications, vol. 15, 2024. DOI: 10.1038/s41467-024-52259-9 D. S. Parra and J. Spahr-Summers, “Model context protocol specification,” Model Context Protocol, Tech. Rep., Nov. 2025. [Online]. Available: https : / / modelcontextprotocol.io/specification/2025-11-25 J. Xue et al., “Edgemap: An optimized mapping toolchain for spiking neural network in edge computing,” Sensors, vol. 23, no. 14, p. 6548, 2023. DOI: 10. 3390/s23146548 W. Poole, A. Pandey, A. Shur, Z. A. Tuza, and R. M. Murray, “Biocrnpyler: Compiling chemical reaction networks from biomolecular parts in diverse contexts,” PLOS Computational Biology, vol. 18, no. 4, e1009987, 2022. DOI: 10. 1371/journal.pcbi.1009987 B. J. Kagan et al., “In vitro neurons learn and exhibit sentience when embodied in a simulated game-world,” Neuron, vol. 110, no. 23, 3952–3969.e8, 2022. DOI: 10.1016/j.neuron.2022.09.001 F. D. Jordan, M. Kutter, J.-M. Comby, F. Brozzi, and E. Kurtys, “Open and remotely accessible neuroplatform for research in wetware computing,” Frontiers in Artificial Intelligence, vol. 7, p. 1 376 042, 2024. DOI: 10 . 3389 / frai . 2024 . 1376042 B. Tan and A. Matta, “The digital twin synchronization problem: Framework, formulations, and analysis,” IISE Transactions, vol. 56, no. 6, pp. 652–665, 2024. DOI: 10.1080/24725854.2023.2253869
[9]
[10]
[11]
[12]
[13] [14]
[15]
[16]
[17]
D. Hogan et al., Cl api: Real-time closed-loop interactions with biological neural networks, version 1.0, 2026. DOI: 10 . 48550 / arXiv . 2602 . 11632 [Online]. Available: https://docs.corticallabs.com/ G. Tanaka et al., “Recent advances in physical reservoir computing: A review,” Neural Networks, vol. 115, pp. 100–123, Jul. 2019. DOI: 10.1016/j.neunet.2019. 03.005 C. C. Horuz, A. Ceni, C. Gallicchio, and S. Otte, Scalable memristive-friendly reservoir computing for time series classification, 2026. DOI: 10.48550/arXiv. 2604.19343 [Online]. Available: https://arxiv.org/abs/2604.19343 D. Marković, A. Mizrahi, D. Querlioz, and J. Grollier, “Physics for neuromorphic computing,” Nature Reviews Physics, vol. 2, pp. 499–510, Jul. 2020. DOI: 10. 1038/s42254-020-0208-2 Cortical Labs, Developer Guide: Cortical Labs API (CL API), Accessed: 202604-17, Cortical Labs. [Online]. Available: https://docs.corticallabs.com/ T. Schick et al., “Toolformer: Language models can teach themselves to use tools,” in Advances in Neural Information Processing Systems 36 (NeurIPS 2023), 2023. [Online]. Available: https://proceedings.neurips.cc/paper files/paper/2023/hash/ d842425e4bf79ba039352da0f658a906-Abstract-Conference.html M. Lagally, R. Matsukura, M. McCool, and K. Toumura, “Web of things (wot) architecture 1.1,” World Wide Web Consortium (W3C), W3C Recommendation, Dec. 2023. [Online]. Available: https://www.w3.org/TR/wot-architecture11/ E. Kamburjan, N. Bencomo, S. L. T. Tarifa, and E. B. Johnsen, “Declarative lifecycle management in digital twins,” in Proceedings of the ACM/IEEE 27th International Conference on Model Driven Engineering Languages and Systems, Association for Computing Machinery, Oct. 2024, pp. 353–363. DOI: 10.1145/ 3652620.3688248 S. Fischer, Phys-MCP prototype: Bridging physical and digital AI systems, 2026. DOI : 10.5281/zenodo.19595082 [Online]. Available: https://doi.org/10.5281/ zenodo.19595082