team_context

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It adds context about 'project and branch attribution stay correct across projects,' implying this tool establishes or maintains attribution. However, it does not state whether the tool is read-only or mutates state, what kind of briefing it returns, or any side effects beyond attribution. This is a partial disclosure.

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?

The description is two sentences long with zero filler. The core purpose is front-loaded, followed by parameter guidance and usage timing. Every word adds value.

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?

The tool is simple (one parameter) and has an output schema, so the return value is already documented. The description covers purpose, when to call, and the parameter's meaning. The only gap is explicit disclosure of whether the tool modifies state (e.g., sets context) beyond the briefing, which would be useful but is not critical given the output schema and clear 'briefing' wording.

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 schema has 0% description coverage, so the description must compensate. It explains project_path: 'Pass the absolute workspace/repo root in project_path' and notes why it matters ('so project and branch attribution stay correct'). This gives meaningful semantic guidance. However, it does not clarify what happens if the parameter is omitted (schema shows it's optional with a default), leaving that ambiguity.

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?

The description clearly identifies the tool as a 'Session-start briefing for the current project.' The verb 'briefing' and resource 'current project' specify exactly what it does. It distinguishes itself from sibling memory tools by its timing ('at every session start') and its role as a briefing, which none of the other siblings (like recall, search_memory, or get_team_status) claim.

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?

The description gives explicit timing: 'Call this FIRST at every session start.' This tells the agent exactly when to invoke it. It does not mention alternatives or exclusions, but the instruction to call it first makes its usage context clear. Since no sibling appears to be a session-start briefing, explicit alternative routing isn't critical.

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