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

Goes well beyond the read-only/idempotent annotations: it explains that the time range is applied before similarity ranking, describes the returned timeRange metadata (exact, method, matched), and warns that exact:false with method nearest-100 means unindexed memories inside a large range were skipped and the range should be narrowed. It also notes the indexing latency ('date-indexed within minutes') and the ownership restriction when time is set.

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?

Front-loaded with purpose, then scoping, then the subtle time-range behavior. Dense but nearly every sentence carries distinct operational information; the parenthetical example of a natural-language time query earns its place. It is longer than typical but not padded.

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 a 4-parameter search tool with no output schema, the description covers the tricky parts: filter-then-rank order, the timeRange result fields, and the nearest-100 caveat. It leaves the result shape for a memory itself and the limit parameter's effect unaddressed, but nothing that would cause a wrong invocation.

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 baseline is 3, but the description adds real semantics the schema lacks: project scoping excludes global/no-project memories, and the ordering interaction between time filtering and similarity ranking. It does not discuss the limit parameter, so it does not reach the top of the range.

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 specific verb and resource ('Semantically search memories using natural language') plus the ranking mechanism ('most relevant memories ranked by similarity'). It is clear what the tool does, but it never names or distinguishes itself from close siblings such as muninn_memory_query or muninn_memory_search_tags, so an agent must infer the boundary from names alone.

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?

Gives concrete conditional guidance: pass project to search strictly within a project, omit to search everything, and pass time for a date-range search with an example query. It also discloses the important scoping rule that with time set only your own memories are searched, not team-shared ones. It stops short of naming an alternative tool for structured/tag search.

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