as_of

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

With no annotations, the description carries the full burden. It discloses key non-obvious behaviors: the reconstruction from version history, the distinction between the current query search and historical content, and the indication of superseded/expired memories. This goes beyond a simple 'get memories as of date' statement.

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 with a purpose statement, a behavioral explanation, and a labeled Args list. It is slightly verbose, but every clause adds useful nuance (e.g., 'searched today, content returned as of the date'), so the length is justified.

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 is a complex temporal reconstruction, and the description covers the main aspects: what it does, how it reconstructs, and what parameters are needed. It relies on an output schema (which exists) to detail return structure. It does not mention error cases or edge like invalid dates, but for a read-only query tool it is reasonably complete.

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 has 0% description coverage, but the description explains each parameter in operational terms: date is the reconstruction point, query is an optional filter that is searched today but content returned as of date, project scopes the result, and limit caps the number. This adds meaning beyond the bare schema.

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 an evocative metaphor 'Time-travel: what did the brain believe at a given date?' and then clearly states the tool returns memories that existed in the past with their content as it was reconstructed from non-destructive version history. This is specific and distinguishes it from sibling tools that operate on current state.

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 gives clear context by explaining that it reconstructs a past state, implying use when historical perspective is needed. It does not explicitly name alternative tools or when NOT to use it, but the temporal focus and optional filters make the intended use obvious.

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