lcm_describe

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.