session_context

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It does state a key behavioral trait: combining multiple sources 'into a single token-budgeted response'. However, it does not clarify whether this initialization has side effects (e.g., triggering/generating intentions or predictions) or whether it is purely read-only, leaving some ambiguity.

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 with no wasted words. 'One-call session initialization' is a clear opening that front-loads the core purpose, followed by the concrete list of combined sources and the value proposition of replacing 5 calls.

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?

Given there is no output schema, the description should provide a sense of what is returned; it does list the content categories (search, intentions, status, predictions, codebase context) but not their structure or ordering. With 6 parameters fully documented in the schema and no required parameters, the description is adequate for invoking the tool but not fully complete for understanding response behavior.

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 100%, and parameter descriptions already explain queries, token_budget, include_status, include_intentions, and include_predictions with defaults. The description maps the tool's output categories to those parameters but does not add meaningful detail beyond what the schema already provides, so baseline 3 is appropriate.

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 uses a specific verb and resource: 'One-call session initialization' that 'combines search, intentions, status, predictions, and codebase context'. It clearly distinguishes itself from the individual sibling tools by framing itself as an aggregate replacement, so an agent can tell it apart from search, intention, system_status, predict, and codebase.

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 says 'Replaces 5 separate calls at session start', giving a clear when-to-use context and naming the alternative approach (making individual calls). It lacks explicit when-not-to-use guidance, such as 'if you only need one component, call that tool instead', so it stops short of a full 5.

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