The macOS MCP Host¶
The ONIX macOS client can run a local MCP server that lets an MCP-capable AI client — Claude Code, Claude Desktop, Cursor, or another client that speaks the protocol — drive the running desktop app. This page describes what that host exposes conceptually and how it is secured, without documenting exact tool argument schemas or internal enforcement mechanics.
What it exposes, conceptually¶
The local host groups its tools into a small number of families:
- Shell — application status, getting-started guidance, reloading the page.
- Chart — reading and adjusting the chart the frontend renders (symbol, resolution, indicators), through the same typed capability namespace the frontend itself installs for this purpose.
- Strategy Workspace — reading and editing the code editor surface the frontend's strategy workbench exposes, including saving draft content.
- Screener — reading and changing screener state (applying, resetting, sorting, or selecting) through the frontend's own screener bridge.
- Connections — reading and controlling venue-connection console state through the frontend's own connections bridge.
- Diagnostics — a higher-risk capability for support and development-time use, off by default and outside the local host's supported, default-scope boundary. This documentation does not describe what it exposes or how to enable it.
Every one of these tools is a thin call onto a browser bridge that the ONIX frontend itself installs when a relevant page is loaded — the native app does not maintain a second chart, a second datafeed, or a second copy of any product state. Availability of a given tool is therefore a property of which frontend route is currently loaded, not a fixed capability of the app: a bridge mounted on one route may simply be absent on another, and the host reports that as a typed "unavailable," not a crash.
Tool groups that existed in an earlier, differently-branded version of this codebase — covering live trading, strategy activation, portfolio/market data reads, and a generic dashboard-automation surface — do not exist in this registry. They were removed outright rather than disabled, on the grounds that ONIX either has no equivalent server contract for them or that the capability should not exist as an automatable native tool at all.
How a client connects, at a high level¶
The host listens on a fixed local port, bound exclusively to the loopback interface. A client that wants to use it needs a connection credential, obtained from inside the running ONIX Mac app itself and copied into the AI client's own MCP configuration. Connecting requires physical or remote-desktop access to the machine already running the app — there is no discovery mechanism and no way to obtain a working credential without that access.
Security posture¶
- Local-only, by construction. The server binds to the loopback address at the operating-system level, not merely by application-level configuration that could be misconfigured to listen more broadly.
- Authenticated. Every tool-bearing request must carry a valid connection credential; there is no anonymous or unauthenticated path to any tool.
- What it will refuse by default. The default, supported tool registry contains no order-placement tool, no order-cancellation tool, no strategy-activation tool, no sandbox start/stop tool, and no generic HTTP or fetch tool. An additional safeguard also rejects any request whose target resembles a money- or account-mutating route, independent of whether a tool that could reach such a path exists at all, as a second line of defense.
- A higher-risk capability exists and is off by default. A "diagnostics" tool family intended for support use is excluded from the set of scopes enabled by default and must be explicitly turned on inside the app. It is outside the supported, default-scope boundary this documentation set describes, and this documentation does not describe what it exposes or how to enable it.
Test evidence at the pin¶
The reviewed commit ships a dedicated automated test package for this local host, described in its own source as proving that its tests actually exercise the shipped tool registry and dispatch guard rather than a hand-maintained copy of them. The test package is wired directly to the real application source rather than a duplicated stand-in, and one test file's specific job is to keep that binding from being quietly broken. The package's tests cover authentication, origin validation, scope gating, and the money-route safeguard described above. This is source-level, structural evidence that automated tests exist and are wired to the real code; it is not a claim that every security property has been independently, externally audited. See MCP Safety and Scope for the honest statement of what has and has not been reviewed.
Related pages¶
- MCP in ONIX — how this surface relates to the backend's own MCP surface.
- MCP Safety and Scope — the full read-only/mutating breakdown and review status.
- ONIX macOS Client — the native app this host runs inside, including the frontend-pin revalidation caveat that also applies to this host's bridge contracts.
Evidence and source pins for this page
Verified. Current behaviour, confirmed in source at the pinned commit.
Verified on against the following immutable sources:
macos@984bdf6c:MCPServer.swift (blob 05f763c1976410fbab50937a3c3c0fdd1583727e)macos@984bdf6c:MCPTools.swift (blob a03bb24902511f8e20430092e2e47acd581d88fd)macos@984bdf6c:MCPSecurityTests/Package.swift (blob 58ea4c702e76fc0059610d6392fb2db56fc1414a)
Status tokens are defined on the documentation and status model page. Every pin on this site is listed under versions and source pins.