Msty Local Ops
OfficialServer 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
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_msty_statusA | Report installation, local-service, and readiness state without reading Msty data. |
| get_capability_manifestB | Report the exact four-tool diagnostic surface and its trust boundaries. |
| get_model_manifestA | List facts advertised by fixed, loopback-only Msty model services. |
| run_compatibility_checkA | Validate the installed Studio version and local model endpoint schemas. |
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 4 tools
Each tool targets a distinct aspect: status, capability manifest, model manifest, and compatibility check. There is no overlap; even the two manifest tools are clearly separated by domain (tool surface vs. model services).
All names follow a consistent verb_noun snake_case pattern, with three 'get_' verbs and one 'run_' verb, which is a natural fit for a validation operation. The naming is predictable and readable.
Four tools is well-scoped for a diagnostic server focused on local ops status, capabilities, models, and compatibility. Each tool earns its place without bloat or thinness.
The tool set forms a complete diagnostic surface: status, capability manifest, model manifest, and compatibility validation. The inclusion of a capability manifest explicitly confirms the surface is intentionally limited to these four tools, so no obvious gaps exist.