Skip to main content
Glama
yanqiw

Coordination Memory MCP

by yanqiw

get_attention_board

Rebuild the attention board from the event ledger to see which items require integrator review and which are already accepted for a team and target.

Instructions

Reconstruct Attention for a team and target from the event ledger.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetNohuman
team_idNodefault
include_greenNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.6

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations provided, the description carries the behavioral burden. 'Reconstruct ... from the event ledger' usefully indicates that the result is computed from events rather than directly stored, and 'get_' implies a read-like operation. However, it does not explicitly state side effects, permissions, or how reconstruction treats green items.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single active, front-loaded sentence with no filler; the verb and object come first. It is suitably brief but slightly under-specified, so it does not earn the top score for structure.

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?

The tool is relatively simple and has an output schema, so the description does not need to explain return values. It is adequate for a basic call, but the undefined include_green semantics and the lack of distinction from similar board tools leave clear gaps for an agent choosing and invoking it correctly.

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 needed to compensate by explaining the parameters. It loosely maps 'team and target' to team_id and target, but it says nothing about include_green, which is domain-specific and not self-explanatory. This is only partial compensation for the missing schema descriptions.

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 ('Reconstruct') and resource ('Attention') scoped by team and target, which makes the core purpose clear. It does not explicitly contrast this with the similar get_team_board sibling, so it stops short of full differentiation.

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 phrase 'Reconstruct Attention for a team and target from the event ledger' implies when to use the tool: when a derived attention board is needed. It does not provide explicit when-not-to-use guidance or name alternatives such as get_team_board or raise_attention.

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