A
licenseNot graded
qualityC
maintenanceMCP server for AI agents to manage a lightweight kanban board stored as markdown files, enabling task creation, updates, and column movements.
7
MIT
agent-coordination-mcp
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@agent-coordination-mcplist CLI agents available on PATH"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
agent-coordination-mcp
An experimental local MCP server for coordinating installed CLI agents across projects that use file-based task boards, locks, and shared status files.
The goal is not to replace the ai-agent-teamwork workflow. It is to expose that workflow as a small MCP control plane so a primary agent can see which CLI agents are available, assign work, inspect project coordination state, and keep durable assignment records.
Why This Works
The workflow works if the MCP server stays narrow:
MCP is the coordination surface, not the editor.
Project state remains in plain files owned by each project.
CLI agents continue to run as separate tools with their own approval and sandbox behavior.
Assignment and heartbeat records are explicit JSON state, not inferred from hidden sessions.
The risky part is supervising long-running CLI processes. This first slice records assignments and generates dispatch intent; later slices can add process launch adapters per CLI once the approval and lifecycle model is clear.
Related MCP server: masterplan
Current Tools
list_cli_agents- detect known local CLI agents onPATH.get_project_status- summarize.agent-tasks.json,.agent-manifest.json, and.agent-status.mdfor a project.list_assignments- read active and historical assignment records.assign_task- record a task assignment to a detected CLI agent.update_assignment_status- update assignment status and notes.
Install
uv sync
uv run agent-coordination-mcpDynamic MCP Proxy Entry
Add this to /home/stephen/dynamic-mcp-proxy-server/user.catalogue.json:
{
"name": "agent-coordination",
"description": "Local MCP control plane for detecting CLI agents and coordinating file-based project task boards",
"command": "uv --project /home/stephen/projects/agent-coordination-mcp run agent-coordination-mcp",
"tags": ["agents", "coordination", "mcp", "cli", "local"],
"tech_stack": ["python", "mcp", "cli-agents"],
"runtime": "stdio",
"env_vars": []
}Planned Slices
Inventory and assignment tracking.
ai-agent-teamworktask board adapters.CLI-specific dispatch adapters for
opencode,codex,gemini,claude, and other installed agents.Process/session tracking where supported by the CLI.
Dynamic proxy integration and research tools such as
devto-mcp-server.
See docs/ROADMAP.md for the current implementation plan. The next slice is capability-aware inventory before automated dispatch.
Non-Goals
No hidden project edits by the MCP server.
No generic shell execution tool.
No automatic force-unlocking or stale-task rewrites without explicit tool calls.
No assumption that every CLI supports resumable sessions.
Available Tools
5 toolsassign_taskC
Record that a CLI agent has been assigned a project task.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | ||
| agent_name | Yes | ||
| task_id | Yes | ||
| instruction | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states the action without disclosing side effects, authorization needs, error conditions, or whether it overwrites existing assignments. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but overly terse given the lack of schema descriptions. Front-loaded with purpose, but missing essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 required parameters, no schema descriptions, no annotations, and an output schema that is not explained, the description is severely incomplete for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description does not explain any parameter meanings (e.g., what 'instruction' or 'agent_name' represent). Fails to add value beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: recording that a CLI agent has been assigned a project task. It uses a specific verb and resource, and implicitly distinguishes from siblings like 'update_assignment_status' or 'list_assignments'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'update_assignment_status'), no prerequisites, and no context about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_project_statusC
Summarize ai-agent-teamwork style coordination files for a project.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does not mention whether the tool is read-only, has side effects, requires permissions, or fails gracefully. The word 'summarize' implies no modification, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is too vague and lacks necessary detail. While concise, it sacrifices completeness and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not hint at what the summary contains. For a simple tool, it should provide at least basic context about the output or behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about the single parameter 'project_path'. Schema coverage is 0%, and the description does not explain the path format, required properties, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it summarizes coordination files, but 'ai-agent-teamwork style coordination files' is vague and not a standard term. It distinguishes from sibling tools somewhat, as they focus on assignments and agents, but the purpose is not precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings or when not to use it. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_assignmentsC
List recorded coordination assignments for a project.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'list' implying read-only, but lacks details on error conditions, pagination, or ordering. The output schema exists but is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but under-informative. It could be slightly expanded to add value without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one required parameter and an output schema (not shown), the description is minimal. It doesn't explain what information an assignment contains, ordering, or how to interpret results. Completeness is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only implies that project_path identifies the project, but doesn't specify format, constraints, or what constitutes a valid project path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists coordination assignments for a project, using a specific verb and resource. It distinguishes from siblings like assign_task (creation) and get_project_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or not use this tool versus alternatives. The context signals include sibling tools but the description doesn't provide usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_cli_agentsA
List known CLI agent commands and whether they are available on PATH.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| extra_commands | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently reports that the tool lists commands and whether they are on PATH. Since no annotations are provided, the description adequately covers behavioral expectations. It could be improved by explicitly stating it's a read-only operation, but the action is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous information. It is appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and the presence of an output schema (presumably documenting return format), the description is mostly adequate. However, the missing parameter documentation is a notable gap that reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'extra_commands' parameter. The agent cannot infer that this parameter allows adding custom commands to check, leaving its purpose ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists known CLI agent commands and checks their availability on PATH. The verb 'list' and resource 'CLI agent commands' are specific, and the purpose distinctly differs from sibling tools which focus on task management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives is provided. However, the distinct purpose from sibling tools implies usage context, but the description lacks explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_assignment_statusC
Update a recorded assignment status.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | ||
| assignment_id | Yes | ||
| status | Yes | ||
| note | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
C2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It simply states 'update' (implying mutation) but gives no details on side effects, permissions needed, idempotency, or return behavior. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but at the expense of necessary detail. It does not earn its place as it omits critical information, making it under-specified rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, and no parameter descriptions in the schema, the description is completely inadequate. It fails to explain how to use the parameters, what the output schema (if any) contains, or any behavioral context needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema has no parameter descriptions. The tool description also fails to explain any parameter semantics, such as valid values for 'status' or the format of 'project_path'. It adds no value beyond the schema's field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a recorded assignment status.' adds little beyond the tool name, essentially restating the action. It does not distinguish from sibling tools like assign_task or list_assignments, and provides no specifics on what 'status' values are valid.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or situations where this tool should be avoided, leaving the agent to infer usage without support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
5 tool updates
v0.1.0- First observed
assign_task - First observed
get_project_status - First observed
list_assignments - First observed
list_cli_agents - First observed
update_assignment_status
TDQS
B3.1/5.0
Disambiguation5/5
Each tool targets a distinct action: assigning tasks, retrieving project status, listing assignments, listing CLI agents, and updating assignment status. No overlap in functionality.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., assign_task, get_project_status), making them predictable and easy to understand.
Tool Count5/5
With 5 tools, the set is well-scoped for coordinating CLI agents in projects, covering essential operations without unnecessary complexity.
Completeness4/5
The set covers key operations: assign, list, update, and status queries. A minor gap is the lack of a tool to retrieve a single assignment by ID, but the overall surface is adequate for the domain.
Maintenance
ActivityStale
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Hosted MCP server for task-first delegation to remote workstations and workers.
Project management MCP for AI agents with safe task reads and writes.
MCP Server for an Agent Task Marketplace
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceMinimal MCP server that keeps implementation plans and handoffs as plain markdown in the CWD of your agent.201MIT
- AlicenseBqualityCmaintenanceMCP server that provides a live coordination layer for AI agents, including attributable handoffs, a shared event ledger, atomic work-claiming, and advisory file leases to prevent collisions.279AGPL 3.0
- AlicenseNot gradedqualityCmaintenanceFile-based MCP server for AI coding agents to coordinate via inbox messaging and human escalation.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/HappyMonkeyAI/agent-coordination-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server