memory_store

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

Annotations already declare the write/non-destructive profile, and the description adds real context beyond them: cross-session persistence, vector-based searchability, per-project_path isolation, and the note that the runtime reports the actual embedding/storage backend. It doesn't state what happens on key collision (the schema's upsert default carries that) or any size/rate limits.

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?

Four short sentences, front-loaded with the core capability and followed by usage constraints. The closing clause about runtime reporting the backend is useful but slightly tangential to the call decision.

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?

For an 8-parameter write tool with no output schema, the description covers purpose, isolation, and safety boundaries but says nothing about conflict/overwrite outcome, growth limits, or the shape of a successful response. Adequate given the rich schema, but there are residual gaps an agent would hit at call time.

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 every parameter including upsert, ttl, namespace, provenance_type, and project_path is already documented in the schema. The description adds only the isolation semantics of project_path and the meaning-search consequence of the stored value, so it sits at the baseline.

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?

States a concrete resource (persistent key-value store with vector embedding) plus the two traits that distinguish it from sibling tools — survives across sessions and is searchable by meaning rather than key/path. It never names memory_search or memory_retrieve explicitly, so routing relies on inference, but the capability boundary is legible.

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?

"Use for project-scoped persistent memory" gives a clear when-to-use, and "Never import personal memory automatically" is an explicit exclusion. It stops short of naming the alternative siblings (memory_search for retrieval, memory_delete for cleanup), so an agent must infer the split.

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