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 that it deletes files and that the scope is limited to one worktree, and mentions maxMatches exists in the schema as a safety limit. But it omits whether deletion is destructive/irreversible, permissions required, or what happens on glob mismatch — significant gaps for a destructive operation 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?

Three short sentences with no waste. Purpose and scope are front-loaded, followed by the safety contrast. 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?

This is a destructive file-deletion tool with 7 parameters, no annotations, and no output schema. The description should clarify safety semantics (irreversibility, dry-run behavior, what maxMatches does), but instead gives only high-level scope. Inadequate for the complexity and risk level.

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 documents all 7 parameters with detail (globs examples, worktree identification methods). The description doesn't add parameter-level meaning beyond noting the scoped nature. Baseline 3 applies when the schema does the heavy lifting.

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 specific verb (cleans/deletes) and resource (scratch files in a git worktree), and clarifies scope ('a specific hop only'). It implicitly contrasts with a global clean, but doesn't name the sibling (e.g., hop_clean) explicitly the way a 5 would.

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?

Implies when to use via 'Safer than global clean' and 'without affecting other worktrees', suggesting a scoped-use preference. However, it never names the alternative tool (hop_clean) or states when NOT to use this tool. Guidance is implied, not explicit.

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 full burden. It usefully discloses that the worktree is an isolated directory and that branch switching does NOT occur, and mentions dryRun in schema only. However it omits where the directory is created, whether repo state is mutated, error/permission behavior, and reversibility, leaving meaningful gaps for a mutating 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?

Purpose and mechanism come first, then the ticket example, then the IMPORTANT follow-up instruction. The follow-up block is agent-directed workflow guidance rather than tool semantics, which pads the description somewhat, but overall it is reasonably tight and 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?

For a 6-parameter mutating tool with no annotations and no output schema, the description covers purpose, isolation semantics, naming behavior, and downstream steps well. It stops short of describing the created path/return shape or failure modes, but the schema carries the parameter detail.

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 schema already documents all six parameters including from, slug, branch, and dryRun. The description adds only the ticket auto-naming example, which the schema already conveys in its ticket/slug descriptions, 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?

States a specific verb+resource ("Start a new hop (git worktree) for a ticket or feature") and immediately scopes it with "Creates an isolated directory for parallel development without switching branches." This clearly distinguishes it from siblings like git_worktree_list, git_worktree_open, and git_worktree_remove.

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?

Explains the triggering context (parallel/isolated development) and how to pass a ticket ID to auto-name the branch, plus explicit post-creation routing to "hop to <ticket>" and "hop open <ticket>". It does not explicitly contrast when to use this vs. hop_start or git_worktree_switch, but the context is strong.

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's a read operation and describes the return fields, which helps, but it doesn't disclose permissions, error conditions, or side effects. For a zero-parameter query tool this is 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?

Two sentences, front-loaded with the core action and return values, followed by usage context. 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?

Since there is no output schema, the description helpfully lists the fields returned. It covers the main contract but lacks details on error handling or how the parsed ticket/slug is derived. Complete enough for a simple query 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 description coverage is 100%, and the single parameter repoPath is fully documented in the schema. The description adds a bit of context about what worktree info is returned, but repeats some schema semantics. Baseline for high coverage with 1 param is 3; the added return-field enumeration lifts it slightly.

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 specific verb (Get) and resource (current hop/git worktree context), and enumerates exactly what is returned (branch, path, dirty status, parsed ticket/slug). An agent can distinguish this read-only query from sibling worktree tools like git_worktree_list or git_worktree_create.

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 for when to use it: to understand 'where am I?' and to enable resumability after context switches or retries. It doesn't explicitly name alternatives or exclusions, but the use case is well-defined.

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 must carry the full behavioral load. It discloses that the output includes path, branch, commit, and dirty status, and mandates that hints be displayed. But it doesn't mention whether this is read-only (implied by 'list' but not stated), pagination, or handling of missing repos.

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, front-loaded with purpose, then alternative, then output and mandatory hint behavior. The 'IMPORTANT' note is clear but slightly verbose; could be more concise, but 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 listing tool with no output schema, the description adequately covers purpose, output fields, and post-call actions. It doesn't detail error cases or how repoPath defaults (schema covers that), but overall sufficient 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?

The single parameter repoPath has 100% schema description coverage. The description doesn't add parameter details, but with one optional parameter already fully explained in the schema, the baseline is high. No additional parameter semantics are needed.

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 specific verb (List) and resource (git worktrees) and explicitly distinguishes itself from the shell command 'git worktree list' and from sibling tools like hop_list. An agent can immediately tell what this 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?

Explicitly says to use this instead of the git command, and the 'IMPORTANT' note gives post-invocation guidance about displaying hints for options (hop to, hop open, hop start). However, it doesn't contrast with sibling tools like hop_list or git_worktree_current beyond the git command.

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 full burden. It does disclose a meaningful side effect—launching a new Cursor window—which is beyond the name. However, it omits prerequisites (Cursor installed/running), failure behavior, or whether an existing window is reused.

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, front-loaded with the action, then the mechanism, then the usage cue. Minor redundancy between 'Open a hop' and 'Launches a new Cursor window,' but nothing wasted.

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 annotations and no output schema, the description must carry the load. It covers purpose and trigger, but all five parameters are optional and the schema only vaguely states that slug is 'combined with ticket,' leaving the description silent on which identifying combination is actually required to resolve a worktree.

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 schema already documents all five parameters, making 3 the baseline. The description adds only a loose hint via 'ticket/worktree' and does not explain how to choose among slug, branch, ticket, repoPath, or worktreePath.

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 specific verb and resource ('Open a hop (git worktree) in Cursor IDE') and clarifies the mechanism ('Launches a new Cursor window at the worktree path'). It does not differentiate from closely named siblings like hop_open or hop_start, so the agent cannot fully disambiguate from the name alone.

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?

Gives a clear triggering condition: 'Use this when user wants to edit files in Cursor for a specific ticket/worktree.' It does not state when-not-to-use it or name an alternative sibling (e.g., hop_open), but the usage 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 behavioral burden. It discloses the key safety refusal on uncommitted changes and the force override, but omits other important traits such as irreversibility, permissions, and the danger of removing the main worktree.

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?

Four short sentences, front-loaded with the core action and safety condition. No filler; every sentence contributes.

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 destructive 9-parameter tool with no annotations or output schema, the description covers the essential refusal behavior and usage trigger. It still leaves significant gaps around side effects, alternatives, and dangerous modes like allowMainWorktree.

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% for all 9 parameters, so the schema already documents each parameter. The description only repeats the force condition, adding no meaning beyond the schema; baseline 3.

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 specific verb and resource ('remove git worktree') and clarifies scope ('End a hop'). However, it does not explicitly distinguish this from sibling tools like git_worktree_clean or hop_end, leaving some ambiguity.

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 a clear usage context: 'Use when done with a ticket.' It does not mention when not to use it or name alternative tools, but the context is explicit.

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, and it does disclose two real traits: the tool returns a path rather than changing the shell's cwd, and the agent MUST subsequently run the cd from suggestedCommands. It stops short of describing failure behavior or whether the operation mutates anything.

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?

Four short sentences, front-loaded with the action and lookup keys, then usage, return value, and the critical follow-up. Minimal waste, though sentence two lightly restates sentence one.

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 output schema, and the description compensates by stating the return value (worktree path) and the mandatory cd follow-up. With all parameters optional, it still lacks guidance on precedence when multiple keys are supplied, but covers the essentials for invoking the tool correctly.

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% with per-parameter descriptions, so the schema already documents all five parameters. The description's listing of ticket/branch/path mirrors the schema without adding format, precedence, or mutual-exclusivity rules across those lookup keys.

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 specific verb (switch/hop) and resource (existing git worktree) and enumerates the three lookup keys, which distinguishes it from create/remove/list siblings. However it does not distinguish itself from the near-identical git_worktree_open sibling, leaving that boundary to the agent.

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?

"Use this to switch context to a different ticket" gives an implied usage context, and the IMPORTANT note prescribes a follow-up action. But it never says when to prefer this over git_worktree_open or what to do if the worktree is not found.

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 is a deletion (destructive) operation yet the description only vaguely reassures 'safer than global clean' without disclosing irreversibility, whether deletion is confirmed, what happens on glob mismatch, or any rate/permission constraints. The one behavioral hint (maxMatches safety limit) in the schema is not echoed or explained.

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, front-loaded with the core action, followed by what it deletes and the safety differentiator. 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?

For a destructive, multi-parameter tool with no annotations and no output schema, the description is far too thin. It omits how a worktree is targeted (slug/ticket/branch/worktreePath alternatives), whether deletion is reversible, and how it differs from git_worktree_clean. An agent could invoke it but lacks the context to do so safely.

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 seven parameters, including globs examples and the maxMatches safety limit. The description adds no parameter-level meaning beyond what the schema provides; 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?

States a specific verb (clean) and resource (scratch files in a hop/git worktree), and distinguishes from a global clean. However, it does not distinguish from the sibling 'git_worktree_clean' — both appear to operate on worktrees, and the description never explains how hop_clean differs from that sibling, which matters for an agent choosing between them.

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: clean scratch files in a single worktree rather than globally, and asserts it is 'safer than global clean'. But it never explicitly says when to prefer hop_clean over the sibling git_worktree_clean, and there is no guidance on when not to use it. Implied usage only.

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 and does reasonably well: 'Get'/'Returns' implies a read-only operation, and it discloses the scope (current working directory) and the returned fields (branch, path, dirty status, parsed ticket/slug). It omits error behavior when not inside a git repo and does not explicitly affirm non-mutating behavior.

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, front-loaded with the core action before the return contents and rationale. The returned-fields sentence is slightly redundant with the opening sentence but still earns its place by enumerating outputs.

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, single-optional-parameter read tool with no output schema, the description supplies enough: purpose, scope, and enumerated return fields. Missing only edge-case behavior (e.g., outside a repo, detached HEAD) which is minor here.

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 single optional repoPath parameter is fully documented in the schema; per the rubric this sets a baseline of 3. The description adds only the implicit 'current working directory' default, not new syntax or format detail.

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 specific verb and resource ('Get the current hop (git worktree) context') and clarifies scope as the current working directory. It does not, however, differentiate itself from the similarly named sibling 'git_worktree_current', leaving ambiguity about which of the two to pick.

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 usage context: 'Use this to understand where am I? and to enable resumability after context switches or retries.' That tells the agent when the tool is valuable, but it names no alternatives or exclusions (e.g., vs. hop_list or git_worktree_current).

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 and does disclose the key destructive-safety behavior: it removes the worktree directory and refuses when there are uncommitted changes unless force=true. It does not touch on permissions, prune semantics, or the allowMainWorktree danger path, but the core refusal contract is stated.

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 tight sentences, front-loaded with the purpose and then the safety contract and usage cue. No filler or repetition.

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 nine-parameter destructive tool with no annotations and no output schema, the description is adequate but thin: it omits dryRun, prune, and allowMainWorktree behavior and, more importantly, does not explain how the worktree is identified among the multiple alternative selectors.

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 all nine parameters are already documented. The description only echoes the force=true behavior already in the schema and adds no identification-logic detail (slug+ticket vs branch vs ticket vs worktreePath). 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?

States a specific verb+resource ('End a hop') and immediately disambiguates the jargon with the parenthetical '(remove git worktree)'. This distinguishes it from siblings like hop_start and hop_list without opening any schema.

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?

'Use when done with a ticket' gives a usable lifecycle cue, but there is no when-not guidance and no distinction from close siblings such as hop_clean or git_worktree_remove. The agent must infer which cleanup tool applies.

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 usefully discloses the return fields (path, branch, commit, dirty status) and imposes an unusual output obligation: always display the hints from the response. That is genuine behavioral context beyond the schema. A 5 would require more on errors or repo-state preconditions.

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, each earning its place, with the usage recommendation and the IMPORTANT output instruction front-loaded. Slightly wordy in the alternative list but nothing is wasted.

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 one-parameter, annotation-free read tool with no output schema, the definition is complete: it explains what is returned, how to call it, and the mandatory hint-display behavior. It stops short of describing failure modes or repository prerequisites.

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 repoPath fully, including the default-to-cwd behavior. The description adds nothing about parameter meaning. Baseline 3 is appropriate when the schema does all the heavy lifting.

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 specific verb (List) and resource (hops / git worktrees), and explicitly says to prefer it over the sibling command 'git worktree list'. An agent can distinguish it from hop_to, hop_start, etc. without opening any schema.

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?

Gives a clear when-to-use signal ('Use this instead of "git worktree list"') and names the alternatives the user should consider afterward (hop to, hop open, hop start). It does not, however, state exclusions or prerequisites (e.g., must be inside a repo), so it falls just 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.

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 discloses the external side effect (a new Cursor window is launched), which is more than the name implies. However, it says nothing about failure behavior when the target worktree does not exist, whether this requires the worktree to have been created first, or which parameter takes precedence when several are supplied.

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, front-loaded with the core action and followed by the mechanism and the usage trigger. Sentence two ("Launches a new Cursor window at the worktree path") partially restates sentence one, a minor 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 takes five different optional worktree identifiers with zero required parameters, no annotations, and no output schema. The description never explains how those parameters combine or which one to prefer, leaving an agent unable to reliably construct a valid call without reading the schema closely.

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 only adds "at the worktree path," which merely echoes the worktreePath parameter, and it gives no guidance on how slug+ticket, branch, repoPath, and worktreePath relate or resolve to one worktree.

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 specific verb (open) and resource (a hop / git worktree) and clarifies that the action is to launch a Cursor IDE window at the worktree path. An agent can distinguish it from hop_list, hop_start, and hop_end. It does not, however, differentiate itself from the sibling git_worktree_open, which the name implies may do something similar.

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?

"Use this when user wants to edit files in Cursor for a specific ticket/worktree" gives a clear triggering context tied to a specific intent. It stops short of naming alternatives (hop_start, git_worktree_open) or stating when not to use it, so it is context without 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 and does disclose meaningful behavior: it creates an isolated directory, explicitly does NOT switch branches, auto-names from the ticket ID, and supports a preview via dryRun (documented in schema). It omits error/permission behavior and what happens if the target already exists, which keeps it out of 5 territory.

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?

Front-loaded with the core action, then the no-branch-switch benefit, then the ticket-ID usage. The trailing 'IMPORTANT' sentence prescribing user-facing dialogue is somewhat conversational and agent-prescriptive, but still earns its place as usage guidance.

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 output schema exists, so the description could say more about the return value (branch name/path), but the schema's dryRun note partially covers this. For a 6-parameter creation tool with no annotations, the definition covers purpose, side effects, and next steps adequately.

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 echoes the ticket-ID example and auto-naming behavior already fully documented in the schema, adding no syntax or format detail beyond it.

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 specific verb and resource — 'Start a new hop (git worktree) for a ticket or feature' — and immediately defines 'hop' as a git worktree, so an agent understands the operation. However, with a sibling `git_worktree_create` that appears to do the same thing, the description offers no differentiation between the two, leaving a real ambiguity unresolved.

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?

Gives clear context for use ('parallel development without switching branches') and even prescribes follow-up routing to 'hop to' and 'hop open' alternatives. It stops short of explicit when-not guidance (e.g., when to use `git_worktree_create` instead, or behavior when the worktree already exists).

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 and does disclose two non-obvious traits: it returns the worktree path, and the caller MUST run the suggestedCommands cd afterward because the working directory is not changed automatically. It does not cover failure modes (no matching worktree) or how ambiguity between multiple matches resolves.

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?

Front-loaded with the action, then return value, then the critical post-call requirement in caps. Slight redundancy between 'hop to an existing worktree' and 'use this to switch context,' but nothing is wasted.

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?

Covers purpose, lookup keys, return, and the mandatory follow-up cd step for a 5-parameter tool with no output schema. Missing only edge-case behavior: what happens on no match or when multiple worktrees match and slug is omitted.

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 all five selectors are already documented in the schema. The description reinforces that lookup can be by ticket ID, branch name, or path, but adds no syntax, precedence, or fallback detail beyond that; 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?

States a specific verb ('hop to'), the resource (an existing git worktree), and the three lookup keys (ticket ID, branch name, path). This is clearly distinguished from siblings like hop_start/git_worktree_create, which create rather than target an existing worktree.

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?

'Use this to switch context to a different ticket' gives clear when-to-use context. It doesn't explicitly name alternatives (hop_list, hop_open) or state exclusions, but the 'existing worktree' framing implicitly separates it from creation/listing siblings.

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