No user-submitted related servers found.
Scored across 16 tools
Most tools are distinct domain objects (bug, task, gate, memory, rule, claim, merge), but the read-side overlaps: ddflow_brief promises 'what is ready to start now' which is exactly ddflow_next's job, and ddflow_view, ddflow_show, ddflow_brief and ddflow_next all occupy the 'read state' niche. ddflow_help ('call this first') and ddflow_brief ('START HERE every session') also give competing first-call instructions, so an agent must read carefully to pick correctly.
All 16 tools share a consistent ddflow_<topic> prefix with single-token names and uniform action-dispatch arguments, which is highly predictable. The only deviation is mixing nouns (task, gate, rule) with verbs (claim, complete, show) and adjectives (brief, next), so the name alone doesn't tell you whether it reads or writes.
16 tools is slightly above the comfortable range but each maps to a real workflow concern (identity, lease, gates, merge, memory, rules, sessions, bugs, views). Consolidating the many action-dispatch tools further would just move complexity into argument lists, so the split is defensible.
The surface covers the full item lifecycle from identify/brief through claim, task/gate, heartbeat, merge and complete, plus supporting memory, rules, bugs and reporting. The gap is ddflow_merge's description pointing at a `ddflow_pr_sync` tool that is not in the set, leaving the PR-integration path a dead end, and there is no explicit release/abandon-lease operation.
