workspace-status-mcp
Related Servers
Alternatives to workspace-status-mcp
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityCmaintenanceProvides MCP tools for fetching GitHub PR diffs, searching codebases, running unit tests, and linting code, enabling automated code review and CI/CD workflows.MIT
- AlicenseNot gradedqualityCmaintenanceProvides MCP tools to scan and navigate markdown repositories, offering graph-based overview, document reading, context retrieval, and orphan detection.MIT
- AlicenseNot gradedqualityCmaintenanceProvides MCP tools to manage code review tasks, track evidence and GitHub checks, and record approval decisions in a local kanban board.1MIT
- FlicenseNot gradedqualityCmaintenanceProvides local MCP tools for searching, filtering, adding, updating, and analyzing a catalog of study projects, with statistics and GitHub publication readiness checks, all backed by SQLite.-
- FlicenseNot gradedqualityBmaintenanceProvides MCP tools to read, validate, propose, and review architecture models and UML diagrams in local workspaces.-
- FlicenseNot gradedqualityCmaintenanceEnables detection and remediation of Kubernetes GitOps drift via MCP tools, supporting drift detection, policy evaluation, patch application, PR generation, and audit trail retrieval.-
TDQS
Scored across 4 tools
Each tool targets a distinct concern: sweep_status covers git/CI status, check_docs covers architecture-doc freshness, check_release_drift covers release lag, and write_doc supports doc tracking. Any conceptual overlap, such as staleness, is clearly separated by the resource being checked.
All tool names follow a consistent snake_case verb_noun pattern: sweep_status, check_docs, check_release_drift, write_doc. The check_ prefix is used uniformly for health/diagnostic operations.
Four tools is well-scoped for a workspace-status server: one general status sweep, two specialized checks, and one supporting write operation. No tool is redundant or extraneous.
The set covers the full workflow for its domain: identifying repo status, checking and writing architecture docs, and measuring release drift. The release-drift pair requirement is an explicit design boundary rather than a missing operation.