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

Goes well past the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) by disclosing the ephemerality (24h, non-extensible), the one-time secret return of separate read and write bearer tokens with a secrecy/share-only-needed warning, hard quotas, and that no API key or account is required. The one-time credential disclosure is exactly the kind of irreversible behavior an agent must know about.

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 the purpose, then lifetime, model, return values and limits in a compact sequence. The closing 'No API key, no account and no sign up' is borderline promotional but still carries an auth-relevant fact, so only minor tightness is lost.

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?

With only one optional parameter, no output schema and non-destructive annotations, the description covers everything an agent needs: what is created, how long it lives, what comes back (collection_id plus read/write tokens), the secrecy obligation, and the quotas that constrain reuse.

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 coverage is 100%, so the enum and default are already documented; the description adds real meaning by saying the chosen model 'stays fixed for the collection', i.e. the parameter is a permanent commitment rather than a per-call setting.

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 ('Create a collection of short notes') plus the defining capability ('agents search by meaning, across wording and between languages'), which cleanly separates it from siblings like query_semantic_search, add_semantic_search_notes and read_semantic_search.

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 the operative context an agent needs before calling: fixed 24-hour lifetime that cannot be extended, a model choice locked for the collection's life, a 500-note ceiling and a 20-collections-per-IP daily cap. It does not explicitly name the follow-up tool (add_semantic_search_notes) or state when not to use it, so it stops short of full routing guidance.

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