memory_toolset

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

Annotations already disclose the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the bar is lower. The description adds genuinely useful behavior beyond that: the one-step-per-expand constraint and the important caveat that 'list_changed_sent' means the notification was sent, not that the client refreshed. It does not address persistence/session scope of the tier change, which is a minor gap.

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?

Purpose is front-loaded in the first clause, and the tier contents follow before the workflow caveats. It is dense and multi-clause (slightly heavier than needed), but every sentence carries operational value and nothing is pure filler.

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?

An output schema exists, so return-value explanation is rightly omitted. The description covers tier transitions, what each tier adds, notification semantics, and the mismatch-handling rule, which is thorough for a one-param state-change tool. It could note whether tier state is session- or server-scoped, but nothing essential for correct invocation is missing.

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 0% and the single 'action' param has only an enum, so the description must carry the meaning. It does: expand, collapse (steps down), and status ('shows the current tier and what each tier adds') are each explained, compensating well for 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 states a specific verb (change) and resource (server-visible tool tier) and enumerates the three actions (expand, collapse, status) plus what each tier adds. This is a meta-tool whose purpose is unmistakable against the memory_* and document_* siblings, which it explicitly manages visibility of rather than being one of them.

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?

It gives operational when-to-use guidance (one step per expand, collapse steps down) and an explicit when-not/exclusion: 'do not keep expanding' when a named tool is still absent. It also routes the agent through the post-expand rediscovery workflow and the visibility-mismatch reporting condition, leaving little to inference.

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