Memlord

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

Annotations already indicate destructiveHint=true, so description does not need to repeat destructiveness. It adds useful disambiguation context, but no further behavioral traits beyond what annotations provide.

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?

Two sentences, no filler. First sentence states primary action, second adds optional guidance. Ideal conciseness for a simple tool.

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?

Given simple tool with 2 params and output schema present, description covers core operation and disambiguation. Missing details like permissions or confirmation, but adequate for 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 has 0% description coverage for parameters. Description adds the purpose of workspace (disambiguation), but does not describe name parameter type or constraints, leaving gaps.

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?

Description clearly states 'Delete a memory by name', specifying verb and resource. Sibling tools (get_memory, list_memories, etc.) have different purposes, so no ambiguity.

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?

Description explains when to use workspace parameter for disambiguation, but does not explicitly state when not to use this tool or suggest alternatives like update_memory if deletion is not intended.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces the non-mutating nature by stating it only proposes candidates. It also adds a behavioral detail annotations cannot convey: similar pairs are always within a single workspace and ordered by similarity. It stops short of describing result volume or what the report body contains.

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 what the report contains, then the read-only constraint, then routing guidance — a sensible order. Every sentence carries information, though the fragment-style opening sentence is slightly compressed for the amount of detail it introduces.

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 documentation is unnecessary, and annotations cover the safety profile. Combined with the description's coverage of scope, ordering, read-only behavior, and follow-up routing, an agent has everything needed to call this correctly.

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 67% — `workspace` and `similarity_threshold` are documented in the schema, but `max_pairs` has no description. The description's note that pairs are single-workspace and similarity-ordered adds context relevant to two of the three parameters, but it does not compensate for the undocumented `max_pairs` or clarify threshold/limit semantics beyond the 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 names a specific resource and scope: a report of consolidation candidates consisting of similar pairs plus expired/expiring memories. It clearly distinguishes itself from the sibling memory tools by stating it only proposes candidates while merge/supersede/extend/delete happen elsewhere.

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 explicitly routes the agent: this tool is for reviewing candidates, acting on them uses the regular memory tools, and the full guided procedure lives in the `dream` prompt. Both the alternative and the escalation path are named, not inferred.

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

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

Annotations already establish the safe read profile (readOnlyHint=true, destructiveHint=false), but the description adds a genuinely non-obvious behavior: this lookup returns expired memories that search hides, and tells the agent how to detect (expires_at) and remedy (update_memory) that state. It does not cover permissions, pagination, or duplicate-name behavior, so it falls short of a 5.

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 core action, then usage, then exclusions in short scannable clauses. Every sentence carries actionable content — positive precondition, negative routing, and the expired-memory caveat — with no 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 unnecessary, and the description covers selection criteria, alternatives, and the expired-memory edge case. The only real gap is the unexplained 'workspace' parameter, which prevents a 5.

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?

With 0% schema description coverage, the description carries the full burden, and it does clarify that 'name' is a memory identifier sourced from retrieve_memory/recall_memory results. However, the optional 'workspace' parameter is never mentioned in the description or the schema, leaving its scope and default semantics unexplained.

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 ('Fetch full content of a single memory by name') and immediately contrasts itself with the two nearest siblings, retrieve_memory() and recall_memory(). An agent can distinguish this tool from search-style siblings without opening any schema.

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 an explicit precondition ('Use only when you already know the name'), names where names come from ('after retrieve_memory() or recall_memory()'), and states an explicit when-not with the correct alternatives for both semantic/text search and time-based queries. Nothing is left to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavior beyond that: result ordering (newest first) and that full content is returned rather than snippets. It says nothing about pagination limits or result volume, which would have been the last piece.

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?

Two sentences, zero filler. Ordering and return format come first, and the intended use case is stated last in a single compact clause.

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 values need not be re-explained, and the description still helpfully characterizes them as full content. For a read-only list tool with annotations covering safety, the only real omission is pagination guidance for the otherwise-undocumented page/page_size parameters.

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 only 25%: tag and memory_type are documented in the schema, but page and page_size carry no descriptions. The description adds no parameter information at all — notably it never mentions that results are paginated or how page/page_size interact — so it fails to compensate for the documented coverage gap.

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 (browse/enumerate) and resource (memories), plus concrete scope details: ordered by creation date newest-first and full content rather than snippets. The phrase 'without a specific query' implicitly separates it from query-driven siblings like search_by_tag or recall_memory, though no sibling is named.

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 a clear use case ('Use to enumerate or audit without a specific query'), which tells the agent when this tool is appropriate versus retrieval/search tools. It stops short of naming specific alternatives or explicit when-not conditions, so it falls just short of a 5.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false. Description adds that it lists workspaces the user is a member of (personal + shared), providing context beyond annotations. No contradictions.

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?

Single sentence, front-loaded, no wasted words. Perfectly concise.

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?

Tool has no parameters, has output schema, annotations cover safety, description covers purpose and scope. Complete for a simple read-only list tool.

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?

No parameters; schema description coverage is 100%. Baseline score of 4 for 0 parameters, as description adds no parameter info but none is needed.

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?

Description clearly states the tool lists all workspaces the user is a member of, specifying personal and shared. Verb 'List' and resource 'workspaces' are precise. Sibling tools are all memory-related, so no confusion.

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?

Description indicates when to use: to list workspaces. No explicit exclusion or alternatives, but given the tool's self-contained nature and distinct sibling set, the guidance is clear.

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

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

Annotations indicate non-destructive, but 'move' typically removes from source. The description adds workspace access requirement but does not clarify if memory is removed from source, potential side effects, or atomicity. There is a mild contradiction with destructiveHint=false.

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?

The description is concise with four lines covering the action and parameters. However, parameter descriptions are listed separately rather than integrated, slightly reducing flow.

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?

While the description covers parameters and basic action, it does not explain return values (despite output schema existing), error cases, or behavior on name conflict. For a 3-parameter tool, this is adequate but not comprehensive.

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?

The description explains each parameter with purpose and constraints (e.g., 'to_workspace: must be a member with write access', 'from_workspace: disambiguate source'). This adds significant value beyond the bare schema, especially with 0% schema description coverage.

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 clearly states the action ('Move a memory') and the target ('to a different to_workspace'). It distinguishes this tool from siblings like delete_memory or store_memory by focusing on relocation.

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 implies usage for moving a memory between workspaces but does not provide explicit guidance on when to use vs. not use this tool, nor does it mention alternatives like update_memory for changing properties.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds one useful behavioral fact – results are truncated to names and metadata rather than full records. It says nothing about result counts, ranking, or pagination beyond that, and an output schema already exists, so a 3 is appropriate.

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 tight lines: capability plus output contract first, then examples, then the escape hatch to get_memory, then the workspace scoping note. Every sentence carries distinct information and nothing is repeated from the schema.

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 an output schema present and annotations covering the safety profile, the description only needs to cover invocation semantics, which it largely does via query format examples, the result-truncation contract, and the get_memory follow-up. The unexplained n_results parameter is the one remaining gap for a search tool.

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 only 25%, so the description must compensate, and it partially does: it explains the query accepts time expressions plus semantics and gives three concrete examples, and it explains the workspace scope parameter. It says nothing about n_results or memory_type, leaving two of four parameters to the schema alone.

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 gives a specific verb and resource (search memories) and narrows scope to time expression + semantics, plus an explicit output boundary (names + metadata only). That output boundary meaningfully separates it from get_memory, which fetches full content. It does not clearly separate itself from the sibling retrieve_memory, which keeps it short of a 5.

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 a concrete follow-up path (use get_memory(name=...) for full content) and a scoping rule (pass workspace=<name> to restrict the search), which tells the agent when to reach for this tool. It lacks explicit exclusions relative to retrieve_memory and list_memories, so it is clear context rather than full when/when-not guidance.

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

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds a genuinely useful behavioral trait beyond the annotations: results are truncated to "names + metadata only," which tells the agent why a follow-up call is needed. It omits pagination/limit behavior and any rate or auth context.

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 short lines, zero filler, and the core mechanism and the "metadata only" caveat are front-loaded before the pointers to the alternative tool. Every sentence earns its place.

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 values need not be described, and the description correctly focuses on routing and scoping. The remaining gap is the undocumented tuning parameters (limit, similarity_threshold), which is the one thing an agent needs before calling this search tool correctly.

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 only 20%, so the description carries the burden for the other parameters. It explains workspace scoping semantics, but says nothing about limit (result count/pagination), similarity_threshold (what it controls or how the default 0.25 behaves), while memory_type is documented only inside the schema enum text. Two of five parameters remain undocumented anywhere.

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 names the retrieval mechanism precisely ("Hybrid semantic + full-text search") and, together with the tool name retrieve_memory, makes the resource unambiguous. It also distinguishes itself from get_memory, so an agent can separate the two siblings without opening schemas. It stops just short of 5 because it never restates the resource explicitly (memories).

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 an explicit alternative and the condition for choosing it: "Use get_memory(name=...) to fetch full content of a specific result," plus a scoping condition for workspace. It does not address other plausible siblings (recall_memory, search_by_tag, list_memories), so coverage is good but not exhaustive.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), but the description adds real behavioral context: no pagination (all results returned) and case-insensitive tag matching. It does not discuss result ordering or limits, but for a read-only search tool this is solid added value.

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 core purpose and the non-pagination caveat, then the operation semantics, then routing to alternatives. Four short sentences, each earning its place with no repetition of the schema.

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 unnecessary, and the description still notes the all-results/no-pagination behavior. Combined with explicit sibling routing and enum semantics, an agent has everything needed to invoke this correctly.

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%, so the description must carry the load, and it does: it defines operation='AND' (default, all tags required) vs 'OR' (at least one tag), and clarifies tags are exact and case-insensitive. Only minor gaps remain, such as the uniqueItems constraint in the 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?

States a specific verb and resource ('Find memories by exact tag match') and immediately narrows scope with 'exact tag match' plus 'Returns all results (no pagination)'. It is clearly distinguishable from retrieve_memory and list_memories, both of which are named explicitly.

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?

Explicitly routes the agent: use retrieve_memory() for semantic/text search and list_memories(tag=...) to browse a single tag with pagination, implying this tool for multi-tag exact matching without pagination. The when-to-use and when-to-use-something-else conditions are both stated.

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

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

Annotations already declare idempotentHint=true and destructiveHint=false, so the baseline is set. The description adds real value beyond them: a near-duplicate check runs by default and is skipped only with force, expired memories remain retrievable by exact name via get_memory, and purging happens through a profile clean-up action. It does not describe return shape, but that is defensible given the idempotency note.

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 one-line purpose followed by compact per-parameter bullets; nothing is wasted. The only blemish is that the workspace and force blurbs are near-verbatim duplicates of the schema descriptions, which is mild redundancy rather than bloat.

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 values need no explanation, and the description covers creation semantics, dedup behavior, workspace scoping, and expiry. It is adequate for an 8-parameter write tool, though it could say more about what content or memory_type should contain and where the sibling update_memory takes over.

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?

With only 50% schema description coverage across 8 parameters, the description must compensate, and it does for the four most ambiguous ones: name uniqueness, workspace membership vs personal-memory default, force semantics, and the expiry lifecycle. content, tags, and metadata are left unexplained, but those are largely self-evident and memory_type carries a detailed enum in the 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 opening sentence gives a specific verb+resource ("Save a new memory") and the word "new" implicitly distinguishes it from the update_memory sibling. However, it never explicitly names or contrasts with update_memory, recall_memory, or retrieve_memory, so an agent must infer the boundary itself.

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 states the tool is idempotent and returns existing content, which implies the caller need not pre-check for duplicates, but it never states when to use this over update_memory for existing memories or why not to use it for retrieval. No prerequisites, exclusions, or alternative routing are given despite ten siblings covering overlapping memory operations.

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

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

Annotations only declare idempotentHint=false and destructiveHint=false; the description usefully adds that unspecified fields are preserved, which is not in the annotations. It still omits what happens on name collision, whether renames are reversible, and why the call is non-idempotent, so it adds partial rather than rich behavioral context.

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 lines, front-loaded with the core action and then one line per non-obvious field. The per-field list is efficient, though the expires_at line is a verbatim restatement of the schema description and earns no new information.

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 unnecessary, and the partial-update rule is stated. For an 8-parameter mutation tool with non-idempotent behavior, the description is still thin on collision/rename semantics and on how content, tags, and metadata interact with existing values.

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 only 25%, so the description carries extra burden. It explains new_name, workspace, and expires_at, and duplicates the schema's expires_at wording, but says nothing about tags, content, or metadata — including whether they replace or merge with existing values, which is the most consequential ambiguity for a 8-parameter tool.

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 ('Update an existing memory') and adds the partial-update semantic ('Only provided fields are changed'), which is a meaningful differentiator from store_memory or delete_memory. It does not, however, distinguish itself from move_memory, which appears to be the natural alternative for changing workspace.

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?

Usage is implied through the field explanations: workspace is described as a disambiguator and expires_at as an extend-or-set action. There is no explicit when-to-use framing, and the workspace note potentially conflicts with the existence of move_memory, leaving the agent to infer which tool performs workspace changes.

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