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

The description thoroughly discloses all side effects: it creates a bare repository, adds a remote, initializes a git repo if needed, and lists specific error conditions (path not exist, name already registered, bare repo already exists). It also mentions the return value (repo name and clone URL). This transparency exceeds the annotations, which only indicate it's not read-only or destructive, and aligns with the mutating nature described.

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 detailed but not overly verbose. It packs essential information (actions, error cases, related tools, return value) into a few sentences without redundancy. While slightly longer than necessary, the structure is logical, progressing from the main action to side effects to error handling to related guidance, which aids comprehension. It earns a 4 for being effective without being bloated.

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 explicitly states what the tool returns: 'Returns the repository name and its clone URL.' It also mentions prerequisite behavior (initializes repo if needed) and error handling, covering all operational aspects. With a list of sibling tools, it provides enough context for an agent to understand the tool's role in the workflow. This is complete and self-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?

The input schema already provides clear descriptions for both parameters: 'Optional custom name for the repository on LGH' and 'Absolute path to the LOCAL working directory containing the Git repository.' The description does not add significant extra meaning beyond the schema, but it does reference the 'name' in an error condition, which slightly reinforces its role. Since schema coverage is 100% and descriptions are adequate, this is a baseline score.

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 primary function: 'Register a local Git repository with the LGH local server.' It specifies the verb (register), the object (local Git repository), and the target (LGH local server), making the purpose unambiguous. It also implicitly distinguishes it from siblings by describing a unique setup 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?

The description provides explicit guidance on subsequent tool usage: 'Use lgh_up to push subsequent commits and lgh_remove to unregister.' This tells the agent when to use other tools after this one, clearly framing this as the initial registration step. It also implies that this tool is for initial setup, which distinguishes it from update/removal 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?

Annotations only say readOnlyHint=false, openWorldHint=false, destructiveHint=false. The description goes well beyond by disclosing refusal conditions (unregistered name, server down, non-empty destination), the no-overwrite guarantee, and the returned JSON fields (name, clone_url, destination, branch, HEAD). This is rich behavioral context the annotations do not carry.

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 purpose, then usage, then error semantics, then return shape. Dense but every clause earns its place; slightly long with multi-clause sentences, costing a point against maximal tightness.

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 compensates by naming the returned fields. Combined with prerequisites, failure modes, and no-overwrite guarantees, an agent has everything needed to invoke this 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 description coverage is 100% and both parameters are already documented in the schema, including dest defaulting and the .git suffix note. The description repeats the .git allowance without adding format or syntax beyond the schema, so baseline 3 is correct.

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 (clone) plus resource (repository from LGH local server into a working directory), and immediately positions it relative to siblings: 'the restore side of the backup loop and the inverse of lgh_up.' An agent can distinguish it from lgh_up without reading schemas.

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 explicit when-to-use ('recover a working copy after data loss or materialize an existing backup on a new machine') and a prerequisite chain: find the name with lgh_list, ensure server is up via lgh_status otherwise lgh_serve_start. This is exactly the routing guidance the dimensions reward.

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?

Annotations already declare readOnly, non-destructive, and idempotent behavior. The description adds critical behavioral details: truncation at 32KB to protect context and refusal outside a Git work tree. These are not inferable from annotations alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no redundant phrasing, and the content is logically ordered: what it does, what it returns, key constraints, and when to use alternatives. Every sentence carries meaningful 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?

Although no output schema is provided, the description lists all return fields (has_changes, stat, diff, truncated, staged) and covers the error condition (non-Git path). Combined with sibling-tool context, an agent has sufficient information to invoke 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?

The schema provides 100% coverage for both parameters (path with default and staged with default). The description adds no extra semantic information beyond what the schema already states, so the 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?

States a specific verb ('Show'), resource ('uncommitted changes in a Git working directory'), and differentiates from the sibling lgh_up_dryrun by describing its distinct output (full diff vs. change list). This makes the tool's purpose immediately clear.

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 instructs when to use this tool ('to review patch content before lgh_save or lgh_up') and when to use an alternative ('use lgh_up_dryrun instead when you only need the changed-file list, trash detection, and LGH registration state'). No ambiguity remains.

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?

The description reinforces the read-only, idempotent, and non-destructive nature indicated by annotations, adding specific details like 'Reads only the local registry' and 'no network access.' It also states the return format (JSON array) and behavior when nothing is registered, making the tool's behavior transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured, covering purpose, output details, and usage guidance in a few sentences without redundancy or unnecessary fluff.

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 listing tool, the description provides sufficient context: what it does, what it returns, when to use it, and the local-only scope. The lack of an output schema is mitigated by the explicit mention of 'Returns a JSON array,' making the tool self-explanatory.

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 a single optional parameter 'filter' with a clear description ('Optional substring filter applied to repository name or source path (case-insensitive)'). However, the tool description itself does not mention the parameter or add any extra meaning beyond the schema, so it stays at 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 clearly states the tool's function: listing every Git repository registered with the LGH local. It specifies the exact fields returned (name, source_path, bare_path, clone_url, created_at) and distinguishes it from sibling tools like lgh_add, lgh_remove, and lgh_log, which perform different 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?

The description provides explicit use cases: discovering the clone_url of an existing backup or finding the exact registered name for lgh_remove. It also notes that the operation reads only the local registry with no network access, clarifying appropriate scenarios and contrasting with potential remote-oriented 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?

Descriptors in the description (reading log, empty array if no file) align with the annotations (readOnly, idempotent, not destructive). The description adds useful behavioral details about output format and empty-case handling, though it doesn't need to restate the annotation flags.

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: it states the core action in the first sentence, then adds the level filter and use-case context. No unnecessary words 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?

Despite lacking an output schema, the description explicitly defines the return shape ('JSON array of {ts, level, msg, component} objects') and the empty-array behavior. It also mentions the sibling tool lgh_status for contrast, providing enough context 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 schema already documents both parameters (level with enum values, limit with description). The description reinforces the meaning of level ('exactly that severity') and its purpose, which is sufficient.

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 ('Read') and a specific resource ('the LGH server's runtime log'). Clearly distinguishes from lgh_status by noting that lgh_log shows history rather than current health.

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 when investigating why a push or the server misbehaved in the past, and contrasts with lgh_status which shows the current health snapshot. This gives clear when-to-use 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?

The description fully discloses destructive behavior: permanently deletes the LGH-side backup and history, and explains recovery via lgh_add and lgh_up. It also states the local working tree and git history are never touched, providing complete transparency beyond the destructiveHint annotation.

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 succinct yet comprehensive, covering all essential aspects—what it does, what it doesn't do, failure conditions, and recovery—without unnecessary verbosity. It is well-structured and easy to parse.

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 absence of an output schema, the description sufficiently explains side effects, failure modes, and prerequisites. It provides all necessary context for an agent to safely and correctly invoke the tool, including a clear warning about destructiveness.

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 description for 'name' is present (100% coverage), and the description adds meaningful context by emphasizing that the name must be an exact registered name and that it will error otherwise. While it doesn't specify format details, the added guidance is useful.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool unregisters a repository from LGH, detailing that it deletes the bare backup repository and removes the 'lgh' remote. It distinguishes itself from sibling tools like lgh_add and lgh_up by focusing on removal, and mentions that the local working tree is untouched.

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 advises using lgh_list first to find the exact registered name, and notes that the tool fails if the name is not registered. This gives clear situational guidance and prerequisites, effectively telling when to use it relative to other 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?

Beyond the destructiveHint annotation, the description explicitly states that uncommitted changes and rolled-back commits are discarded, explains push behavior (force-push to LGH), and details the JSON return fields.

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 dense but not verbose; every sentence adds critical information (action, destructiveness, push behavior, return format, and alternatives). It is well-structured and appropriately sized.

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 the core action, destructive consequences, push behavior, return value, and recommended pre-rollback inspection tools. No essential context is missing for a destructive operation.

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 description adds context for push (force-push when enabled) and steps (N commits), and explains the overall effect on the repository. While the schema already covers parameter definitions, the description enriches understanding of their behavioral impact.

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 action: rolling back N commits via git reset --hard HEAD~N. It distinguishes from siblings by mentioning lgh_up and lgh_save for saving before rollback and lgh_diff/lgh_up_dryrun for inspection.

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 instructs to run lgh_up or lgh_save first if anything is worth keeping, and to use lgh_diff or lgh_up_dryrun to inspect what would be lost. This provides clear when-to-use 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?

The description discloses all behavioral traits beyond annotations: it 'ensures a .gitignore exists', 'Initializes git if the directory is not a repo yet', 'commits locally without pushing', and returns JSON with a human-readable output line. These details are consistent with the annotations (readOnlyHint=false, destructiveHint=false).

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 somewhat verbose (four sentences) but each sentence adds essential information: action, side effects, usage guidance, and return format. It is logically structured and not redundant, meriting a 4.

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 (2 parameters, no output schema, no nested objects), the description is complete: it covers purpose, usage, side effects, and return format. The absence of an output schema is compensated by explicitly describing the return value.

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%: both 'path' and 'message' have clear descriptions. The tool-level description adds no additional parameter-specific details beyond what the schema already provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Create a local checkpoint: ensures a .gitignore exists, then git add + git commit in the working directory WITHOUT pushing anywhere'. It also explicitly differentiates from lgh_up by noting 'switch to lgh_up when the work should also reach the LGH backup', making the resource and scope 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 direct usage guidance: 'Use this for intermediate saves; switch to lgh_up when the work should also reach the LGH backup.' It also mentions when it aborts ('aborts when trash detection finds blocking issues'), giving clear conditions for use.

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?

The description transparently communicates that it spawns a background daemon, returns startup output or an error (e.g., port already taken), and implies a persistent side effect. This matches the annotations (readOnlyHint=false, destructiveHint=false) and provides sufficient detail for expected 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?

The description is tight and well-structured, using two sentences to convey the core action, its context, and expected outputs. No redundant or vague wording.

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?

It includes when to use the tool, what to expect (startup output or error), and how to verify success (lgh_status). The absence of an output schema is acceptable given the clear narrative of returned information.

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 only parameter, port, is fully described with its default value and purpose. Schema coverage is 100%, and the description adds the default context, so no ambiguity remains.

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 (start), the resource (LGH HTTP server), and its purpose (hosts git endpoints). It distinguishes from siblings like lgh_serve_stop and lgh_status by focusing on the startup 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?

It explicitly states when to use this tool ('before lgh_up or before cloning from LGH') and advises checking lgh_status afterwards to confirm the PID and listen address, providing clear operational 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?

Annotations already indicate readOnly=false, destructive=false, idempotent=true; the description adds context that repositories/commits are unaffected and that it returns a friendly notice when not running, but does not contradict the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that convey purpose, safety, and return behavior with no fluff 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 no-parameter tool, the description covers what happens, when to use it, and what to expect (friendly notice). No output schema needed as return behavior is described.

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?

No parameters exist, so schema coverage is trivially 100%. The baseline score of 4 applies and the description adds no unnecessary parameter details.

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?

Clearly states the action (stop) and the resource (LGH HTTP server). No ambiguity about 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?

Explicitly notes it is safe to call speculatively as a cleanup step and recommends using lgh_status to avoid a no-op call, giving clear when-to-use 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?

The description is transparent about the tool's behavior: it 'reads only local state,' implying no side effects, and explains how the ActionD PID is obtained ('probed via its PID file'). It also discloses the output format (pretty-printed JSON), giving the agent a clear expectation of the result.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise yet comprehensive, using three well-structured sentences. It front-loads the purpose, lists the aggregated data, and provides usage and output details without redundancy or unnecessary fluff.

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 fully covers the tool's role in the ecosystem: it defines the health snapshot, explains the source of data (local state, PID file), specifies the return format, and explicitly contrasts with lgh_log for historical context. This is sufficient for an agent to decide 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?

The tool has zero parameters, and the description explicitly states 'Takes no arguments.' This eliminates any ambiguity about parameter usage, exceeding the baseline for parameterless tools by confirming there is nothing to pass.

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 explicitly states the tool's purpose: 'Get a unified health snapshot of the LGH server and the ActionD daemon.' It enumerates the specific data points aggregated (running state, PID, listen address, etc.) and distinguishes it from the sibling tool lgh_log, making its role unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly tells the agent when and how to use the tool: 'Takes no arguments' and 'safe to call at any time.' It also provides explicit selection guidance by contrasting with lgh_log for historical events, ensuring the agent chooses the correct tool for the situation.

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?

The description discloses the full workflow (git add, commit, push), the auto-init and registration behavior, and the abort-on-trash-detection logic when force is not set. It also notes the return format and CI trigger condition. However, it does not explicitly warn about potential remote overwrite or that pushes modify the remote repository 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?

The description is unnecessarily verbose and repetitive. It restates the same information multiple times (e.g., 'one-click backup', 'auto-registers', 'trash detection') and includes tangential details about ActionD that could be condensed. A shorter version would convey the same meaning more effectively.

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 covers the operation's side effects, error conditions, and return structure (success, output, project_type, commit, triggered_job_ids). It also explains the auto-initialization and registration behavior. It lacks only a note on typical failure modes or environmental prerequisites, but the essential context is present.

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?

All three parameters are documented in the schema with clear descriptions. The tool description adds contextual meaning, particularly for 'force' (skip trash detection) and 'message' (commit message). Since schema coverage is 100%, the description supplements rather than compensates, making this a strong but not maximal score.

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 purpose: a one-click backup that runs git add, commit, and push to the LGH local server. It also explicitly distinguishes LGH from GitHub/GitLab, eliminating ambiguity. The verb and resource are specific and immediately understandable.

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 does not provide guidance on when to use this tool versus alternatives like lgh_up_dryrun or lgh_save. It mentions behavior but not selection criteria. The user is left to infer the appropriate context from the operation itself.

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?

The description goes beyond the annotations by enumerating exactly what the tool reports (git repo status, changed files, LGH registration status, auto-register name, trash-detection results, failure reasons) and states it returns a JSON with dry_run=true. It also reaffirms the no-side-effect guarantee ('nothing is committed, pushed, registered, or written'), matching the readOnly and idempotent hints with no contradiction.

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 efficient: two sentences convey the core purpose, a third gives scoping and alternatives, and a fourth states the return format. No redundant wording; every sentence serves a distinct role.

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 includes all necessary context for an agent to decide when to invoke this tool: what it does, what it outputs, when to use it instead of lgh_up or lgh_diff, and its non-destructive nature. It is self-contained without needing external references.

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 only parameter 'path' is described fully as 'Absolute path to the LOCAL working directory (defaults to current directory)', providing both meaning and default behavior. With 100% schema coverage, the parameter semantics are 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?

The description clearly states the tool is a dry-run preview of lgh_up, explicitly names the sibling tool it simulates, and differentiates it from lgh_diff by contrasting the output type. The purpose is unambiguous and specific.

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 provides direct guidance on when to use this tool ('Call this before lgh_up whenever you are unsure what a backup would include') and when to use the alternative lgh_diff for patch content instead of a changed-file list. The situational selection is explicit.

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