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 explains that events are recorded for future AI sessions, implies persistence, and sets explicit content boundaries (what to include and exclude). It does not mention side effects like overwrite or error behavior, but for an append-style event logger the core behavior is clearly communicated, making this a strong but not perfect 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 moderately long but every sentence contributes value, covering purpose, usage, and exclusions in a logical flow. It is front-loaded with the core purpose and then branches into details. While a bit verbose, it avoids redundancy and is well-structured, earning a 4 rather than a 5 for being slightly over-explanatory.

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 has 6 parameters, 2 required, and no output schema, the description provides comprehensive context. It tells the agent exactly when to invoke the tool, what content qualifies, which event types to use (with special emphasis on user_message), and what to avoid. There is no missing information an agent needs to call it correctly; the lack of output schema is acceptable for an append-only logger.

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?

Even though the input schema already covers all parameters with 100% description coverage, the description adds substantial extra semantics. It elaborates on the event_type parameter, specifically clarifying the intended use of 'user_message' for meaningful user-provided facts, requirements, and context, and gives guidance on the content parameter by instructing proactive capture. This enriches the schema's definitions and helps the agent select appropriate values.

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 records important events for future sessions, enumerates concrete event categories (decisions, bugs, test results, TODOs, discoveries, commands, state changes), and explicitly differentiates meaningful content from trivial chatter. It distinguishes itself from sibling tools by focusing on generic event logging rather than specialized ones like file changes or memory updates.

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: 'Use during work for meaningful decisions, bugs, test results, TODOs, discoveries, commands, or state changes.' It also gives clear exclusion rules: 'Do NOT record trivial conversation (hello, thanks, okay) or private chain-of-thought.' Furthermore, it instructs proactive capture of user-provided information without requiring the user to ask, which is actionable and specific.

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 explains what a snapshot is and what content it should include, but doesn't disclose whether the snapshot persists, whether it creates a new checkpoint or overwrites a previous one, or whether it requires an active session. Adequate but not rich.

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 sentences with no filler. The main action is front-loaded, followed by precise usage timing, then a concrete instruction on what content to include. 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?

For a persistence-oriented tool with no output schema, the description explains the intended content and the use cases. It doesn't describe return values or side effects, but the agent has enough to invoke it correctly and populate the parameters meaningfully.

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%, so the baseline is 3. The description adds value by identifying the critical fields (goal, current_state, next_action) and explaining their collective purpose: enabling a fresh AI to continue without full history. This goes beyond the schema's individual field descriptions.

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 ('Create a recovery snapshot') and a clear resource ('current work state'). This clearly differentiates it from session lifecycle siblings like start_session or end_session, which manage the session itself rather than preserving a resume point.

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 timing guidance: 'after meaningful milestones, before ending work, or before switching to another major task.' It doesn't explicitly name alternatives or state when not to use it, but the provided context is strong enough for an agent to decide correctly.

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 it does well: it explains that previously recorded events are already durable and that the operation finalizes the session for clean handoff. This gives the agent useful side-effect and persistence context, though it does not mention reversibility or required permissions.

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 short sentences with no wasted words. The main action is front-loaded, followed by the call timing and then the important durability guarantee.

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 tool with all-optional parameters and a 100%-covered schema, the description gives enough operational context: when to call, what it does, and what the agent can rely on afterward. It could mention what happens if no session is active, but the schema already covers parameter resolution hints.

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 parameters are already documented in the schema. The description adds no additional meaning about session_id, final_overview, or workspace_path, keeping this at the 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?

The description opens with a specific verb and resource: 'Finalize the current work session.' It also differentiates from sibling tools like start_session and checkpoint_session by clarifying that this operation comes after a final checkpoint and closes the session for handoff.

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 call the tool: 'after recording unfinished TODOs and creating a final checkpoint.' However, it does not mention when not to use it or name alternative tools, so it stops short of full routing 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 full burden of disclosing behavioral traits. 'Get information' implies read-only behavior, but the description does not state whether it errors when no session is active, whether it returns partial data, or whether any state is modified. The lack of any behavioral context leaves the agent with only the verb and tool name to infer safety and side effects.

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 clear sentence with no filler or repeated information. It is front-loaded and efficiently communicates the core purpose, though it could include a bit more operational context without becoming verbose.

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 read-only getter with one optional parameterable to invoke correctly since the schema covers workspace_path and the purpose is clear. However, the absence of an output schema and annotations means the agent does not know what 'information' is included or what happens when no active session exists, leaving some important context unspecified.

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 already fully documents the only parameter, workspace_path, with 100% coverageable for this single optional filter. The description adds no parameter-specific meaning, but because the schema covers the parameter adequately, a baseline score of 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 states a clear read operation ('Get information') and a specific resource ('currently active session'), which goes beyond the bare tool name by specifying that it targets the active session rather than any arbitrary session. It does not explicitly name sibling tools like get_session or list_sessions, but the 'active' qualifier provides meaningful 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 implies that the tool should be used when the active session is needed, but it does not explicitly explain when to prefer this over get_session, list_sessions, or start_session. There is no exclusionary guidance, so an agent must infer the appropriate context from the sibling tool names.

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 of behavioral disclosure. It openly states that it returns 'selective/compact context,' implying it may not contain all details, and lists exactly what it returns (goal, state, decisions, bugs, TODOs, files changed, next action). It also explains the fallback path. While it doesn't discuss side effects or permissions, for a read operation this is sufficient and adds meaningful behavioral context.

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 slightly verbose but every sentence carries value: purpose, timing, content, and fallback. It is front-loaded with the primary purpose and immediate usage instruction. The phrase 'most important tool for cross-session continuity' adds emphasis but could be trimmed without losing information. Overall it is well-structured and not overly long for the complexity.

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, the description compensates by enumerating the exact fields returned and explicitly noting the selective nature. It covers when to use, what it returns, and what to do if data is missing. It doesn't specify response format or error conditions, but for a read tool with clear fallback guidance, the description is sufficiently complete for correct invocation.

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 all four parameters with descriptions. The tool description adds minimal parameter-specific information—it mentions auto-detection of project via workspace_path indirectly, but that's already in the schema. Since the schema handles parameter semantics fully, the description doesn't need to compensate, so a baseline of 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 the verb ('Retrieve'), the resource ('continuation context from previous sessions'), and the scope ('for the current project'). It also distinguishes itself from sibling tools by naming the exact context to retrieve (goal, state, decisions, bugs, TODOs, files changed, next action) and by positioning itself as the primary cross-session continuity tool, making it easy to differentiate from search_memory, search_history, and get_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 timing instructions: 'Call this IMMEDIATELY after start_session and BEFORE making significant changes.' It also gives clear fallback guidance: if specific info isn't found, use search_memory() for durable facts or search_history() for detailed events. This tells an agent exactly when to use this tool and when to switch to alternatives, leaving nothing 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?

With no annotations, the description itself must indicate side effects. The verb 'Retrieve' makes it clear this is a read-only operation, and the phrase 'with its events and checkpoint' discloses the returned data. However, it does not address failure behavior for missing/invalid IDs or any permission requirements, though these are minor for a simple getter.

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 sentence with no filler. The core operation is front-loaded, and the qualifiers 'with its events and checkpoint' are appended without 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?

This is a simple one-parameter getter with no output schema, and the description provides the essential return content (events and checkpoint). It could be more explicit about what happens when the session ID is not found, but for a straightforward retrieval tool the description is adequately 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?

The input schema already provides a 100% description for the sole parameter session_id ('The session ID'), so the description's job is minimal. The description does not add any additional format, example, or source for the session ID beyond what 'by ID' implies, so it earns the baseline for high schema coverage.

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 the specific verb 'Retrieve' and identifies the resource 'a session by ID', specifying the return content 'with its events and checkpoint'. This clearly separates it from sibling tools like get_active_session, which would not require an explicit session_id.

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 usage when the caller has a specific session ID and needs its events/checkpoint, but it does not explicitly name alternatives or say when not to use it. No exclusion criteria or comparison with get_active_session/list_sessions is provided, leaving the selection logic implicit.

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 of behavioral disclosure. It only says 'recent sessions' without explaining ordering, whether active sessions are included, what fields are returned, or whether the operation is purely read-only. 'List' implies read-only, but the description does not elaborate on behavior beyond the name.

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 just three words and contains no redundancy or filler. It is front-loaded with the key action and object, and every word contributes to the meaning.

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 list tool with two optional, well-documented parameters, this is minimally viable. However, there is no output schema and no description of return values, sorting semantics, or what 'recent' means, so an agent still has some ambiguity about the exact behavior and response 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 100%, so the schema already documents both parameters (limit and workspace_path). The description itself adds no parameter-level meaning, but baseline 3 is appropriate because the schema carries the semantic weight.

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 clear verb and resource: 'List recent sessions.' This distinguishes it from siblings like start_session, end_session, get_session, and get_active_session by virtue of the 'list' action, but it does not explicitly differentiate it from similar listing or search tools like search_history.

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 offers no guidance on when to use list_sessions versus alternatives such as get_active_session, get_session, or search_history. It does not state prerequisites, exclusions, or preferred scenarios, so an agent must infer the usage context from the tool name alone.

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. It clearly indicates the tool records an activity and gives guidance on content quality, but it does not disclose whether the entry is persisted, how it relates to the workspace/session, or what response is expected.

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 core purpose. Every sentence earns its place: what it does, which categories to use, and how to phrase the content. No redundancy or 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?

For a 4-parameter tool with no output schema, the description covers the important category semantics and content expectations. Metadata and workspace_path are adequately described in the schema. A small gap is the lack of any statement about return values or session behavior, but this is not critical for a simple logging 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 100%, so the baseline is 3. The description adds meaningful value by expanding the category enum into concrete use cases and giving a good versus poor example for the description parameter, which goes beyond the schema's generic labels.

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 clear verb+resource: 'Record an important activity during work' and enumerates the activity categories it supports. The category list makes its purpose specific, though it does not explicitly distinguish itself from similar siblings like append_event or log_file_change.

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 tells when to use it with a list of activity types such as decisions, bugs, todos, commands, test_result, and error. It also gives content guidance like 'Record outcomes, not reasoning,' but it does not name alternatives or state when not to use this tool.

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?

Without annotations, the description carries the transparency burden and it does a good job: it states the operation is a post-action log entry, defines 'significant' by counterexample, and shows the expected content shape. It doesn't discuss persistence or return values, but as a simple logging tool those are not critical to invoking it correctly.

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 compact sentences plus a single illustrative example. The action, the timing, the quality bar, and the expected payload are all present without filler, and the main instruction is front-loaded.

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 a simple audit-logging action with six parameters, no output schema, and no annotations. The description captures the essential selection cue, the content requirements, and a concrete format example, covering everything an agent needs to log a change correctly. Minor details such as workspace resolution are already documented in the input schema.

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 example maps nicely to path, change_type, and description, and the prose tells the agent to include path, change, and why. However, the description adds no meaning for lines_added, lines_removed, or workspace_path, and schema coverage is only 67%, so the uncovered parameters still lack interpretive help.

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 object ('Record a significant file change') and frames it clearly with a temporal constraint ('after the change is actually made'). The example and 'Do not log every temporary edit' guidance distinguish it from generic logging/activity-tracking siblings like log_activity, making the tool's scope immediately recognizable.

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 defines the intended trigger: significant file changes after they actually happen, and tells the agent to skip temporary edits. It doesn't name sibling tools that should be used instead for non-file events, but the positive and negative triggers are clear enough for selection among the listed siblings.

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. It states the operation but does not disclose side effects (e.g., whether the session is made active, whether current state is overwritten, or whether recovery is destructive). This is a significant gap for a tool that modifies session state.

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, grammatically correct sentence with no filler. The key qualifier ('abandoned or crashed') is front-loaded, providing maximum clarity in minimal space.

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?

With no output schema, no annotations, and a terse description, the tool is under-specified for an agent to understand what 'recover' actually accomplishes. The low parameter count reduces complexity, but the behavior and return value remain unexplained.

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%, with session_id described as 'Session ID to recover' in the schema. The tool description adds no additional semantic value beyond that, so the baseline of 3 applies.

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 ('recover') with a clear resource ('session') and adds a condition ('abandoned or crashed'). This distinguishes it from siblings like get_session or start_session, though 'recover' is not fully detailed (e.g., does it resume, restore, or re-activate?).

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 'abandoned or crashed session' implies when to use this tool versus alternatives like start_session or get_session, but there is no explicit when-to-use or when-not-to-use guidance, and no sibling tools 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 provided, so the description carries the full behavioral burden. It usefully discloses that memories persist across sessions and are retrievable later, and mentions provenance. However, it does not explain what provenance entails, return/acknowledgment behavior, or side effects, leaving gaps for a tool with zero annotation coverage.

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 with no filler. The purpose is stated first, and the persistence behavior follows immediately. Every component 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 no annotations and no output schema, the description provides the essential purpose and persistence trait but omits details like what provenance means, what the tool returns or acknowledges, and explicit guidance on when to prefer it over logging tools. It is sufficient for basic selection and invocation, but not comprehensive.

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 all parameters. The description adds no parameter-level detail beyond the notion of long-term memory and provenance, so the baseline 3 applies.

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 ('Store') and resource ('long-term memory with provenance'), making the core action unambiguous. It also adds persistence semantics, but it does not name sibling tools to explicitly differentiate itself, so it stops short of a 5.

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 conveys clear usage context: this is for memories that should persist across sessions and can be retrieved later. It does not mention exclusions or alternatives like log_activity or append_event, but the intended use case is reasonably 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. It discloses that resolved TODOs remain in history but no longer appear under Open Tasks, which is a useful side effect. However, it doesn't mention reversibility, failure handling, or any other behavioral constraints. This is minimal but not misleading.

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 fluff. It front-loads the purpose, then provides usage context and a behavioral note. Every sentence adds value.

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 action with no output schema, the description covers the essential aspects: what it does, when to use it, and the post-resolution state. It doesn't mention error conditions (e.g., what if the TODO doesn't exist), but that is a minor gap for this type of tool. Overall, it's fairly 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 schema already documents all parameters. The description does not add extra meaning beyond what the schema provides (e.g., todo_text matching is already in the schema). Since coverage is high, a baseline of 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 the action ('Mark a previously recorded TODO as resolved') and the resource (TODO). It also ties to a specific origin ('open task from get_context'), making its purpose unambiguous and distinct from siblings like log_activity or update_memory.

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: 'Use this when an open task from get_context has been finished.' This gives a clear trigger condition. It doesn't explicitly mention alternatives or exclusions, but the reference to get_context and the specific action provides enough context for 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 provided, the description carries the full burden of transparency. It discloses that this tool returns raw events from past sessions and searches historical events rather than curated knowledge. It does not state side effects or permissions, but as a read-only search operation, the behavioral profile is reasonably clear. Minor gaps include no mention of result ordering or default behavior, but the core behavior is clear.

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 appropriately sized and front-loaded, starting with the action and scope, then use cases, fallback conditions, and sibling distinction. Slight redundancy exists between 'when current context does not contain enough detail' and 'Call this when get_context() and search_memory() do not contain the needed information,' but 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?

For a read-only search tool with 100% schema coverage and no output schema, the description provides enough context: what it searches, what it returns, when to use it, and how it relates to sibling tools. It does not describe the shape of returned raw events, but the absence of an output schema makes that a minor but acceptable 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 100%, so the schema already documents all five parameters. The description adds use-case context but no additional parameter-level detail beyond what the schema already provides. This meets the baseline for full schema coverage without needing compensation.

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 verb ('Search'), a specific resource ('historical session events'), and the exact scope ('exact historical... raw events from past sessions'). It also distinguishes itself from search_memory by noting the difference between raw historical events and curated long-term knowledge.

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: when current context lacks detail and when get_context() and search_memory() are insufficient. It explicitly names the alternative tools and clarifies how search_history differs from search_memory, giving an agent clear routing 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 full behavioral burden. It usefully characterizes the data domain as 'durable project knowledge' and implies a read-only search, but it does not explicitly state side-effect safety, permission requirements, or result behavior. The scope information adds some value, but the safety and return profile remain implicit.

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 action and object are front-loaded ('Search durable project knowledge and previous important decisions'), followed by concrete usage scenarios and an explicit alternative, so 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 moderate complexity (4 parameters, no output schema), the description covers what the tool searches, when to use it, and how it relates to get_context. The main omissions are the result shape and any memory_types value semantics, but for selecting and invoking a search tool the provided context is nearly sufficient.

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%, so the baseline is 3. The description adds semantic guidance for the query parameter by specifying the kinds of questions it should address, such as 'why a previous architectural or implementation decision was made' and long-term facts, conventions, and preferences. It does not add detail for limit or memory_types, but the core query intent is meaningfully enriched.

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: 'Search durable project knowledge and previous important decisions.' It further clarifies scope with concrete use cases (reasons behind decisions, long-term facts, conventions, user preferences) and positions itself against the get_context sibling, making it easy to distinguish.

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 when-to-use conditions: 'Use when reasoning depends on why a previous architectural or implementation decision was made, or to find long-term project facts, conventions, and user preferences.' It also names an alternative and a routing rule: 'Call this when get_context() does not contain the needed information.'

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 full behavioral disclosure burden. It tells the agent that the tool starts or resumes session tracking and should be called automatically, but it does not explain what happens when a session is already active, whether callings is idempotent or destructive, or what state changes occur. Some of this is implied by force_new in the schema, but the description itself leaves the side effects underspecified.

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 four short, purposeful sentences with no filler. It front-loads the purpose, then gives usage triggers, a required follow-up action, and an exclusion. The emphasis on 'AUTOMATICALLY' and 'Do NOT' improves scannability without bloating the text.

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 largely complete for invocation: it states purpose, provides examples and exclusions, names the next tool to call, and all parameters are covered by the schema. It falls short only on explaining the precise 'resume' semantics and side effects on the active session, which would matter when deciding between start_session and related tools like get_active_session or end_session.

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 every parameter is already documented in the schema. The description only adds 'current project,' which maps to workspace_path, but it does not enrich goal, title, or force_new beyond what the schema already states. 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 a specific action—'Start or resume Session Memory tracking'—scoped to 'the current project,' and the schema confirms workspace_path as the project identifier. This distinguishes it from siblings like end_session, get_active_session, and get_context by naming the session lifecycle action it performs.

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: 'Call this AUTOMATICALLY at the beginning of meaningful project work' with concrete examples, and an explicit when-not: 'Do NOT start sessions for trivial questions.' It also instructs the agent to follow with get_context. It does not name alternative sibling tools for checking or ending sessions, such as get_active_session or end_session, so it stops short of full alternative routing.

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, but it only states the operation without consequences. It does not say whether updates are partial or full replacements, what happens if memory_id does not exist, how status transitions like 'superseded' affect other memories, or whether the operation is idempotent.

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 and no redundancy. It is appropriately concise for a simple update tool, though slightly under-specified in a way that hurts behavioral transparency rather than conciseness.

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 no annotations and no output schema, the description alone is not enough to fully understand the tool's behavior. It relies on the schema for parameter semantics but leaves unanswered the behavioral and usage questions, such as how to obtain a memory_id, what a successful update returns, and what side effects status changes may have.

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 memory_id, content, status, and importance, including the status enum and importance range. The description adds little beyond the phrase 'content or status' and actually omits 'importance', so it neither enhances nor contradicts 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 uses a clear verb–resource pair ('Update an existing memory') and names the most common mutable fields, which separates it from create-oriented siblings like 'remember' and read-oriented siblings like 'search_memory'. However, it omits the 'importance' property exposed by the schema, so the stated scope is slightly incomplete.

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 guidance on when to use this tool versus sibling alternatives such as 'remember' for creating memories or 'search_memory' for finding a memory_id. The description does not state prerequisites or warn against using it for new memories, leaving the decision entirely to inference.

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