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

Annotations already cover the read-only, non-destructive, closed-world profile, but the description adds real behavior beyond them: output is bounded extracted text with original path and source fingerprint, pagination applies, and four distinct error states must be handled. Missing detail on what 'fresh' means operationally (cache bypass? snapshot semantics).

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 sentences, front-loaded with the identity/precondition and ending with the scope exclusion. Dense but every sentence carries information; style is telegraphic rather than wasteful.

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 needn't be spelled out, yet the description still flags path and fingerprint payload. Error handling and pagination are covered. The gap is pagination semantics and the meaning of 'fresh', which an agent invoking with limit/offset would want.

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 0% and none of the three params (limit, offset, artifact_id) carry descriptions. The description does clarify artifact_id's provenance and implies pagination via limit/offset, which compensates partially, but the pagination mechanics and defaults remain undocumented.

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?

Names a specific verb (fresh read) and resource (artifact id), and explicitly distinguishes itself from the alternative path-based access: 'an id returned by search_local, never an arbitrary path.' An agent can route between this and search_local without opening either 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?

States the precondition that the id must come from search_local and enumerates the error conditions to respect (missing/disconnected/stale/blocked). Also says PDF rendering/download is out of scope, which is a useful exclusion. It stops short of naming a sibling alternative for the PDF case, so not a full 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 declare readOnly/non-destructive/non-open-world, but the description adds genuinely new context: the source 'may be offline' and that snippets are unreliable for amounts/scope. It also hints at the return shape; the output schema already handles return values, so this is a minor redundancy rather than a 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?

Front-loads purpose, then adds query style, then the follow-up instruction, then the sibling routing. Every sentence carries distinct information with no filler, and the critical 'do not answer from snippets' caveat is prominent.

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, the description need not enumerate return fields, yet it briefly does so. Combined with the offline caveat and the read_local_artifact/workspace_recall routing, an agent has everything needed to select and invoke it 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 0% with two parameters (query, limit) documented nowhere structurally. The description gives keyword-style guidance for query ('factual keywords such as ExampleCo 견적서'), but says nothing about the limit parameter or the optional/defaulted nature of query, leaving half the surface undocumented despite the low 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?

States a specific verb ('Find') and resource ('original work documents') and scopes it to 'explicitly allowed local/SSD roots'. It actively distinguishes itself from siblings by naming workspace_recall for session conversations and read_local_artifact for follow-up reads.

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?

Explicit routing: use keyword queries here to find candidates, do not answer from snippets, and instead call read_local_artifact; session conversations route to workspace_recall. Both the when-to-use and the alternatives are named with their triggering conditions.

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?

With annotations covering safety (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description adds substantial context: local-only saving, data hygiene rules (no secrets, personal data, or local paths), idempotency via stable IDs, and non-publishing behavior handled by a scheduler.

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 front-loaded with the core action and then flows through requirements, constraints, and behavior. It is dense but every sentence adds necessary specification, though a bulleted format could improve readability.

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 the output schema and annotations, return values and safety profiles are covered elsewhere. The description thoroughly explains payload structure and behavior, but leaves slight ambiguity about whether the single 'checkpoint' parameter is an object containing the listed keys or a simpler value.

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 sole parameter has no type or description, so the description carries full burden. It enumerates required keys, enums, boolean constraints, and array structures in detail, adding clear meaning beyond the empty 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 (Save) and resource (strict v1 confirmed_summary checkpoint) with a clear exclusion (never raw chat). It distinguishes from publishing and implies difference from recall/read siblings, but does not explicitly name any sibling for routing.

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 implies usage by specifying what to save and what not to save ('never raw chat', 'does not publish'), but gives no explicit when-to-use context or named alternatives to workspace_recall or other siblings.

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, destructiveHint=false, and openWorldHint=false. The description adds the useful constraint that local paths and historical content are not exposed, which is behavioral context beyond the annotations. However, it does not clarify what 'availability and scope' concretely returns or when the check might fail.

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?

A single concise sentence that front-loads the action. It is efficient, though its brevity may contribute to the overall vagueness noted elsewhere.

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 no parameters and an output schema present, the description needn't explain return values. Still, for a health-check tool among several workspace siblings, it should do more to define what is being checked and why an agent would call it, leaving a material gap in distinguishing its role.

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?

There are no parameters, so the baseline is 4. The description does not need to compensate for parameter documentation, and it appropriately focuses on the operation rather than parameters.

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 what the tool checks, availability and scope, but the phrasing is abstract and does not clearly distinguish it from siblings like workspace_recall or workspace_checkpoint. It does not name a specific resource being inspected beyond 'workspace', making the purpose only loosely clear.

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?

No guidance is given on when to use this tool versus workspace_recall, workspace_checkpoint, or the artifact tools. The agent must infer its role from the name alone.

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 readOnly/no-destructive/no-open-world, and the description adds real value beyond them: freshness-checked search of recent and refined memory, an operator-gated fallback to bounded redacted Cold excerpts, and an explicit output limitation (no full sessions or local paths). Terms like 'Cold excerpts' are internal jargon that reduce clarity slightly.

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?

A single dense paragraph that front-loads the trigger conditions and packs fallback/limitation details without filler. Some clauses are run-on and jargon-heavy, but every sentence roughly 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; the description instead covers triggers, search behavior, operator gating, and output limits. It is nearly complete for a single-optional-parameter recall tool, with only sibling routing left implicit.

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 0%, so the description must carry the burden, and it does provide guidance: use factual topic keywords and resolve a missing topic from the conversation or by asking. It stops short of format/examples for the query value.

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 clear verb+resource (recall prior work) and enumerates concrete trigger utterances the user might make, including Korean phrases. It does not explicitly differentiate itself from sibling tools like workspace_checkpoint or search_local, so it falls just short of 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?

Gives strong when-to-use context via quoted user phrasings ('continue a named project', 'where did we leave off') and notes the user need not say 'AI Workspace'. However, it names no explicit alternative or exclusion, leaving sibling selection to inference.

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