omlx-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OMLX_API_KEY | Yes | Your local oMLX API key. | |
| UV_CACHE_DIR | No | Cache directory for uv. | |
| OMLX_BASE_URL | No | Base URL for the oMLX API. | http://127.0.0.1:8000/v1 |
| OMLX_AGENT_MODEL | No | Default model for agent mode. | MLX-Qwen3.5-35B-A3B-Claude-4.6-Opus-Reasoning-Distilled-8bit |
| OMLX_DEFAULT_MODEL | No | Default model for chat mode. | MLX-Qwen3.5-27B-Claude-4.6-Opus-Reasoning-Distilled-v2-4bit |
| UV_PROJECT_ENVIRONMENT | No | Virtual environment directory for uv. |
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 |
|---|---|
| omlx_statusA | Return local oMLX model list and current Mac power status. |
| omlx_runB | Run either a chat or agent-style local oMLX request. Blocks on battery unless allow_on_battery is true. |
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 2 tools
The two tools have completely distinct purposes: one for querying status/model list, the other for running requests. There is no overlap or ambiguity.
Both tools follow a consistent 'omlx_' prefix plus a verb (status, run). This is a clear and predictable pattern.
With only 2 tools, the set feels thin for a model-running server. While each tool is justified, the count is on the borderline of being too minimal.
The core functionality is covered: status provides information needed before running, and run executes the request. Minor gaps exist (e.g., no explicit model management or request cancellation), but for the stated purpose the surface is largely complete.