A
licenseNot graded
qualityC
maintenanceProvides camera and vision tools for AI assistants to list available cameras, capture images from USB cameras, and save frames to disk for use with LLMs.
4
MIT
SphereLoom
by jluqueba
Summary: SphereLoom aims to let an AI agent drive an Insta360 camera and process its 360° media locally over MCP, but at its current status (Milestone 0) the only working tool is a server health check — all camera and media capabilities are still planned.
Available now:
server_health— the single exposed tool; reports whether the server is running and how it is configured (status, version, transport, camera backend, workspace readiness, whether destructive tools are enabled). It never contacts a camera and takes no arguments.Planned, Milestone 1 (Wi-Fi, not yet implemented): connect, check status/battery/storage, read and change capture settings, take stitched 360° photos, start/stop unstitched video recording, browse the gallery with pagination, download media as cancellable background jobs, and delete media (disabled by default, two-step confirmation).
Planned, Milestone 2: an example agent built on the Microsoft Agent Framework, including an offline scripted mode.
Deferred:
sphereloom-assistant, an optional high-level tool like "record 30 seconds and download it" that requires your own model credentials.Planned, Milestone 3 (USB only, requires an Insta360 SDK you supply): exposure/white-balance control, live preview/streaming, and guarded storage formatting.
Planned, Milestone 4 (USB + Insta360 Media SDK + discrete NVIDIA GPU): exporting stitched 360° video, plus stabilisation and colour grading.
Explicitly not available: trimming, cutting, merging or editing clips, and DNG→JPG conversion.
Design guarantees: unsupported operations return a structured
unsupportedresponse rather than an error; jobs return a pollable/cancellablejob_idwith paths and metadata instead of media bytes; long-running work runs in sidecar processes.Safe defaults: stdio transport with no network listener, workspace path jail, confirmation tokens for destructive actions, bounded concurrency, redacted logs, and opt-in HTTP requiring a loopback bind plus token.
No hardware needed: a protocol-faithful fake camera backend runs the test suite and doubles as a demo mode.
Enables AI agents to control Insta360 360° cameras over Wi-Fi via the vendor's Open Spherical Camera HTTP API: connect, check status/battery/storage, read and change capture settings, take stitched 360° photos, start/stop video recording, browse the gallery with pagination, and download media as cancellable background jobs (plus guarded media deletion disabled by default). Planned milestones add USB-only features like exposure and white-balance control, live preview, and stitched 360° video export using the vendor's Media SDK.
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., "@SphereLoomtake a 360 photo and download it"
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.
🔮 SphereLoom
Automating a 360° shoot today means a phone app, a desktop stitcher and a folder of files copied by hand. SphereLoom is built to let an AI agent drive an Insta360 camera directly, safely and honestly.
SphereLoom is an MCP server, designed so that any MCP client — an editor, a desktop assistant or your own agent — can check a camera, change its settings, capture, browse the gallery and bring media to your machine, through one set of typed tools. It is in early development: the capability matrix shows what works today.
What it is designed to do
Speaks one tool surface for connecting, checking status, reading and changing settings, taking photos, recording video, browsing the gallery and downloading media.
Is honest about every capability. A request the camera cannot serve gets a structured, explained answer — what is not possible, why, and where to read more — instead of a timeout or a stack trace.
Runs long work in the background. Downloads are jobs you can follow and cancel, and responses carry file paths and metadata, never media bytes.
Is safe by default. It runs locally over stdio with no network listener, writes only inside one workspace folder, and asks for an explicit confirmation before deleting anything.
Keeps your media local. Nothing is uploaded anywhere, and no model credentials are needed: the server is deterministic, and the reasoning stays in your client.
Works without a camera for development. A built-in fake camera runs the whole test suite and doubles as a demo backend.
Related MCP server: OBSBOT Camera MCP Server
How it is designed to work, in plain terms
You join your camera's Wi-Fi access point from your computer.
Your MCP client starts SphereLoom as a local process.
The agent calls tools such as "check status" or "take a photo"; SphereLoom checks that the camera can do it, talks to the camera, and returns a typed result.
Downloads run as background jobs and land in your workspace folder.
SphereLoom targets Insta360 cameras, and development and testing target the Insta360 X5. The Wi-Fi layer follows the open Open Spherical Camera API, so other cameras may happen to work, but none is tested or supported.
Documentation
Developer guide: architecture and diagrams, requirements, getting started, project layout, testing, configuration and the security model.
Capabilities: what SphereLoom can do today, what is not available yet, and what the camera's API does not offer.
Contributing: how to propose changes and the workflow to follow.
Security policy: how to report a vulnerability.
Code of Conduct: the standards expected in this community.
Changelog: what changed, and when.
For developers
Want to run SphereLoom, try it without a camera, or understand how it is built? Head to the developer guide. You do not need a camera to contribute.
Status
Early development. The MCP server runs over stdio and enforces its configuration and security guard rails, but it does not control a camera yet. The capability matrix shows the state of every capability, and the changelog announces each one as it ships.
Licensing and trademarks
SphereLoom is released under the MIT licence. It needs no agent framework and no model client, and GPL-licensed dependencies are not used.
SphereLoom does not redistribute any Insta360 SDK. Wi-Fi control uses only Insta360's publicly documented HTTP API. Features that need a vendor SDK require you to apply for it yourself, accept its licence, and point SphereLoom at your local copy.
Insta360 is a trademark of Arashi Vision Inc. SphereLoom is an independent, unaffiliated project and is neither endorsed by, sponsored by, nor associated with Arashi Vision Inc. The name "Insta360" is used here only descriptively, to state which cameras this software works with.
Available Tools
1 toolserver_healthCheck SphereLoom server healthA
Report whether the SphereLoom server itself is running and how it is configured. This never contacts a camera, so it is the right first call when something is not working.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| version | Yes | |
| transport | Yes | |
| camera_backend | Yes | |
| workspace_ready | Yes | |
| destructive_tools_enabled | Yes |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the key behavioral trait that the call has no side effects on cameras and is a safe diagnostic. It stops short of stating read-only/permission requirements or whether the check can time out, but for a trivial zero-param probe this is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, each earning its place: the first defines the operation, the second gives the routing condition. Front-loaded with the purpose before the usage hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described. For a parameterless diagnostic with no annotations, the description supplies everything needed to decide when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema has nothing to document; the baseline of 4 applies. The description correctly adds nothing spurious about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('Report') plus resource ('the SphereLoom server itself') and scope ('whether it is running and how it is configured'). The scope clause distinguishes it from any camera-facing operation without needing sibling names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call it: 'the right first call when something is not working.' It also rules out a competing behavior by noting it 'never contacts a camera,' so the agent knows this won't touch hardware.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
server_health
TDQS
A4.2/5.0
Scored across 1 tool
Disambiguation5/5
There is only one tool, so there is no possibility of selecting the wrong tool or confusing overlapping purposes. Its purpose is clearly stated as a server health check.
Naming Consistency4/5
The single name 'server_health' is readable and uses snake_case, but it does not follow a verb_noun pattern. With only one tool there is no inconsistency to flag, though the convention is not fully demonstrable.
Tool Count2/5
A single tool is far too thin for a server called SphereLoom that hints at camera or device interaction. The tool count suggests the surface is essentially a stub rather than a useful toolset.
Completeness1/5
The only tool reports server health and explicitly does not contact a camera. This leaves the apparent domain of camera/device operation, configuration, or data handling entirely uncovered, creating a severe dead end.
Maintenance
ActivityMaintained
ResponsivenessResponsive
Related MCP Connectors
214 tools for AI agents over one MCP endpoint: image, video, audio, 3D, data, storage, mail, GPUs.
1Travel tools for AI agents: plan and edit real trips, search stays and tours, import travel videos.
Connect your AI to your own devices, 3D printers, factory tools and a shared agent task pool.
Image and video AI tools and your own pipelines, run from any AI assistant.
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables PTZ camera control with gimbal positioning, snapshots, and AI visual analysis for OBSBOT and UVC cameras. Supports autonomous scanning patterns and integrates with vision-language models for real-time camera analysis.71MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to remotely control Sony DSC cameras via the Camera Remote API, supporting live view, shooting, exposure adjustment, zoom, and content management.1MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to control the RealityScan photogrammetry pipeline (align, mesh, texture, export) either headless or through a visible GUI, and includes a 360° video to perspective frames converter for pre-processing equirectangular and YouTube EAC content.MIT