Semaphore UI MCP server
Related Servers
Alternatives to Semaphore UI MCP server
No user-submitted related servers found.
Related Servers
- AlicenseDqualityCmaintenanceEnables secure, configurable access to one or more Syncthing instances over MCP, with read-only defaults and opt-in write, destructive, and administrative operations. Supports stdio and authenticated Streamable HTTP transports, typed tools, bounded responses, and multi-instance configuration.40MIT
- AlicenseNot gradedqualityCmaintenanceConnects MCP clients to a self-hosted Seafile server through the seahub HTTP API, exposing libraries, files, search, sharing, and optional admin operations over stdio or Streamable HTTP. It defaults to read-focused tools and gates writes behind confirmation, with token redaction and dry-run previews.9 npmMIT
- AlicenseNot gradedqualityCmaintenanceTurns any API with an OpenAPI 3.0/3.1/3.2 spec into callable MCP tools: it generates a tool per supported operation, validates arguments, and forwards authenticated requests, served over stdio or local HTTP or embedded as a library. No hand-written tool per endpoint is required.MIT
- AlicenseAqualityBmaintenanceConnects MCP clients to a self-hosted Syncthing instance's GUI REST API for reading configuration, folders, devices, and connections, plus gated write actions like adding or patching folders and devices, scanning, pausing, restarting, and shutting down. Supports stdio and localhost-only Streamable HTTP with API-key auth, dry-run write previews, redaction of secrets, caching, and rate limiting.5MIT
- FlicenseCqualityDmaintenanceSchema-driven MCP server that exposes all Paperclip API operations as typed MCP tools over stdio or Streamable HTTP, supporting both authenticated and local_mode deployments.100-

Daykeeper MCPofficial
AlicenseAqualityBmaintenanceA local stdio MCP adapter for the Daykeeper management API. It uses separately issued scoped credentials and exposes read-only tools by default; planning and mutations require explicit opt-in.825 npmApache 2.0
TDQS
Scored across 213 tools
Most tools are distinguished by resource + scope (global vs project vs template), and several descriptions explicitly disambiguate near-duplicates (e.g. get_global_task warns to use get_task). However, there are genuine near-overlaps an agent can easily mix up: get_task_output vs get_task_raw_output, list_tasks vs list_recent_tasks vs list_global_tasks, list_integrations vs list_project_integration_aliases, and confirm_task/reject_task vs wait_for_task. With 213 tools, selection pressure is high and several boundaries are only clear after reading the full description.
The surface follows a very predictable verb_noun snake_case convention (list_/get_/create_/update_/delete_/set_) with clear resource nouns. Minor deviations exist in noun ordering for a few tools (detach_template_inventory, set_template_default_inventory, stop_template_tasks) and one-off verbs (ping, leave_project, test_project_notification), but overall it is highly readable.
213 tools is an extreme mismatch for any coherent agent-facing surface; this is a 1:1 dump of the Semaphore REST API, including edition-gated routes that return 404 in Community. Many tools (permissions, terraform aliases, TOTP, subscription, cluster) will rarely or never be needed, creating enormous selection cost.
Coverage is essentially exhaustive: full CRUD for projects, templates, tasks, repositories, inventories, integrations, runners, roles, users, views, workflows, and even reference lookups, task polling, and cron validation. No obvious lifecycle gap exists for the Semaphore domain.