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

With no annotations, the description carries the burden of behavioral disclosure. It explains what the tool returns, that the result is distilled rather than exhaustive, and that scope controls whose sessions are searched. It does not discuss authentication, rate limits, or edge cases, but for a read-only informational tool the disclosed behavior is sufficient.

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 compact, front-loaded with the tool's purpose, and every sentence contributes either core behavior, usage context, or parameter explanation. There is no fluff or repetition.

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?

The description covers purpose, when to use it, what the output contains, and the main scope parameter, which is adequate for a simple read-only tool with an output schema. The only minor gap is limit semantics and edge cases like files with no prior sessions.

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?

Input schema description coverage is 0%, so the description must compensate. It explains the scope parameter well: 'mine', 'team', 'org', and the omission behavior. It also maps path to the file whose history is briefed. However, the limit parameter has no explanation of how it caps the brief, and path format is not further specified.

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 action and object: 'Return a distilled brief of prior sessions that touched a file', and specifies the returned fields (who, when, a short highlight). It is clearly about file history rather than session text search or session summarization, though it does not explicitly name sibling tools for contrast.

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 gives explicit when-to-use guidance: 'Use before a non-trivial edit to a file you don't already have context on'. It also provides a when-not-to-use rule: 'Do not call this for every file you read; only when prior history is actually likely to change your approach.' This is strong usage routing even without naming sibling alternatives.

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 no annotations, the description carries the full burden of behavioral disclosure. It discloses result capping ('Results are capped at 100'), date inclusivity/exclusivity, default scope behavior, and the special provider='codex' mapping. It does not discuss ordering or output format, but an output schema exists and the tool is a read-style listing.

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 compact and front-loaded with the essential purpose. Every sentence adds distinct value: purpose, when to use, when not to use, special provider handling, date semantics, and scope behavior.

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 15-parameter filtering tool with no annotations and no schema descriptions, the description is unusually complete. It covers selection criteria, exclusion criteria, date/scope/provider nuances, and result limits; the existing output schema covers return shape.

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 compensate. It explains the non-ovious semantics of scope, date_from/date_to, provider, and the minimum-count/code-change filters. It does not individually explain limit, file_path, model_family, or include_changed_files, but these are fairly inferable and the schema provides titles.

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 opens with a specific verb and resource: 'List sessions by metadata using authoritative Postgres filters, without semantic search.' It also explicitly distinguishes itself from the sibling search_sessions, so an agent can tell them apart without inspecting schemas.

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 provides explicit when-to-use guidance ('Use when the user provides no semantic text query...'), what not to do ('Do not invent search text'), and names the alternative tool for semantic-topic queries ('use search_sissions'). It also covers date semantics and scope behavior.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the primary output ('summary metadata and a frontend link') and implies a read-only retrieval, but it does not mention error behavior, authorization requirements, or what happens when an ID does not exist.

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 two sentences with no filler. The core function is front-loaded, and the usage constraint is stated separately and clearly. 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?

Given the tool's simplicity, one required parameter, and the presence of an output schema, the description is nearly complete. It explains what the tool returns and when to use it. The only notable omission is behavior for invalid or missing session IDs, which is a minor gap for a direct lookup 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 description coverage is 0%, so the description must compensate for the undocumented session_id parameter. It adds that the parameter is a ReclaimLLM session ID and that it should be a specific identifier, but it does not specify format, source, or examples. This is adequate for a single self-explanatory parameter but not rich.

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 ('Return summary metadata and a frontend link') and the target resource ('a specific ReclaimLLM session ID'). It distinguishes get_session from listing/searching tools by emphasizing lookup by ID, though it does not explicitly contrast with the sibling summarize_session.

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 provides an explicit use condition: 'Use only when the user asks to look at a particular session by ID.' This is clear guidance, but it does not name alternative sibling tools or explain when a different tool would be more appropriate.

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?

No annotations are provided, so the description correctly carries the burden of behavioral disclosure. It states that the tool does not end the current session and explains fallback resolution via CLAUDE_SESSION_ID. It also clarifies that the output is a paste-ready markdown document, which is important for setting expectations.

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 well-structured and front-loaded: purpose first, then use cases, then parameter resolution, then output behavior. Every sentence adds value and there is no redundant filler or repetition of the tool name.

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?

The description covers the main workflow and output format, and an output schema exists, so return values are handled. However, two parameters remain under-specified and there is no comparison with sibling tools like transfer_session. For a tool with no annotations and zero schema param descriptions, this is a noticeable completeness gap.

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 needed to compensate for all three parameters. It only explains session_id behavior; include_diffs and max_diff_lines are left entirely to inference from their names and defaults. An agent cannot tell what 'diffs' refers to or how max_diff_lines caps the output.

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 identifies the tool's purpose: packaging a session's state into a compact continuation document for a new session. It names a specific verb and resource, and the phrase 'for starting a fresh session' distinguishes it from plain session retrieval. It does not explicitly contrast it with sibling tools like transfer_session, so it falls short of full differentiation.

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 gives explicit conditions for use: long sessions, expensive context, or user phrases like 'continue this in a new session.' It also explains how session_id resolution works, which is practical guidance. However, it does not mention when to avoid the tool or recommend an alternative sibling, so it lacks full exclusion 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?

No annotations are provided, so the description carries the behavioral burden. 'List' implies a non-mutating read operation and 'deterministic' adds some useful context, but it does not explicitly state side-effect-free behavior, authorization needs, or other operational traits.

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 two succinct sentences with the core purpose front-loaded and the usage condition stated immediately. Every word 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?

For a zero-parameter listing tool with an output schema present, the description is largely sufficient. It names the resource scope and when to call it, though it relies on the output schema for return details and omits any mention of prerequisites or failure modes.

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 input schema has zero parameters, so there is nothing for the description to document. The 0-parameter baseline of 4 applies; the description does not need to add parameter meaning.

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 tool 'List deterministic ReclaimLLM CLI project names', providing a specific verb and resource. It distinguishes from sibling session-oriented tools by focusing on projects, though it does not explicitly name an alternative.

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 phrase 'Use only when the user asks to see available projects' gives an explicit trigger condition and a mild restriction. It does not mention alternative tools or when not to use it beyond 'only when', so it stops 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?

With no annotations provided, the description carries the full burden, and it delivers: it declares 'Strictly read-only', explains the fetch-once-and-reuse behavior, discloses the default config-set behavior when configs is omitted, and exposes the surprising min_turns/min_tool_calls default of 5/5 versus the PRD's 10/10. It even notes where this appears in output ('reported in each config row's provenance').

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?

Every sentence carries distinct information: purpose and example, read-only guarantee, configs format and default, corpus selection reference, and floor overrides with provenance note. The description is dense but well-organized, front-loading the core purpose and behavior before parameter details.

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?

The description covers the essential behavior, all parameter groups, defaults, and output provenance for a tool with 9 optional parameters and a non-trivial configs structure. The only notable gap is that corpus-selection parameters are documented by reference to replay_corpus rather than described inline, and there is no mention of potential errors or limit semantics, though an output schema exists to fill in return details.

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 compensate. It does for the complex configs parameter with a concrete example and default behavior, and for min_turns/min_tool_calls with floor values and PRD context. The corpus-selection parameters (days/source/model_family/project/session_category/limit) are grouped and delegated to 'same as replay_corpus' rather than individually explained, which is helpful but not fully self-contained.

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 first sentence states a specific verb and resource: 'Replay the same session corpus under multiple mechanism configurations in one call'. It also names the exact purpose and outcome ('so bundles stay attributable') and gives a concrete comparison example. This clearly distinguishes it from siblings like replay_corpus and replay_session by its multi-config focus.

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 establishes clear context: you use this tool to compare multiple mechanism configurations in a single read-only call, with an explicit example. It references replay_corpus for corpus-selection semantics, implying a shared/different usage pattern, but it never explicitly states when to use replay_compare instead of replay_corpus or replay_session, nor gives a when-not-to-use exclusion.

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 no annotations, the description carries the burden and does well: it discloses strict read-only behavior, exact rolling ingestion window semantics, model-name constraints for source='codex', the scan cap of 4x limit, and result reporting of considered vs eligible sessions. Minor gap: it doesn't state whether results are returned incrementally or only when complete, and doesn't detail output shape beyond provenance, but an output schema exists.

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 compact for 9 parameters and uses multiple sentences purposefully. It front-loads the core purpose and read-only nature, then explains key parameters in order. The PRD floors aside is slightly dense but valuable. Not every parameter gets an example, but no sentence is wasted.

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 complex retrieval/replay tool with 9 optional parameters, no annotations, and a rich output-schema, the description is thorough. It covers the selection algorithm, eligibility thresholds, and provenance reporting. The presence of the output schema fills return-shape details, so the description is complete enough for an agent to invoke 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 compensate. The text explains days, source, model_family/project/session_category, limit, min_turns/min_tool_calls, and mechanisms implicitly. It grounds the default floors (5/5) against PRD §6's documented floors (10/10). It omits a detailed explanation of 'mechanisms' and 'project' semantics, but given the filter set is mostly intuitive, the description adds substantial meaning over 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 begins with a specific verb and resource ('Reproduce the shipped compression mechanisms... report the aggregate real tool-result token reduction'), clearly distinguishing it as a batch replay/evaluation tool over a corpus. It also contrasts with siblings like replay_session and replay_compare by its corpus-wide aggregate focus.

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 explicitly explains when to use the tool, how the corpus is filtered, and which parameters narrow it. It communicates the relationship between the 'limit' parameter and scan behavior, the default vs PRD floors, and includes exclusions ('why the rest were excluded'). While it doesn't name an alternative tool explicitly, it provides clear and detailed guidance on invocation context.

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 no annotations provided, the description fully carries the behavioral disclosure burden. It states the operation is cheap and read-only, never fetches the full session blob, checks only metadata, always returns a funnel of considered vs excluded sessions, and explains the min_turns/min_tool_calls tradeoff. This is exemplary transparency.

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 paragraphs, each earning its place: purpose and cost, invocation modes and output semantics, and parameter override caveats. The most important information is front-loaded in the first sentence, and the guidance is dense without being repetitive.

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 9-parameter tool with no annotations, the description provides complete enough context: when to call it, how to use both modes, what it checks, what it returns, and what caveats apply to parameter overrides. The existence of an output schema further reduces the need to explain return details.

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 compensate. It gives meaningful semantics for session_id, min_turns, min_tool_calls, and the shared corpus filter set (days/source/model_family/project/session_category/limit) by referencing replay_corpus. It doesn't individually describe every parameter's allowed values or defaults, but the grouped reference is useful enough for correct invocation.

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: it checks whether replaying compression mechanisms on captured sessions is worth doing. It clearly distinguishes itself from sibling tools by naming replay_session and replay_corpus as the follow-up actions it pre-empts.

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 says 'call this before replay_session or replay_corpus' and explains the two invocation modes: pass session_id for a single session, omit it for a corpus window using the same filters as replay_corpus. It also warns against loosening filters to force a non-finding, which is strong usage 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?

With no annotations, the description fully carries the behavioral burden. It explicitly discloses read-only constraints ('no model calls, no writes, no re-execution'), defaulting behavior, refusal with verdict 'insufficient_data', and override semantics. This is exemplary transparency beyond the structured schema.

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, followed by safety and parameter behavior. Every sentence adds useful information, and the dense but organized structure avoids waste.

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 tool with no annotations and an output schema, the description covers purpose, safety, defaults, failure behavior, and parameter semantics completely. Nothing an agent needs to invoke it correctly 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 description compensates fully: it explains session_id's default, mechanisms' default values and subset usage, and min_turns/min_tool_calls overrides with PRD context. Every parameter receives meaningful semantic clarification.

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 ('Reproduce'), precise resource ('one captured session's tool calls'), and measurable outcome ('report the real tool-result token reduction'). It distinguishes itself from sibling replay tools by scoping to a single session and compression mechanisms, so an agent can tell what it does without opening the 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?

Provides clear context: which session is used by default, how to isolate a mechanism, and how threshold overrides work. It does not explicitly name sibling alternatives or state when not to use this tool, but the usage context is specific enough to guide selection.

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 no annotations, the description carries the behavioral burden and does so thoroughly: date_from is inclusive, date_to is exclusive, dates use YYYY-MM-DD ingestion dates, scope has defined values and a fallback default, and the tool is positioned as a non-final step. This is substantive operational context beyond what the schema exposes.

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 purpose and usage, and every sentence adds operational value. It is slightly longer than strictly necessary due to multiple prose paragraphs, but the density of useful guidance is high.

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 6-parameter tool with no schema descriptions, the description covers the core filtering semantics and workflow. It is incomplete only on limit, project_name, and exact/path-matching behavior, which would make invocation fully unambiguous.

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 meaningfully explains file_path, date_from, date_to, and scope semantics (inclusivity, format, allowed values, default). However, schema description coverage is 0%, so the description is the only semantic source, and it omits limit and project_name entirely, leaving two of six parameters under-specified.

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 opens with a specific verb and resource ('Find prior sessions') and makes clear the input is a file or folder path. It distinguishes itself from search_sessions by contrasting semantic-term queries with path-only queries, so an agent can identify the right tool immediately.

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 states when to use this tool ('Use when the user asks for changes/history for a specific file or folder and does not provide separate semantic search terms') and when not to ('use search_sessions with file_path instead'). It also documents the follow-up workflow (second step after search_sessions) and warns not to auto-call summarize_session.

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 no annotations present, the description carries the full burden and delivers: it discloses date inclusivity/exclusivity, scope clamping behavior, ownership metadata in results, and the return contents. It also warns agents not to automatically call summarize_session afterward, which is a behavioral guardrail beyond what structured fields would indicate.

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 longer than the ideal two-sentence form, but the length is justified by the tool's complexity and the need to document ambiguous parameters and sibling routing. It is well-structured: purpose first, then usage conditions, parameter semantics, and follow-up guidance. A few sentences could be tightened, but none are 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?

Given seven parameters, no annotations, and multiple sibling tools, the description is remarkably complete. It covers when to use the tool, how to handle each parameter, what the backend does, what results look like, and how to continue the workflow with search_by_filename. The presence of an output schema also means the return-value description is a bonus, not a requirement.

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 compensate for all seven parameters. It does so well for file_path, scope, date_from, date_to, project_name, and query implicitly via 'by intent'. The only omitted parameter is limit, which is left to inference from 'Returns ... up to three changed source files' despite being a tunable result cap.

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 opens with a specific verb and resource: 'Search prior ReclaimLLM sessions by intent using backend hybrid semantic plus BM25 search.' It clearly distinguishes this tool from search_by_filename and other siblings by focusing on semantic intent search, so an agent can tell it apart without inspecting schemas.

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 explicitly states when to use this tool ('when the user hints that similar prior work may exist' or for bug fixes/performance improvements), when not to retry, and names the alternative tool for file/folder history searches (search_by_filename). It also gives follow-up guidance to use search_by_filename on returned changed_files paths, which is unusually actionable.

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?

Although no annotations are provided, the description compensates fully by stating the operation is read-only, changes nothing, and returns up to 5 open signals with pattern/evidence/projected savings. It also documents the cwd resolution behavior when omitted. This is more behavioral transparency than most tool descriptions 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?

The description is compact, front-loaded with core purpose, and every sentence adds value: usage conditions, return shape, side-effect caveat, and cwd behavior. No fluff or redundancy.

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 tool's simplicity — one optional parameter, no required parameters, an output schema present, and read-only semantics — the description covers all needed context: when to call, what it returns, that it has no side effects, and how the parameter behaves.

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?

While schema description coverage is 0%, the description does compensates for the single cwd parameter by explaining the default resolution behavior. It does not fully specify what the cwd value means when provided, but the parameter name and the fallback explanation are sufficient for an agent to use it correctly in most cases.

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 identifies the action ('Open workflow-efficiency Signals') and the exact resource scope ('current project and the caller's own account'). It also distinguishes itself from generic status queries by limiting use to cost/efficiency questions, making it easy for an agent to tell apart from siblings like get_session or search_sessions.

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 provides explicit conditions for use: when the user asks why a session/project is expensive, when workflow efficiency issues are implied, or when ReclaimLLM Signals are explicitly requested. It also explicitly excludes general status checks, giving the agent clear and actionable 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?

With no annotations, the description carries the transparency burden. It adds useful context about the backend export-context flow and the output form, but it does not disclose side effects (e.g., whether force_regenerate mutates cached state), performance, or permission implications.

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 two short sentences, front-loaded with the main purpose and followed by guardrails and examples. Every sentence adds necessary guidance, 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?

The output schema covers return-value structure, and the usage preconditions are clearly stated. However, with no annotations and opaque parameters, the description is not complete for an agent deciding among siblings such as get_session or understanding force_regenerate behavior.

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 description does not explain any of the four parameters. The examples only imply that session_id identifies a session; include_diffs, max_diff_lines, and force_regenerate are left entirely to inference from their names and defaults.

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 uses a specific verb and resource: 'Return reusable markdown context for a ReclaimLLM session.' It clearly conveys the tool's function and differentiates it from search/list siblings by focusing on export-context output, though it does not name a sibling 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?

It gives explicit trigger conditions with example phrases and a negative instruction: 'Do not infer this request from search results alone.' It lacks an explicit mention of alternatives, so it doesn't fully meet the highest bar.

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 no annotations, the description carries the full behavioral burden and does so thoroughly: it states what the returned artifact contains, what it cannot do (restore provider-private runtime state), and that historical tool calls are read-only and must not be executed automatically. This is a strong safety and limitation disclosure.

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 three sentences, front-loaded with the core purpose, followed by usage constraint, then content/limitations/safety. No filler or repetition.

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?

The tool is low-complexity (one parameter, output schema present), and the description supplies all needed behavioral context: when to use it, what it returns, what it cannot preserve, and a safety warning. Nothing essential is missing for an agent to 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 description coverage is 0%, and the description adds no guidance on session_id despite being the only and required parameter. It never explains where to obtain the session_id or how it is validated, so the description does not compensate for the schema's minimal 'Session Id' text.

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 opens with a specific verb ('Download') plus a precise resource ('the full captured session') and outcome ('secure local artifact for another AI tool'). It also contrasts with 'a summary', which distances it from summarize_session and other retrieval siblings.

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 invocation condition ('Use only when the user explicitly asks to move or load the whole session rather than a summary'). However, it does not name sibling tools like get_session or summarize_session as alternatives, so agents must infer the routing boundary from context.

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