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

No annotations are provided, so the description carries the burden of explaining behavior. It goes beyond mere retrieval by disclosing ranking logic ('ranked by risk-if-missed') and content priorities ('Constraints and alerts rank above general knowledge'). This gives a useful sense of how the tool behaves. However, it does not explain token budget semantics or whether the call is strictly non-mutating, leaving some behavioral gaps.

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 compact and front-loaded. The core purpose is stated in the first sentence, followed by one sentence on ranking logic and one on usage context and sibling differentiation. Every sentence contributes meaning with no filler.

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 has three parameters, no annotations, and an output schema that is not shown but known to exist. The description adequately covers when and how to use it, distinguishes it from sibling tools, and gives behavioral context. However, the lack of explanation for two parameters (token_budget and priority_signal) and the absence of annotation-based safety cues leave some completeness gaps.

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?

Schema description coverage is 0%, so the description must compensate. It explains the role of task_description ('shaped by your task description') and hints at prioritization, but it does not explain the token_budget parameter (e.g., how it is used, what happens when exceeded) or how priority_signal alters the ranking. The enum values are self-evident from their names, but overall parameter semantics remain incomplete.

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 opens with a clear, specific verb-noun pair ('Task-scoped context briefing') and explains the resource and behavior: 'Returns a prioritised context payload shaped by your task description, ranked by risk-if-missed.' It also explicitly distinguishes itself from the sibling tool query_memory, so there is no ambiguity about what it does.

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 tells the agent when to use this tool: 'Use at the START of reasoning about a question to get the system's best assessment of what's relevant.' It also names the alternative, query_memory, and explains how they complement each other: 'this gives breadth, query_memory gives depth.' This provides clear guidance on usage vs. alternatives.

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