SphereLoom
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 1 tool
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.
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.
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.
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.