Coordination Memory MCP

Overview Schema Source Related Servers Discussions Admin

get_team_board

Retrieve a compact view of current assignments for a specific team. Filter by exact status to see proposed, ready, or in-progress work, while omitting completed and canceled items by default, enabling quick team oversight.

Instructions

Return compact assignments for one exact team ID.

Discover team IDs with get_workspace_detail.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`status`	No	Filter by one exact assignment status. Omit to exclude accepted, rejected, cancelled, and superseded assignments.
`team_id`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.2.8Sep 20, 2026

addedInput schema / properties / status

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "proposed",
+        "ready",
+        "claimed",
+        "running",
+        "awaiting_human",
+        "awaiting_approval",
+        "awaiting_review",
+        "needs_fix",
+        "blocked",
+        "accepted",
+        "rejected",
+        "cancelled",
+        "superseded"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Filter by one exact assignment status. Omit to exclude accepted, rejected, cancelled, and superseded assignments.",
+  "title": "Status"
+}

removedInput schema / properties / team_id / default
```
Removed value: -"default"
```
addedInput schema / required
```
Added value: +[
+  "team_id"
+]
```

First observedv0.2.6Sep 6, 2026

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description carries the full burden of disclosing behavioral traits. It says 'Return' which implies a read-only operation, but it does not explicitly state that there are no side effects or that it is safe to call repeatedly. It also does not mention any rate limits, authentication requirements, or other constraints. The description is too sparse to fully convey behavioral expectations beyond a basic read.

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 extremely concise—two sentences with no filler. The core function is stated first, and the hint about discovering team IDs is secondary. Every word earns its place, and the structure is front-loaded and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema is present and the status parameter is well-documented in the schema, the description does not need to explain return values or status filtering. The description covers the purpose and the key prerequisite (getting team ID), which is sufficient for this simple read tool. It lacks details about error handling or invalid inputs, but they are likely covered by the tool's runtime behavior. The combination of description and schema is nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning to the team_id parameter by calling it 'one exact team ID' and explaining how to discover valid IDs via get_workspace_detail. This compensates for the schema lacking a description for team_id. The status parameter is fully documented in the schema (including default behavior and filtering), so the description does not need to repeat that. Overall, it adds meaningful value for the required parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Return') and resource ('compact assignments for one exact team ID'), making the tool's function clear. It is distinguished from siblings like get_assignment_detail and get_attention_board by focusing on a board of assignments for a team, though it does not explicitly name alternatives. The phrase 'one exact team ID' adds precision about the input.

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?

The description provides a useful prerequisite hint: 'Discover team IDs with get_workspace_detail.' This tells the agent how to obtain the required team_id. However, it does not offer explicit guidance on when to choose this tool over alternatives (e.g., get_assignment_detail vs get_team_board) or when not to use it. The usage context is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.