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

With no annotations, the description carries the full disclosure burden, and it discloses almost nothing: it doesn't say whether this is a read-only lookup, what happens with an unknown id, or what the metadata contains. The only behavioral hint is that two entity types (session, summary) are addressable.

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 single clause is front-loaded and contains no filler, but it is sized for a much simpler tool than a two-parameter metadata lookup with zero schema documentation. Brevity here reads as under-specification rather than economy.

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?

No annotations, no output schema, and no parameter descriptions mean this one fragment must carry everything, and it doesn't. An agent cannot determine exclusivity rules, return shape, or how this differs from sibling metadata tools.

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 the description only vaguely implies the two parameters map to 'session' and 'summary'. It never says the parameters are optional, whether they are mutually exclusive, what happens if both or neither are supplied, or what identifier format is expected.

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 resource ('structured metadata for a session or summary') and the tool name supplies the verb 'describe', so an agent can infer this retrieves metadata. But it never states that it returns/describes data, and it gives no differentiation from siblings like lcm_status or lcm_recall, which also sound like metadata readers.

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?

There is no when-to-use guidance, no prerequisite, and no mention of alternatives among lcm_expand, lcm_recent, lcm_status, lcm_grep, or lcm_recall. The only implicit signal is that it targets a session or summary rather than a search or listing operation.

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, and it only discloses the return-shape branching for summary expansion. It says nothing about the raw message expansion path implied by session_id/message_seq, the 2000-character cap, offset paging, or whether the operation is read-only. That leaves a mutation-free but behaviorally nontrivial tool under-described.

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?

One sentence, front-loaded with the action, using a parallel two-clause structure that maps cleanly onto the two branch outcomes. No filler and nothing buried.

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 main summary-expansion semantics are complete enough to call correctly, and the schema documents the raw-expansion parameters at full coverage. Still, the description never acknowledges that two distinct invocation modes exist or that results are paged, which an agent needs to interpret a truncated response.

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 100%, so each parameter is already documented in the schema; the description adds only the conceptual link between summary_id and which result set comes back. It contributes no format, constraint, or mutual-exclusivity guidance beyond that baseline.

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?

A specific verb ('drill into') applied to a specific resource ('a summary'), with the two outcome branches spelled out (leaf → source messages, condensed → parent summaries). It is distinguishable from lookup-style siblings like lcm_describe or lcm_grep, though it never names them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the reader infers this is the tool to use once they hold a summary id and need to go one level deeper. There is no explicit when-to-use versus lcm_describe/lcm_recall/lcm_grep, and no statement of preconditions.

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. It usefully discloses the search mechanism (FTS5 with literal substring fallback) and return shape (snippets with session/summary references), but it omits ranking behavior, case/substring semantics, ordering, and confirmation that the operation is read-only.

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 tight sentences with no filler. The core mechanism, scope, and return format are front-loaded and easy to parse.

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 low-complexity three-parameter search tool, it covers what is searched and what is returned adequately. However, the absence of annotations and lack of sibling-routing guidance leave the agent without enough context to confidently choose lcm_grep over lcm_recall or lcm_recent.

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 100%, so the schema already defines query, limit, and session_id. The description adds no parameter-level meaning beyond what the schema provides.

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 and resource: lexical search across messages and summaries, with deterministic fallback. It is clearly a search tool and distinguishable from siblings like lcm_recent and lcm_expand, though it does not explicitly contrast with lcm_recall.

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 FTS5 lexical search framing implies a keyword/exactish search use case, but the description gives no explicit when-to-use guidance, exclusions, or comparison to alternatives such as semantic recall or recent-message listing.

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 must carry the behavioral burden. It usefully discloses the lexical FTS5 search behavior, literal substring fallback, and searchable corpus, but it does not explicitly state that the operation is read-only or describe result ordering, output shape, or limitations.

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 definition is a single efficient sentence with no filler. It is front-loaded with the retrieval mechanism, though the dense technical phrasing could be slightly clearer for an agent.

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 simple two-parameter retrieval tool with fully documented schema fields, the description covers the search mechanism and corpus. However, it omits return format, result ordering, and sibling differentiation, which are relevant because no output schema or annotations are provided.

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 100%, so the schema already documents both query and limit. The description adds corpus context but no additional parameter-level meaning, making the baseline 3 appropriate.

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 retrieval mechanism and corpus: lexical FTS5 recall with substring fallback across retained summaries and raw messages. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools such as lcm_grep or lcm_recent.

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 no explicit guidance about when to use this tool rather than lcm_grep, lcm_recent, lcm_expand, or lcm_describe. The query parameter's text hints at remembering, but the description itself leaves usage selection 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?

No annotations are provided, so the description carries the full behavioral burden, yet it only states that results are recent activity across sessions. It does not clarify read-only/non-destructive behavior, output shape, pagination or limit behavior, or what 'activity' includes.

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 a single front-loaded sentence with no filler. It is appropriately short for a simple two-parameter tool, though its brevity contributes to gaps elsewhere rather than wasting words.

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 low complexity, two optional parameters, and high schema coverage, the description is minimally adequate. However, without annotations or an output schema, it should do more to explain what recent activity is returned and how the tool differs from its siblings.

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 100%, and both parameters are fully documented in the schema. The description's phrase 'time window' loosely maps to the hours parameter but adds no syntax or semantic detail 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 identifies a scope—recent activity across sessions within a time window—but 'activity' is vague and it does not differentiate itself from siblings such as recall, grep, or status. An agent can tell it is a recent-data tool, but not precisely what data or operation is involved.

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?

There is no explicit guidance on when to use this tool versus lcm_recall, lcm_grep, or lcm_status. The time-window framing implies a recency use case, but no alternatives or exclusions are named.

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 supplied, so the description carries the full burden. It does communicate that this is a non-mutating inspection covering two axes (health and storage), which is enough to signal low risk, but it says nothing about cost, permissions, or whether the check can fail or time out.

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 front-loaded sentence with the resource and the two status dimensions, and no filler. It is efficient, though its brevity is partly under-specification rather than pure economy.

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-param diagnostic tool with no annotations and no output schema, the description leaves open what 'health and storage' actually returns (index size? record count? backend availability?). It is adequate to recognize the tool but not complete enough to predict its response.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool applies. The description adds no param detail because 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?

The description names a specific resource (the codex-lcm memory database) and a specific concern (health and storage status), which clearly distinguishes it from the sibling retrieval tools like lcm_grep or lcm_recall. It stops short of explicitly contrasting itself with those siblings, but the verb+resource pairing is unambiguous.

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?

There is no statement of when to call this versus the other lcm_* tools, nor any precondition such as 'call before lcm_recall to check the index is healthy'. Usage is only inferable from the word 'status' in the name and description.

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