Skip to main content
Glama
Msty Local Ops

Msty Local Ops

Official
by vega-llc

Msty Local Ops

Msty Local Ops is a small, fail-closed MCP for Msty Studio on macOS. It exposes four read-only diagnostics and, in a separate opt-in process, one bounded local-generation tool. It does not read chats, Knowledge Stacks, private databases, provider keys, or application configuration.

New here? Start with the illustrated Mac start guide.

This is an independent community project, not an official Msty product.

What you get

The default diagnostic process exposes exactly:

  • get_msty_status

  • get_capability_manifest

  • get_model_manifest

  • run_compatibility_check

The separate local-inference process adds only local_generate. That tool requires an exact model identifier advertised by a fixed Msty loopback service. It never auto-selects a model, follows redirects, uses a proxy, or falls back to an online provider. Its bounded thinking_mode option accepts only default or none; none sends the standard local chat-template switch without exposing arbitrary provider parameters.

Related MCP server: codex-computer-use-mcp

Install

  1. Install Msty Studio for macOS.

  2. Install Python 3.10, 3.11, or 3.12. The installer selects a supported version even when a newer python3 is also installed.

  3. Download this repository and double-click Install Msty Local Ops.command.

  4. The installer creates two ready-to-paste Toolbox JSON files and opens their folder.

  5. In Msty Studio, open Toolbox → Add New Tool → STDIO / JSON and paste the diagnostic JSON first.

  6. Test the tool in Msty's Tool Console before attaching it to a conversation.

Msty starts the MCP when it needs it. There is no background service to launch by hand. After installation, start Msty Studio first.

Msty's official Toolbox guide explains the same local STDIO/JSON flow: Msty Studio Tools.

The diagnostic MCP is the safe default. Add the local-inference JSON only when you want the calling model to send prompts to a local Msty model. The calling MCP client can observe those prompts and results; see PRIVACY.md.

Health, upgrade drift, and support

The installer adds two local commands:

msty-local-ops-doctor
msty-local-ops-support --output msty-local-ops-support.json
msty-local-ops-verify

The doctor reports GREEN, YELLOW, or RED and never reads chats, keys, or Msty's private database. After a known-good setup, run msty-local-ops-doctor --record-baseline. Future checks warn if the tested Studio version, adapter version, or local service shape changes.

The support command writes a mode-0600 JSON bundle containing versions, booleans, counts, and error categories only. It deliberately excludes usernames, paths, model identifiers, prompts, content, provider details, and credentials. Review the file before attaching it to a public issue.

The verify command is diagnostic by default and submits no prompt. To run the fixed public/synthetic inference canary, explicitly name an advertised local model and its service:

msty-local-ops-verify --model "<exact-local-model-id>" --service mlx --json

The canary never accepts document content or a custom prompt and never falls back to an online provider.

Try the fictional Knowledge Stack

The folder examples/knowledge-stack/synthetic-canary contains a completely fictional retrieval test. It includes a controlling handbook, an obsolete source, an incident clarification, and an adversarial note.

  1. In Msty, create a Knowledge Stack.

  2. Add the entire synthetic-canary folder.

  3. Choose a local embedding model if you want processing to remain on the device.

  4. Compose the stack and attach it to a chat using a local model.

  5. Run the questions in docs/KNOWLEDGE_STACK.md.

Official references: Knowledge Stack basics and local models.

Network and data boundary

The adapter has only these destinations:

Msty service

Address

Local AI

127.0.0.1:11964

MLX

127.0.0.1:11973

llama.cpp

127.0.0.1:11454

Only GET /v1/models and POST /v1/chat/completions are permitted. The default diagnostic process never submits prompts.

Development

python3 -m venv .venv
.venv/bin/python -m pip install -e '.[dev]'
.venv/bin/python -m pytest -q
.venv/bin/python scripts/check_public_boundary.py .
uv lock --check
uv export --frozen --no-dev --no-emit-project --format requirements.txt --output-file requirements-audit.txt

The public repository must start with a fresh initial commit. Do not merge or import history from an operational or private repository.

License and attribution

MIT licensed. See LICENSE and NOTICE.md.

Available Tools

4 tools
get_capability_manifestB

Report the exact four-tool diagnostic surface and its trust boundaries.

Inputs: no named parameters. Returns: result

get_model_manifestA

List facts advertised by fixed, loopback-only Msty model services.

Inputs: no named parameters. Returns: result

get_msty_statusA

Report installation, local-service, and readiness state without reading Msty data.

Inputs: no named parameters. Returns: result

run_compatibility_checkA

Validate the installed Studio version and local model endpoint schemas.

Inputs: no named parameters. Returns: result

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A3.9/5.0

    Scored across 4 tools

    Disambiguation5/5

    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).

    Naming Consistency5/5

    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.

    Tool Count5/5

    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.

    Completeness5/5

    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.

    Maintenance

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      D
      maintenance
      MCP server that enables local Apple on-device Foundation Model access via any MCP client, supporting text generation, structured output, and multi-turn chat on macOS.
      2
      MIT
    • A
      license
      Not graded
      quality
      B
      maintenance
      A macOS-native MCP server that provides AI hosts with fresh workspace state, bounded context, and retained execution evidence, avoiding collapsing operations into shell strings.
      9 npm
      Apache 2.0
    • A
      license
      Not graded
      quality
      C
      maintenance
      A local MCP server that lets Claude Code and Codex delegate repository exploration and test proposals to a remote LM Studio model, while enforcing security boundaries by keeping all repository access read-only and never applying patches or running commands remotely.
      30 npm
      1
      MIT