Skip to main content
Glama
ahmad-codex

Workstream

by ahmad-codex
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

Related Servers

Alternatives to Workstream

  • github-mcp

    AbdeeBuilds
    A
    license
    A
    quality
    D
    maintenance
    GitHub MCP server for Claude Code, Cursor, Cline, Windsurf, and any MCP-compatible client. Exposes GitHub tools (issues, pull requests, code search, file content) to your LLM via the Model Context Protocol.
    7
    MIT

  • slack-mcp

    LesterAJohn
    A
    license
    Not graded
    quality
    C
    maintenance
    MCP server that exposes Slack Web API operations as tools, enabling users to list conversations, read history, post messages, and call any Slack Web API method.
    62 npm
    MIT

  • TaskCenter

    xiaogezi
    A
    license
    Not graded
    quality
    A
    maintenance
    Local-first task governance board for AI agents, enabling session registration, task creation, progress updates, and evidence reporting via MCP, with separation of agent claims and human acceptance.
    Apache 2.0

Related Servers

  • Casefile

    azimov777
    A
    license
    A
    quality
    A
    maintenance
    Self-hosted task tracker and MCP server for AI coding agents. Append-only case files preserve decisions, failed attempts, questions, and check results across sessions. A live web board lets people track progress and answer agents. Runs locally in Docker and connects to Claude Code, Codex, Cursor, and other Streamable HTTP MCP clients. MIT licensed.
    10
    30
    6
    MIT

  • brainy

    memokar
    A
    license
    B
    quality
    A
    maintenance
    Self-hosted shared brain for AI agents: Git-versioned Markdown knowledge plus a task queue with atomic claims, per-space ACL, audit log and human approval, so Claude, ChatGPT and other agents can hand work to each other.
    27
    AGPL 3.0

  • tower-mcp

    Rohanxmalik
    A
    license
    B
    quality
    A
    maintenance
    Enables AI coding agents on different machines and accounts to work one repository as a team by declaring file and symbol claims before editing, so collisions are refused up front rather than discovered at merge. It also supports delegating tasks between teammates' agents, which do the work with their own tokens and commit, with replies, commit shas, claims and messages landing on one shared board.
    20
    2
    MIT

  • Pursers

    swisspra
    A
    license
    Not graded
    quality
    A
    maintenance
    Local OS for your AI Agents fleets. ——————- Enables AI agents to coordinate through a durable local board with shared state, ticket lifecycle, evidence-based approvals, and journal-woken handoffs.
    2
    Apache 2.0

  • Crosschat Relay

    omkarkharade
    A
    license
    Not graded
    quality
    C
    maintenance
    Lets AI agents in different harnesses hand each other concrete tasks, claim and report on them, and continue after restarts via a live dashboard and unattended workers.
    MIT

  • synco-mcp

    ijustseen
    F
    license
    Not graded
    quality
    C
    maintenance
    Enables multiple AI coding agents to coordinate on a shared software project by registering, claiming tasks, declaring file intents, publishing structured change reports, and handing off context, with a local dashboard showing state in near real time.
    -
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.6/5.0

Scored across 36 tools

Disambiguation4/5

Most tools have clearly distinct purposes tied to specific resources and lifecycle stages (claim vs. release vs. refresh, verification vs. fix vs. review verdicts). A few boundaries are subtle — the three submit_*_verdict/submit_review_decision tools and mark_task_status vs. override_verdict require careful reading — and claim_next_attempt_for_review is a documented no-op placeholder whose presence adds confusion.

Naming Consistency5/5

Every tool follows a consistent snake_case verb_noun pattern (list_projects, claim_next_task, submit_review_decision, archive_plan, create_task). Longer names like claim_next_finding_for_verification still conform to the same convention, and there is no mixing of camelCase or conflicting verb styles.

Tool Count3/5

36 tools is heavy for any server, and while the surface spans several real sub-domains (projects, plans, phases, tasks, findings, claims, boards, Slack, audits), the count is driven partly by duplicate claim variants and a dead placeholder tool. It is defensible given the orchestration scope but sits above a comfortable ceiling.

Completeness4/5

Coverage is strong across the full lifecycle: project/plan/phase setup, task and finding creation, claim/refresh/release, submission and verdict flows, audit dispatch, stuck-work inspection, event forensics, and export. Minor gaps remain (no direct list_tasks or list_findings, no project update, and plan archiving is intentionally one-way), but core workflows are workable.

Maintenance

ActivityMaintained
ResponsivenessWithin a week

Resources