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

With no annotations, the description carries the burden of behavioral disclosure. It specifies the content of the brief (blockers, obligations, decisions, client asks, dropped attempts) and the fallback behavior when called without a project. While it doesn't explicitly state the tool is read-only, the phrasing 'Call it FIRST' and the absence of any mutating language strongly imply a non-destructive retrieval, which is adequate given the context.

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 well-structured, leading with the core value proposition (what the brief contains) and then the crucial usage directive. It is a bit long (three sentences) but each sentence packs substantive information. The front-loading of the content list and the imperative 'Call it FIRST' makes it efficient and scannable, though it could be tightened slightly without losing meaning.

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?

Since there is no output schema, the description must convey what the agent will receive. It enumerates the brief's contents (blockers, obligations, decisions, client asks, tried/dropped items) and explains the no-project fallback. This is sufficient for an agent to know what to expect and when to use it. It does not describe the exact data structure or fields, but the semantic list is adequate for correct invocation and interpretation.

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 already provides descriptions for both parameters with 100% coverage, so the baseline is 3. The description adds value by explaining that the 'repo' parameter is used by Kika to resolve the engagement automatically, and that calling with no project lists the user's projects. This clarifies the optionality and the resolution mechanism beyond the schema alone, justifying a 4.

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 states what the tool returns: a snapshot of an engagement's status including blockers, obligations, decisions, client requests, and previously tried approaches. It names the resource ('engagement') and the action (retrieve brief), and the emphasis on 'Call it FIRST' establishes its role as a foundational lookup distinct from any modification tool.

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 explicitly instructs to call this tool first, before planning or changing anything, and explains the benefit: avoiding re-deciding settled matters or contradicting prior calls. It also covers the no-argument behavior (lists the user's projects), giving clear guidance on when and how to invoke it. It does not mention the sibling tool search_memory, but the usage context is so specific that an agent knows exactly when this tool is appropriate.

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