Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@bl-halo-mcp show 'Hello' on my Halo display"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Fleet MCP wrapper for Brilliant Labs Halo smart glasses (2025 successor to Frame 2024). Open-source AI glasses: ~40 g wayfarer, 0.2 in 640x480 RGB microOLED peripheral HUD, low-power camera, dual mics + bone-conduction audio, IMU + taps/clicks, NPU SoC, Lua 5.4 frame.* VM over BLE, Noa companion AI with Narrative memory + natural-language Miniapps.
Headless default: FastMCP stdio (uv run python -m bl_halo_mcp.server) + Starlette REST (11976) + Vite dashboard (11977). MOCK mode needs no hardware. Live needs BLE + paired Halo/Frame + Noa app.
Hands-in: display write, photo capture, Lua deploy, Noa ask. Hands-out: BLE pairing, firmware flash, store publish (drafts only here).
Related MCP server: btdiag
Halo is fully documented open hardware: Balletto B1 (Cortex-M55 + Ethos-U55 NPU),
VGA global-shutter camera, dual mics, bone-conduction audio, tap-interrupt IMU,
300 mAh - see docs/HARDWARE.md and the dashboard Hardware
page with a 3D viewer for Brilliant's official full-assembly STL
(docs.brilliant.xyz/halo/halo.stl). No official CAD sources or firmware repo
exist yet (both "coming soon" upstream) - anything claiming otherwise is wrong.
First Halo units shipped Aug 2026 after a bumpy ramp (production dates slipped repeatedly through H1 2026 - hinge/plastics tweaks, holiday shutdowns). Limited quantities, direct sale via brilliant.xyz ($299 pre-launch, now $349-399). Frame is discontinued/sold out. Company active: 2026 partnerships (Alif, Neuphonic, TheStage AI, Liquid AI), maintained docs/SDK/firmware.
Supply chain is China-centered (Brilliant has not named the assembly factory; schedules move with Chinese holidays; Far-East suppliers include Guozhao display, QST compass, Grepow cells). Design in Singapore/HK, fabless global BOM, assembly in China - the standard small-batch open-hardware play. Consequence for this repo: MOCK-first + emulator is the primary dev path for most people; live hardware is a bonus, not the baseline.
Copy-Item .env.example .env
uv sync --extra dev
uv run pytest -q
.\start.ps1First time? Complete docs/ONBOARDING.md before expecting live host calls.
Doc | Purpose |
Onboarding (mandatory: Halo/Frame, BLE, emulator, Noa costs) | |
Env + ports | |
Dev loop | |
Tool reference | |
Fixes |
Backend health: http://127.0.0.1:11976/api/health. Ports 11976/11977 registered in fleet WEBAPP_PORTS.md.
halo_device - 21-op portmanteau (status, connect, show_text/image, photo, IMU, audio, Lua CRUD, Noa, Miniapp, firmware)
halo_dashboard - Prefab App status card
halo_help, halo_shutdown - help + guarded disconnect
Resource skill://halo-dev/SKILL.md, prompt halo_recipe
Upstream: docs https://docs.brilliant.xyz, SDK https://github.com/brilliantlabsAR/brilliant_sdk, Noa https://github.com/brilliantlabsAR/noa-flutter.
Halo status dashboard (Prefab App).
{success, message, app} where app renders device, battery, display, counts.
await halo_dashboard()
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full burden. It does disclose the return format and the structure of the app field, and the example shows a simple awaited call. However, it does not explicitly state that the call is read-only/non-destructive, nor does it mention error behavior or authentication needs. For a status dashboard this is a moderate but not severe gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, well-structured with Return Format and Examples sections, and front-loads the core purpose in the first line. Every sentence contributes useful information and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless status tool, the description covers the outcome and a usage example, and an output schema exists to supplement return-value details. The main missing piece is usage context relative to the sibling tools, but that is already accounted for in the usage dimension. Overall it is sufficiently complete to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema trivially covers 100% of its (empty) parameter set. With no parameters to explain, the description needs to provide no parameter semantics; the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a status dashboard for Halo and specifies the return shape ({success, message, app}) plus what the app carries (device, battery, display, counts). This is clear enough to indicate its function, though it lacks an explicit verb like 'get' or 'retrieve'. Its role as an overview is implied relative to the sibling tools, but not explicitly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use halo_dashboard versus halo_device, halo_help, or halo_shutdown. The name suggests an overview vs. device-specific tool, but the description never states this distinction or any exclusions. An agent must infer usage from the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Halo / Frame glasses controller (portmanteau).
{success, message, result?, error?, suggestions?, has_more?}.
await halo_device("status")
await halo_device("show_text", text="Hello Halo")
await halo_device("capture_photo")
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Text / Lua source / question. Required for: show_text, run_lua, deploy_lua, noa_ask, miniapp_create. | |
| limit | No | Page size (1-100). Used by: list_photos, list_lua_apps, tap_history. | |
| offset | No | Page offset. Used by: list_photos, list_lua_apps. | |
| lua_name | No | Lua filename. Required for: deploy_lua. | |
| image_b64 | No | Base64 image. Required for: show_image. | |
| operation | Yes | One of: status, list_devices, connect, disconnect, show_text, show_image, clear_display, capture_photo, list_photos, imu_read, tap_history, play_audio, record_audio, run_lua, list_lua_apps, deploy_lua, get_lua, delete_lua, noa_ask, miniapp_create, firmware_info. | |
| duration_s | No | Audio seconds (1-30). Used by: play_audio, record_audio. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the return format and gives examples, but does not disclose side effects, state changes, error handling, or system impact. Operations like 'connect', 'disconnect', 'clear_display', and 'deploy_lua' imply significant behavioral consequences that are left completely unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is remarkably concise, with a one-line intro, a return-format section, and three examples. This structure is efficient and front-loaded, wasting no words. It could be longer to cover more operations, but as a concise spec it is well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 7 parameters and 20 operations, yet the description offers only a return format and three examples. It does not explain how operations relate to parameters, list prerequisites, or note any special cases. An agent would be ill-equipped to use it correctly for operations beyond the examples, making it incomplete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with detailed descriptions (coverage 100%), so the description does not need to add parameter semantics. The examples illustrate usage but do not add meaning beyond the schema. The description's contribution is minimal, matching the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description labels it a 'Halo / Frame glasses controller' but does not clearly state what the controller does beyond that. Examples show specific operations like 'status' and 'capture_photo', giving a hint of its scope, but the purpose remains vague and fails to differentiate it from siblings like halo_help or halo_dashboard. A more explicit statement like 'Perform operations on Halo/Frame glasses' would improve clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its sibling tools (halo_help, halo_shutdown, halo_dashboard). It neither lists conditions for its use nor mentions alternatives or exclusions. An agent would have to infer usage from the operation list, which is not stated in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Halo help - operations, BLE pairing, Lua, Noa.
{success, message, result: {topic, text}}.
await halo_help()
await halo_help("lua")
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Focus: pairing, lua, display, noa, ble, hardware. Omit for the capability-matrix overview. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description must carry the burden. It does disclose the return format ({success, message, result}) and provides example calls, which gives some behavioral context. However, it does not state that the operation is read-only, describe error handling, or mention any side effects. For a help tool this is minor, but the lack of explicit safety disclosure keeps it at a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-organized with sections for Return Format and Examples. The opening line is a bit telegraphic but still informative. There is no redundancy, and the structure front-loads the purpose. It earns a 4 for efficiency, though the opening could be slightly more descriptive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter, the description is fairly complete. It specifies the return format and provides examples. The schema covers the parameter details. It does not mention edge cases like invalid topics, but given the low complexity and presence of an output schema description, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains the 'topic' parameter with a list of focus areas and the note about omitting it for the overview. The description adds examples (e.g., halo_help('lua')) but does not materially extend the parameter semantics beyond what the schema provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Halo help - operations, BLE pairing, Lua, Noa.' which clearly indicates the tool provides help on these topics. It is not a tautology, and the verb 'help' is implied by the tool name and the list. However, it could be more explicit about the action (e.g., 'Retrieves help documentation for...'), so it misses a fully specific verb+resource phrasing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus sibling tools like halo_device, halo_shutdown, or halo_dashboard. There is no mention of alternatives or exclusions. The examples show calls but do not explain when to invoke them, leaving the agent to infer usage from the topic list in the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disconnect Halo (destructive-guarded).
{success, message, result?}.
await halo_shutdown(confirm=True)
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Must be true to disconnect. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior itself; it does add the destructive-guarded trait and the return format. However, it does not explain what disconnecting entails, whether it is reversible, or what side effects follow, leaving a meaningful transparency gap for a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very compact: one core sentence front-loads the action and guard, followed by a terse return format and example. No filler or redundancy, though some behavioral details are sacrificed for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema, the essentials are present: action, guard, return shape, and invocation example. Still, the lack of usage context and undefined consequences makes it less than fully complete for an autonomous agent choosing among sibling Halo tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents confirm ('Must be true to disconnect'), so at 100% coverage the baseline is 3. The description adds only a usage example, not new semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete action — 'Disconnect Halo' — and signals it is the shutdown/destructive sibling next to halo_device, halo_help, halo_dashboard. It is not merely a restatement, though it leaves 'Halo' and the exact scope of 'disconnect' undefined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage cue is the parenthetical 'destructive-guarded' and the example requiring confirm=True, which implies this is a gated/dangerous action. There is no explicit statement of when to use shutdown versus halo_device or halo_dashboard, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.3.0halo_dashboardhalo_devicehalo_helphalo_shutdownScored across 4 tools
halo_device is a catch-all that overlaps with halo_dashboard (status vs. full dashboard) and can perform many actions, making its boundary fuzzy. halo_help and halo_shutdown are distinct, but the general-purpose nature of halo_device creates ambiguity.
All tools share the consistent halo_ prefix and use snake_case, creating a recognizable family. However, the second part mixes nouns (device, dashboard) with verbs (shutdown) and a noun/verb (help), which is a minor inconsistency.
Four tools is a well-scoped set for a niche device controller, avoiding both bloat and thinness. Each tool has a clear role, even if halo_device is broad.
Core operations like status, display text, photo capture, help, shutdown, and dashboard are covered. Missing explicit connect/pair or settings tools, but help references BLE pairing and the surface feels adequate for typical use.
Automate 1,000+ services from any MCP-compatible AI agent: build Applets, run actions and queries.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Shared memory and actions for Claude, Kiro, OpenAI, Cursor, and other MCP-compatible AI clients.
