Check live team status before starting work: see who is online, current tasks, master prompt state, assigned work, pending questions, and recent changes.
See what your team is doing right now: who is online and on which task, the master prompt's state, your tasks, questions waiting for you, and what changed since you last looked. Call it at the start of a session and before starting new work.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does convey that this is a read-style "see" operation and that it tracks diffs ("what changed since you last looked"), implying stateful/cursor semantics. However it never states the safety profile explicitly (read-only, non-mutating, no side effects) nor output format or paging behavior, leaving meaningful behavioral gaps for an annotation-free tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with what the agent gets back followed by when to call it, with no filler. The content enumeration is somewhat long but each item earns its place by telling the agent what the snapshot contains.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description does the necessary work of enumerating the returned items and the call timing. It is largely complete for a zero-parameter read tool, with only the safety/read-only framing and any size or freshness limits left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4 per the rubric. The description rightly spends its words on returned content instead of inventing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb-and-resource pair ("See what your team is doing right now") and enumerates the returned surface: presence, current task, master prompt state, your tasks, pending questions, and diffs. This clearly reads as a read-only snapshot, distinguishing it in kind from the action siblings (team_ask, team_post, team_reply), though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete invocation triggers: "Call it at the start of a session and before starting new work." That is clear when-to-use guidance. It stops short of naming alternatives or stating when not to call it, so it does not reach the 5 tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.