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

With no annotations, the description carries the full burden. It discloses that the tool returns a context packet containing summarized intent and messages up to the fork point, implying a read-only operation. No contradictions found.

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. Every word 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?

Even without an output schema, the description explains what the context packet includes ('summarized intent and messages up to the fork point'). For a simple 2-parameter read tool, this is sufficient, though sessionId remains ambiguous.

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 only 50%: branchId is documented but sessionId is not. The description only says 'specific branch' and provides no additional meaning for sessionId. It fails to compensate for the undocumented parameter.

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 'Get' and resource 'context packet for a specific branch', clearly distinguishing it from sibling tools like threadmap_fork or threadmap_status. It precisely states what the tool does.

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 this tool: when you need a branch's summarized intent and messages up to the fork point. It doesn't explicitly mention alternatives or when not to use, but the context is unambiguous.

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 burden of disclosure. It reveals the key behavior of creating a clean branch with only context up to the fork point, which is important. However, it does not disclose side effects like whether the original thread is modified, persistence, or 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?

Two sentences, front-loaded with the action, and every word adds meaning. No filler or 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?

Given the tool's simplicity, the description covers the core purpose and outcome. It does not mention return values or edge cases, but for a forking operation the description is sufficiently complete for an agent to understand when and how to invoke it.

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 67%: messageIndex and branchName have descriptions, but sessionId does not. The description adds minimal semantic value beyond the schema, mainly restating the fork point concept. It does not clarify sessionId's purpose or format.

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 ('Fork the conversation') and the resource ('from a specific message index'), and distinguishes it from siblings by specifying it creates a new branch with limited context. This is a precise verb+resource combination.

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 explicit guidance on when to use this tool versus alternatives like threadmap_branch_context or threadmap_reset. The description implies usage for branching, but does not state conditions or 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 provided, the description carries the full burden. The verb 'show' clearly indicates a read-only, non-mutating action, and there are no side effects or prerequisites to disclose. This adequately covers behavioral expectations for such a simple tool.

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 that earns its place. It communicates the purpose efficiently 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?

Given the tool's simplicity (no parameters, no output schema, no annotations), the description is complete. It tells the user what the tool does (shows a legend) and what it contains (color explanations), which is all that is needed.

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 zero parameters, so the description does not need to explain parameter meanings. The baseline of 4 applies, and the description adds no unnecessary parameter-related noise.

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 ('show') and identifies a clear resource ('color legend'), explaining exactly what the tool does. It is distinct from sibling tools like threadmap_fork or threadmap_timeline, which clearly serve different purposes.

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 when to use the tool: whenever a user needs to interpret the colors on a threadmap. It gives clear context without explicitly naming alternatives, but no alternatives are necessary for a legend 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?

With no annotations provided, the description carries the full burden of disclosing side effects. It accurately discloses that the current thread is archived (non-destructive) and tracking restarts from a new origin. However, it does not mention reversibility, required permissions, or any other implications beyond the immediate archive, which is a moderate transparency level for a mutation tool.

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 concise sentences, front-loaded with the primary action ('Reset the session') followed by a clarifying explanation. Every word earns its place, with no redundancy or extraneous detail.

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 tool with 2 parameters, no output schema, and no annotations, the description covers the core functionality and the main side effect. However, it omits any mention of return values or what happens to the archived thread beyond being archived, leaving a moderate gap in completeness. A bit more detail on the post-reset state would elevate it.

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 50%: newOriginContent has a description, but sessionId does not. The description references 'session' and 'new origin', which loosely maps to both parameters and reinforces their roles. However, it does not explicitly explain that sessionId is the session to reset or provide additional syntax/format details, offering only marginal value 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 clearly states the tool's function with a specific verb ('Reset') and resource ('session'), then elaborates on the action: archiving the current thread and starting fresh tracking from a new origin. This distinguishes it from sibling tools like threadmap_fork or threadmap_track, making its purpose 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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention scenarios like 'use when you want to abandon current tracking' or contrast with threadmap_fork. The behavior is described, but there is no direct usage context or exclusion criteria, leaving the agent to infer suitability.

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 transparency burden. It reveals the return components (color, score, inflection flag) but does not explicitly state it is a read-only operation, potential errors, or how sessionId affects results. The verb 'Get' implies a read, but this is not explicit.

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, front-loaded with the core purpose, and contains no filler or redundant information. It is appropriately sized for a simple status getter.

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 incomplete for a tool with no output schema and no annotations. It does not explain what 'drift status' means, how sessionId is used, the structure of the response, or how this fits with sibling tools. The agent is left with significant ambiguity.

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% (only a param name 'sessionId'), and the description does not mention or explain the parameter at all. Since the description must compensate for the low schema coverage, the total lack of param guidance leaves the agent without clues about how to supply or use sessionId.

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 ('Get') and identifies the resource ('drift status') with explicit output details (latest color, score, inflection point). It clearly distinguishes from siblings like threadmap_timeline (historical) and threadmap_track (likely a different action).

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 is provided on when to use this tool versus alternatives. The description only implies usage by naming 'current drift status' but does not mention exclusions, prerequisites, or alternative tools for other needs.

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. 'Show' implies a read-only operation, but side effects, output format, and error behavior are not addressed. It does disclose visible output components (drift scores, inflection points, branches), adding some behavioral clarity.

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 conveys the primary purpose and output content with no redundancy. Every phrase 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 simple schema (one parameter) and no output schema, the description explains the core output content adequately. It could be more complete by clarifying whether the output is a visual timeline or structured data, and by noting any dependency on an existing session, but it is largely sufficient for basic usage.

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 fully describes the only parameter, sessionId, with 'Session ID to show timeline for', providing 100% coverage. The description adds no extra parameter syntax or constraints, so the 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 identifies the action ('Show') and the resource ('full color-coded conversation timeline'), and explicitly mentions drift scores, inflection points, and branches. This distinguishes it from siblings like threadmap_fork or threadmap_branch_context.

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 explicit when-to-use or alternative guidance is provided. The purpose implies a timeline visualization use case, but there is no mention of prerequisites or exclusions compared to other threadmap tools.

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. While it mentions building the drift map, it does not disclose any side effects, limitations, or behavioral nuances (e.g., whether messages are appended, overwritten, or require an active session). The description is too thin to fully inform the agent about the tool's behavior beyond the basic action.

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 concise sentences with the action front-loaded and no superfluous detail. Every word earns its place, making it highly efficient.

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 3-parameter tool with no output schema, the description provides sufficient context to invoke it correctly: it states when to call and what it does. However, given the absence of annotations, it could have briefly mentioned that this is a write operation that records messages, but the current level is adequate for the tool's simplicity.

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 provides 100% coverage with clear parameter descriptions (role, content, sessionId). The tool description adds minimal extra meaning—mainly reinforcing that role and content correspond to the immediate user/assistant message. This meets the baseline for high schema coverage but does not substantially enrich parameter understanding.

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 ('Track a message in the conversation timeline') and the resource it acts on. It distinguishes itself from siblings like threadmap_timeline (which likely displays the timeline) by positioning itself as the recording step, making its purpose 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 provides explicit when-to-use guidance: 'Call after each user or assistant message.' This clearly indicates the appropriate trigger and context. It does not explicitly name alternatives or exclusions, but the instruction is specific enough for an agent to know when to invoke it.

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