Hi Margo community — I maintain Industrial-AIOps (iaiops, MIT, on PyPI + the MCP Registry), a vendor-neutral OT read-first data tap across ~14 field protocols (OPC-UA, Modbus, S7comm, EtherNet/IP, PROFINET-DCP, BACnet/IP, MTConnect, MQTT-Sparkplug, HART-IP, …) plus a cross-protocol RCA “brain”, all exposed as governed MCP tools (audit / budget / risk-tier / undo + change-management gating on the few writes).
It maps naturally onto Margo’s edge-application role: pure-Python, headless, air-gap friendly, container-shippable. I’ve applied to the TWG (Observer) and already drafted an application description to the margo.org/v1-alpha1 schema. I’d love to (a) run the conformance toolkit and (b) offer iaiops as a neutral reference OT app.
I’ve posted the specific Application Description questions here: Packaging a headless MCP tool-server (multi-profile) as a Margo application — Application Description questions · margo/specification · Discussion #192 · GitHub — feedback very welcome. Happy to contribute the descriptor + a hardened container recipe back.
@zhouwei008 I’ll address the three questions you asked here:
- Runtime shape — the app exposes an MCP stdio/socket tool surface rather than an HTTP UI. Does the Application Description care about the interface, or purely about container + config + lifecycle?
At this point, specifying how applications communicate with each other is not in Margo’s scope. There has been some discussion about this, so maybe in the future Margo might have an opinion, but not right now.
So as far as using stdio/socker, Margo doesn’t have an opinion. I think socket-based communication would be the easiest to use since it only requires opening the port in the container. Stdio would be more difficult and would require some special deployment approach to make this work (e.g., sidecars).
- Profiles / variants — I’ve modeled the editions as one application with a
profile parameter (SelectValidationSchema → IAIOPS_MCP env var). Is that the intended idiom, or would you expect N app packages (one per profile)?
Margo doesn’t have an opinion on how applications are implemented. If having a profile parameter to allow the person installing the application to make a choice makes sense, that is an implementation choice the supplier can make. If it makes more business sense to have multiple application packages, or multiple deployment profiles in the application description, that would be a choice the implementer can make.
- Secret + least-privilege —
v1-alpha1 seems to have no secret-typed parameter; how should a workload declare a secret param, plus “read-first, outbound-only to configured OT endpoints, no inbound”? Governance is core to this app.
Currently, handling secret parameters is not incorporated in the specification. We do have an existing feature for adding support for this.
Thanks Philip — that’s exactly the clarity I needed, and it unblocks the packaging.
Runtime shape: good to know it’s out of scope. I’ve taken your recommendation and made the socket transport the default in our Margo skeleton — the container now exposes a single MCP port (streamable-http), IP-allowlisted, while the OT side stays strictly outbound to the configured endpoints. stdio is kept only as a local-pipe fallback.
Profiles: perfect — I’ll keep it as one parameterised application (a profile parameter selects which field-protocol connectors load) rather than fragmenting into per-edition packages. Simpler supply and upgrade story.
Secrets: that’s the one real gap for us, so I’ll take it to #145 rather than work around it. We resolve every credential on-device from an encrypted secret store by reference — the descriptor and deployment spec only ever carry the secret’s logical name, never a value — which I think is a useful third data point alongside the two models already on that issue. I’ll write it up there.
Appreciate you taking the time — really helpful for a small independent maintainer trying to be a good Margo citizen.