Retrieve recent session notes and summaries for a specified project so you can resume prior coding context while keeping other private sessions hidden.
List legacy notes and summaries visible to this caller; never other private sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | ||
| session_id | No | ||
| project_name | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.8.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden. It says results are limited to what the caller can see, which is a genuine visibility constraint, but it doesn't state ordering (why 'recent'), pagination, permissions, or what 'legacy' implies about freshness. A read tool is low risk, but the description leaves core behavior unexplained.
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 and scope. It is compact with no padding, though the wording is slightly confusing ('legacy notes and summaries' vs the tool name) rather than maximally clear.
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 has three parameters at 0% schema description, no annotations, and an output schema. Even allowing that the output schema covers returns, the description fails to explain the parameters, the meaning of 'recent', or how it differs from sibling session tools, which is too little for a three-parameter listing 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 0%, so the description must compensate and it says nothing about count, session_id, or project_name. An agent cannot tell whether session_id filters to one session, whether project_name scopes the listing, or what count defaults to (the schema shows 3 but gives no meaning). This is the biggest 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?
The verb+resource is 'List legacy notes and summaries', which is specific, but the tool is named list_recent_sessions and the name promises 'recent sessions' while the description talks about 'legacy notes and summaries'. That mismatch leaves the agent guessing which artifact it actually gets. The scope qualifier 'visible to this caller' is useful but the core object is muddled.
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 on when to use this versus siblings such as get_session_handoff, session_status, or query_memory, which all touch session data. The 'never other private sessions' clause is an exclusion but about data visibility, not about when to pick this tool. The agent gets no routing signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.