get_context

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

The annotations already establish this as a safe, read-only, closed-world read, so the safety profile is covered. The description adds the 'compact, budgeted' framing and the grouping categories, but does not disclose truncation behavior, what happens when the token budget is exceeded, or any auth/scope requirements – with an output schema present, return shape need not be repeated.

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, no padding, with the substantive characterization of the payload leading and the usage hint trailing. Efficient and front-loaded, though the second sentence could have carried parameter guidance instead of just a preference cue.

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?

An output schema exists, so return values are handled elsewhere, and the description covers the artifact's nature adequately. The gap is parameter guidance for topic/purpose/max_tokens at 0% schema coverage, which leaves an agent guessing about how to steer the result.

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 carries the full burden. It implies topic ('about a topic') and budget ('budgeted'), but never mentions the purpose parameter and gives no format, default, or interaction guidance for any of the three, leaving two of three params only obliquely hinted.

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 states a concrete resource – a compact, budgeted context package grouped into preferences, history, goals and inferences. That level of detail lets an agent picture the artifact without opening the schema, though it never distinguishes itself from siblings like get_recent_context or get_profile.

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?

'Prefer this at the start of a task' gives one concrete trigger point, which is more than nothing. However, it names no alternatives (get_recent_context, get_profile, search_memories are all nearby) and offers no when-not-to-use condition, so the routing decision is only half supported.

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