A
licenseA
qualityB
maintenanceEnables MCP-capable AI clients to control a local computer over stdio with filesystem operations, ripgrep search, shell command execution, and persistent process sessions.
14
MIT
openrhyme-mcp
Officialby OpenRhyme
Related Servers
Alternatives to openrhyme-mcp
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityDmaintenanceProvides a stdio MCP bridge for coding agents to query and record engineering knowledge locally, preserving debugging history, failed attempts, and verified solutions.0MIT
- AlicenseNot gradedqualityAmaintenanceSearch and read locally-recorded meeting transcripts over stdio. Read-only, no network. Exposes list_sessions, get_session, and search_transcripts to any MCP client.73 PyPI7MIT
- AlicenseNot gradedqualityAmaintenanceProvides a drop-in MCP memory server over stdio using a local SQLite store, enabling agents to store, search, and audit memory with provenance, scoped access, and contradiction tracking without requiring API keys, LLMs, or embedding providers.648 npm16Apache 2.0
- FlicenseNot gradedqualityBmaintenanceExposes read-only capabilities from the Baihua home server to any MCP client via stdio, including knowledge base search/reading, budget summary, and task listing.-
- AlicenseNot gradedqualityAmaintenanceProvides a local stdio MCP server that gives AI coding agents a typed, temporal, evidence-backed memory on embedded SQLite, letting them record decisions and constraints, ask why something happened, navigate memory by time, trace proof paths between refs, and export or supersede stored state without rewriting it. It also exposes read-only ChronoLoom view tools so a person and their agent can steer the same multidimensional memory view by semantic intent rather than raw coordinates.Apache 2.0
TDQS
A3.9/5.0
Scored across 5 tools
Disambiguation5/5
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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Maintenance
ActivitySlowing
ResponsivenessNo issues