openrhyme-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPENRHYME_BIN | No | Path to the openrhyme CLI binary. If not set, the server will look for `openrhyme` on PATH. |
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 |
|---|---|
| eventsA | Raw activity events between Returns {"events": [...rows...], "count": N}; each row's keys are the event columns (bundle_id, app_name, window_title, kind, value, ...) and a local-ISO "time" field. Read result["events"] for the rows. Times accept |
| statusA | Engine status (trust, daemon liveness, event count, allowlist) plus this server's view: supported schema, database path and whether it exists. |
| appsC | The capture allowlist and the currently running apps (with bundle identifiers, whether each is allowlisted, and whether it is an Electron app). |
| allow_appA | Add an app to the capture allowlist by bundle identifier (e.g. com.apple.Safari). Takes effect within a few seconds; the daemon reloads its config on each heartbeat. |
| deny_appA | Remove an app from the capture allowlist by bundle identifier. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| recent_events | The last 15 minutes of raw events as JSON Lines (values cut to 500 chars). |
TDQS
Scored across 5 tools
Each tool has a clearly distinct role: events queries captured activity data, status reports engine/server state, apps lists the allowlist and running apps, and allow_app/deny_app make targeted allowlist changes. There is no functional overlap between any of these tools.
The read-only tools use noun-style names (events, status, apps) while the mutations use verb_noun style (allow_app, deny_app). This is fairly predictable and readable, though not as uniform as a single verb_noun convention throughout.
Five tools is well-scoped for this server's purpose: querying activity events, checking engine status, listing apps, and managing the allowlist. Each tool earns its place without the surface feeling bloated or thin.
The core workflows are fully covered: retrieve activity data, inspect engine health, view the allowlist, and add or remove apps from it. Since events are an append-only raw log, update/delete operations are not expected here, so there are no obvious gaps.