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

Even though annotations already declare readOnlyHint=true and idempotentHint=true, the description adds substantial behavioral context: how relations with since/until are filtered, how half-life decay works exponentially, the specific return fields (dropped, decayed), and the error-handling contract (never raises protocol error, returns a structured error object). This goes well beyond the annotations.

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 and appropriately sized for the tool's complexity. It starts with a one-sentence summary, then details the filtering/decay mechanics, provides an example, gives usage vs. alternative guidance, and covers error handling. Every sentence contributes unique value without redundancy or 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 description covers the tool's core behavior, parameters, return structure, error handling, use cases, and relationship to siblings. Given the complexity of the tool (nested objects, optional decay, error responses) and the available annotations/schema, this description leaves no significant gaps for an agent to misuse the tool.

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 100% coverage for all three parameters, so the baseline is 3. The description enhances this by giving a typical input/output example that ties the parameters together, explaining the effect of half_life_days on confidence (exponential decay), and showing how as_of interacts with the graph. This adds semantic meaning beyond the schema definitions.

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 statement: 'See the memory as it stood on a given day, optionally faded by age.' This specifies the resource (memory graph), the temporal scope (as of a date), and the optional age-fading behavior. It also distinguishes itself from graph_diff explicitly, clarifying its unique purpose among sibling tools.

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 provides explicit usage guidance: 'Use when the answer depends on when you ask. Not for what changed between two points - that is graph_diff, which does not need dates at all.' This tells the agent exactly when to choose this tool over alternatives, including a named alternative and the condition for exclusion.

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