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

Annotations carry only a title (no readOnlyHint or destructiveHint), so the description must bear the behavioral burden. It discloses scoping ('scoped to your knowledge area') and the return nature ('Returns the most relevant memories you have access to'), which implies a read-only operation. However, it doesn't disclose failure behavior, result limits, authentication needs, or the relationship of kit_session_id to the wake flow. Adequate but not rich for a tool with minimal annotation support.

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?

Three sentences each do distinct work: purpose, usage trigger list, and return behavior. The purpose is front-loaded in the first clause. The middle sentence is long but necessary for conveying the query scope. No filler or redundant restatement of the name or title. Reasonably tight for the information it carries.

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?

There is no output schema, so the description must convey return behavior, which it does ('Returns the most relevant memories you have access to'). All parameters are documented in the schema. For a simple retrieval tool this is mostly sufficient, but it omits details like result ordering, pagination, or the count/limit semantics that an agent might want before invoking. Functional but with visible 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 100%, so the schema already documents all three parameters (query, limit, kit_session_id) with their own descriptions. The baseline of 3 applies. The tool description adds no parameter-specific detail beyond what the schema provides, notably not clarifying the kit_session_id reuse semantics that the schema does mention. No additional value, but no harm either.

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 specific verb+resource: 'Recall this Lady Whiskerdown's knowledge by semantic search.' It clearly states the operation (semantic retrieval) and the target resource (memories/knowledge scoped to the agent's area). It distinguishes itself from the write sibling `remember` by framing itself as a retrieval tool, though it doesn't explicitly name that sibling. Clear and unambiguous.

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 explicit when-to-use guidance: 'Use before answering any user question about this Lady Whiskerdown, the customer/product, project facts, onboarding, architecture, policies, product decisions, or imported documents.' This is a strong list of triggering contexts. It stops short of naming alternatives or explicit when-not-to-use conditions relative to siblings like `wake` and `areas`, so it doesn't reach 5.

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