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

No annotations are provided, so the description carries the burden. It discloses the sync behavior (local session logs first), which is a side-effect, and notes the private scope. That adds useful transparency beyond a simple list operation.

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 concise sentences with front-loaded purpose and a brief behavior note. No wasted 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?

The description is sufficient for a simple no-parameter tool: it states what it lists and the sync behavior. It doesn't detail output format, but the name and description imply a list of sessions, which is adequate.

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 has 0 parameters, and the description provides no parameter info, but the baseline is 4 for no-param tools as there is nothing to explain.

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?

Description clearly states the tool lists recent agent sessions (Claude Code, Codex) from the user's private corpus, using a specific verb and resource. This distinguishes it from siblings like search_my_sessions and share_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 implies this is the tool for getting a current list of sessions, especially by mentioning the local sync for up-to-date data. However, it doesn't explicitly mention alternatives or when not to use it.

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 discloses key behaviors: short sessions return full transcript automatically, long sessions return summary + recent turns, and the agent MUST ask the user before proceeding on a summary. It also instructs to call again with full=true only after confirmation. 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?

Two sentences, no filler. The purpose is front-loaded, and the conditional behavior is explained in a structured, easy-to-follow manner. Every clause 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?

Despite lacking an output schema and annotations, the description covers the main decision flow, parameter usage, and the critical user-confirmation requirement. It is complete enough for an agent to select, invoke, and correctly handle the tool's results.

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 schema already provides detailed descriptions for both parameters (100% coverage), so the baseline is 3. The description adds contextual semantics by explaining that full=false is the observed behavior for longer sessions and that full=true should be used after user confirmation, going slightly beyond the schema's wording.

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: 'Pull a shared agent session (by share link or token) into the current conversation to continue or build on it.' It clearly distinguishes from sibling tools (list/search/share/unshare) by focusing on importing a shared 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 explains when to use the tool (to continue/build on a shared session) and gives important procedural guidance for short vs. long sessions, including mandatory user confirmation. It does not explicitly name alternatives or state when not to use it, but the context and sibling tool names make the usage clear.

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 burden and does an excellent job. It discloses key behaviors: semantic matching (with example), relevance ranking, a 'why' explanation per hit, result contents (what was asked and a summary), and the privacy boundary ('only the user's own sessions'). This is substantial and goes beyond a minimal tool description.

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 concise sentences: core purpose and semantics, result format, and privacy. Each sentence adds distinct information with no filler. It is front-loaded with the main action and immediately conveys what the tool does.

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 there is no output schema and no annotations, the description adequately covers what the tool does, what results look like (why line, asked query, summary), and the access scope. This is complete enough for an agent to understand when and how to invoke it without missing critical context.

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 schema already documents the 'query' parameter with a helpful description. The tool description adds value by explaining how the query is interpreted semantically (e.g., 'retries' finds 'exponential backoff'), enriching the meaning beyond the schema's literal field description.

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 a specific action (semantic search) over a specific resource (the user's own agent sessions) and differentiates from siblings like list_recent_sessions by emphasizing meaning-based retrieval rather than listing. The phrase 'matches by MEANING, not just keywords' adds a distinctive feature that sets it apart.

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 that this tool is for finding sessions by meaning or topic, with a note about privacy. It does not explicitly list alternatives or exclusions, but the context distinguishes it from the sibling tools (list, share, unshare, pull), and the description implies it is the go-to for semantic discovery of past sessions.

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 discloses key behavioral facts: the link is not read-only, anyone with it can pull full session content into their own agent, explicit user consent is required, and the link is revocable. This exceeds typical transparency 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 concise and front-loaded with the core purpose. Each sentence adds valuable context (non-read-only nature, consent requirement, revocation), with no wasted 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?

For a simple one-parameter tool with no output schema, the description covers purpose, usage conditions, behavioral implications, and revocation. It doesn't explicitly describe the return value, but 'Mint a public share link' implies the response contains the link. Minor gap, but overall complete.

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 100% for the single session_id parameter, with a clear description of where to get it (from list/search results). The description adds minimal extra meaning beyond confirming it's one of the user's sessions, so baseline 3 is 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 clearly states 'Mint a public share link for ONE of the user's sessions' with a specific verb and resource. It distinguishes itself from siblings by emphasizing the sharing action and contrasting with unshare_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?

Provides explicit when-to-use guidance: 'ONLY call this when the user has explicitly asked to share a session' and 'Never call it proactively.' It also references the revocation alternative unshare_session, giving clear context and exclusions.

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 discloses a key behavioral trait: the link stops working immediately. However, it omits other potentially relevant details such as irreversibility, permission requirements, or whether the session itself is affected. This is acceptable for a simple tool but lacks depth.

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, concise sentence that is front-loaded with the action and effect. Every word earns its place, with no 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?

The tool has only one parameter, no output schema, and no annotations, so the description needs to convey the core behavior, which it does. It would benefit from a note about whether the action is reversible or affects the session itself, but for a simple revocation it is largely complete.

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 baseline is 3. The description does not add meaningful parameter details beyond what the schema already states ('the session_id to unshare'), and the only clue is that the session_id corresponds to a session with a share link.

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 'Revoke' and identifies the resource as 'a session's share link', clearly distinguishing it from sibling tools like share_session. It also states the immediate effect, making the purpose explicit and 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?

The description clearly implies when to use the tool (to stop sharing a session) and contrasts with share_session through the verb 'revoke'. However, it does not explicitly name alternatives or exclusions, so it falls 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.