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

With no annotations provided, the description carries the burden of disclosure. It identifies the side effect (adds to status bar) and input validation requirements (absolute path, git root). However, it omits failure modes (what if path doesn't exist), return value structure, and whether adding 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?

Two sentences, zero waste. The first sentence establishes the operation and target; the second specifies the critical path constraint. Efficiently front-loaded with essential information.

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 4 simple parameters with complete schema documentation, the description is minimally sufficient. However, lacking annotations and output schema, it should ideally describe the success/failure response or what happens when adding a duplicate repo, which would elevate it above baseline adequacy.

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%, establishing a baseline of 3. The description adds value by reinforcing the 'absolute' path requirement and 'git repo root' constraint in the second sentence, but does not elaborate on the 'label', 'type', or 'show' parameters beyond what the schema already documents.

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 specific action ('Add'), resource ('repository'), and destination ('status bar'). Distinguishes from siblings like 'remove_repo' implicitly through the verb, though it does not explicitly clarify when to prefer this over 'validate_repo_path' or other related tools.

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?

Mentions the path constraint ('must be an absolute filesystem path'), providing a prerequisite. However, it lacks guidance on when to use this vs. 'validate_repo_path' first, whether the operation is idempotent, or when to choose 'active' vs 'reference' types.

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 full burden. While 'Get' implies read-only behavior, it fails to disclose error conditions (non-existent repo), return format (string vs object), or idempotency. This is a significant gap for a tool requiring safe operational 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?

Single sentence, front-loaded with the action verb. Every clause earns its place: 'Get' (action), 'current branch' (resource), 'single repo' (scope), 'by its label or path' (input method). No redundancy or verbosity.

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 (1 parameter, 100% schema coverage, no nested objects), the description adequately covers the core functionality. It implies the return value is the branch name. Minor gap: no mention of error handling or exact return type structure, though acceptable for this complexity 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 coverage is 100%, establishing a baseline of 3. The description repeats 'by its label or path' which mirrors the schema's 'Repo label or absolute path' without adding syntax details, format constraints, or examples beyond what the structured schema already provides.

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 specific verb 'Get' with clear resource 'current branch' and scope 'single repo'. It implies distinction from sibling get_branch_status (which likely returns status metadata) by focusing solely on retrieving the branch name. However, it lacks explicit differentiation from siblings like validate_repo_path.

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 guidance or prerequisites are provided. The description does not mention whether the repo must exist beforehand (likely managed by add_repo) or what error occurs if the identifier is invalid, leaving gaps for agent selection logic.

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 provided, so description carries full burden. It discloses important filtering behavior (respects enabled flag and showReferenceRepos toggle) but fails to explicitly confirm read-only safety, rate limits, or the structure of returned data.

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 efficient sentences with no waste. Purpose is front-loaded in the first sentence; the second adds behavioral context without bloating the description.

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?

Adequate for a simple read operation but lacks return value specification (no output schema exists to compensate) and omits behavior details like error handling when no repos are configured.

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?

Zero parameters present, triggering the baseline score of 4. The description does not need to compensate for missing schema documentation since the schema is trivially complete (empty object).

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?

Clear verb (Return) + resource (git branch) + scope (every configured repo). Implicitly distinguishes from sibling 'check_repo_branch' by emphasizing bulk retrieval across all repos, though it doesn't explicitly name the sibling alternative.

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 versus 'check_repo_branch' or 'list_repos'. The mention of respecting 'enabled flag' and 'showReferenceRepos toggle' describes configuration dependencies but provides no prescriptive usage context.

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 disclosure burden. It specifies that two distinct values are returned (file path and configuration content), but omits safety details, error conditions (e.g., missing config file), or whether this reads from disk potentially impacting performance.

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, efficient 12-word sentence with the action verb ('Return') front-loaded. No words are wasted, and the length is appropriate for a parameter-less utility function.

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 output schema exists, the description appropriately explains what is returned (path and configuration). It adequately covers the tool's simplicity, though it could enhance completeness by mentioning the config format or error scenarios.

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 contains zero parameters, which per the guidelines establishes a baseline score of 4. The description correctly implies no inputs are needed by focusing entirely on return 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 returns the config file path and current configuration using specific verbs and resources. While it doesn't explicitly contrast with the repo-focused siblings (add_repo, list_repos, etc.), the name and description make the distinct purpose evident.

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 guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as whether a configuration must exist first or how this relates to the repo management sibling 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 provided, so description carries full burden. Discloses output structure by listing specific fields returned (label, path, type, visibility). However, omits safety confirmation (though implied by 'List'), auth requirements, or performance characteristics.

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?

Single sentence, perfectly front-loaded. Action verb leads, followed by scope and output specification. 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?

Given zero parameters and no output schema, the description adequately compensates by enumerating the output fields. Could improve by specifying return format (array/object) or noting this retrieves local configuration only.

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?

Zero parameters required. Schema is empty object as expected. Baseline score 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?

Specific verb 'List' + resource 'configured repos' + scope 'all'. Field enumeration (label, path, type, visibility) distinguishes from sibling tools like get_config_info (general settings) and check_repo_branch (specific repo operations).

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?

Implied usage as an inventory/catalog operation by specifying output fields, but lacks explicit guidance on when to use versus get_config_info or prerequisites for calling this before repo-specific operations.

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 behavioral disclosure. It successfully establishes this is a UI/status bar operation (not data deletion), but lacks information on side effects, reversibility, or whether the removal persists across sessions.

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 single 9-word sentence is perfectly front-loaded with the verb 'Remove' and contains zero redundant information. Every word earns its place by specifying action, resource, location, and key parameter.

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 (one well-documented parameter, no output schema), the description adequately covers the necessary context for an agent to invoke it correctly. However, it could benefit from mentioning the relationship to add_repo for complete contextual awareness.

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 the 'label' parameter already described as 'Repo label to remove.' The description mentions 'by its label' but adds no additional semantic context (e.g., format constraints, where to find valid labels) beyond the schema, warranting the baseline score for high-coverage schemas.

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 specific action (Remove), resource (a repository), and scope (from the status bar) using the label parameter. It effectively distinguishes this from destructive deletion operations by specifying 'status bar,' though it could explicitly contrast with sibling tools like add_repo.

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 guidance on when to use this tool versus alternatives (e.g., when to use remove_repo vs set_repo_visibility or toggle_statusbar) or prerequisites (e.g., confirming the repo exists via list_repos first).

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 full behavioral disclosure. It successfully identifies the UI location ('status bar') which is critical context, but omits persistence behavior (does this setting survive restart?), error handling for invalid labels, or whether this affects other views beyond the status bar.

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?

Single 11-word sentence with zero redundancy. Front-loaded with the action ('Show or hide'), followed by target ('specific repo'), location ('status bar'), and key parameter ('by its label'). Every word 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?

Adequate for a simple 2-parameter toggle with no output schema. Captures the essential operation and UI context. However, lacks completeness regarding error conditions (invalid label) and relationship to the registration state of the repo (managed by sibling 'add_repo').

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 has 100% description coverage ('Repo label' and boolean semantics). The description mirrors this information ('Show or hide' aligns with the boolean, 'by its label' references the string param) but adds no additional syntax guidance, constraints, or examples beyond what the schema already provides. Baseline 3 appropriate for high-coverage schemas.

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?

Clear verb pair ('Show or hide') with specific resource ('repo') and scope ('in the status bar'). The 'by its label' qualifier maps to the required parameter. Distinguishes from sibling 'toggle_statusbar' (which implies global UI toggle) by specifying 'specific repo', though it doesn't explicitly reference the visibility concept from the tool name.

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 no guidance on when to use this versus 'toggle_statusbar' or 'toggle_reference_repos', nor does it state prerequisites like the repo needing to exist first (implied by 'label' reference). No mention of when showing/hiding is appropriate.

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 provided, so description carries full disclosure burden. Explains the visibility toggle behavior but omits persistence details (session vs permanent), side effects on other tools, or definition of 'reference' vs 'active' repo types. No contradictions present.

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?

Single efficient sentence with zero waste. Action verb front-loaded, scope clearly delimited by 'in the status bar.' Appropriate length for tool 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?

Adequate for a simple 1-parameter toggle tool. Status bar context is specified. No output schema exists, but return value is likely implicit boolean success; description doesn't need to elaborate for this complexity 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% (parameter 'show' fully documented). Description does not add parameter-level semantics beyond schema, which is acceptable baseline when schema is complete.

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?

Clear specific action (show/hide), target resource (repos type 'reference'), and location (status bar). Implicitly distinguishes from sibling toggle_statusbar by specifying it's for filtering repo types rather than the status bar itself.

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 guidance or contrast with siblings like toggle_statusbar (which likely controls the entire status bar visibility) versus this tool which filters content within it. Uses must infer applicability from the action description 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?

With no annotations provided, the description carries the full disclosure burden. It successfully explains that disabled state causes the status line script to output nothing, but fails to describe the enabled state behavior, persistence, or any 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 consists of two efficient sentences with no waste. The primary action is front-loaded in the first sentence, while the second sentence provides immediate behavioral context, making it well-structured.

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 (single boolean parameter, no output schema), the description adequately covers the essential functionality and immediate behavioral effect. It appropriately scopes the explanation to the tool's limited surface area.

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?

With 100% schema description coverage, the baseline is 3. The description mentions 'enable or disable' which aligns with the boolean 'enabled' parameter, but adds no additional semantic detail about the parameter's usage beyond what the schema already provides.

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 enables or disables the status bar using specific verbs. While it distinguishes itself from repository-focused siblings, it lacks domain context about what the 'status bar' refers to (e.g., IDE, terminal, or repository status display).

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, nor any prerequisites. It explains the behavioral consequence of disabling (no output) but does not frame this as usage 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 provided, so description carries full disclosure burden. While it specifies the dual validation logic (existence + git status), it omits critical behavioral traits: read-only nature, return value structure (boolean vs object), error behavior on invalid paths, 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?

Single sentence structure with zero redundancy. Front-loaded with action verb. Every word earns its place. Appropriate length for tool 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?

Adequate for simple single-parameter tool with complete schema coverage, though gaps remain due to missing output schema (no indication of success/failure return format or error conditions) and zero annotations providing context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage ('Absolute path to check'). Description references 'filesystem path' but adds no semantic elaboration (e.g., format constraints, relative vs absolute path handling, examples) beyond the schema baseline. Baseline 3 warranted by 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?

Clear action verb 'Check' and specific validation targets (path existence AND git repository status). Resource scope is explicit ('filesystem path'). Distinction from siblings like 'check_repo_branch' is conceptually clear (path validation vs branch inspection) though not explicitly stated.

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?

States what the tool validates but provides no guidance on when to invoke it versus alternatives (e.g., 'use before add_repo to verify', 'do not use for already registered repos—use list_repos instead'). No preconditions or exclusions mentioned.

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