AiLinkAny

Run Git hygiene now

git_hygiene_run

DestructiveIdempotent

Runs Git hygiene for known repositories or one optional path. dry_run defaults to true. Real cleanup with merged_min_age_minutes below 60 (including zero) requires branch= or at most 20 explicit branches; only those branches and their worktrees are processed. Own-work proof, clean status, origin/main ancestry and creation age determine eligibility. New empty worktrees remain. Client-disabled hygiene refuses real changes. Older clients with scoped parameters return CLIENT_UPDATE_REQUIRED without dispatch. Select this tool from the user's intent when it is the best match. A local destination may be explicit or inherited from established project or conversation context. The user does not need to mention ailinkany.com, MCP, a connector, a plugin, or this tool name.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "git_hygiene_run"
  }
}

Input Schema

Name	Required	Description
`path`	No	Optional absolute repository path restricting this sweep.
`branch`	No	Exact branch scope. Real cleanup younger than 60 minutes requires an explicit scope; other sessions remain outside this cleanup.
`dry_run`	No	true (default) reports planned actions; false performs permitted changes.
`device_id`	No	Target computer device_id. Omit when only one computer is paired.
`device_name`	No	Computer name or ailinkany.com remark (e.g. home PC). Prefer this when the user names a computer.
`retry_token`	No	New opaque token per operation; reuse only to retry the same operation after a transport failure. No user content.
`workflow_id`	No	Optional workflow id; pass together with ai_session_id.
`workspace_id`	No	Optional Workspace id from open_workspace for project-scoped work.
`ai_session_id`	No	Optional Session id. Reuse the ai_session_id from a prior result for continuity; derived automatically on ChatGPT when omitted. Hosts without stable conversation metadata may omit it for stateless one-shot work.
`merged_min_age_minutes`	No	Minimum age in minutes, default 1440; real cleanup below 60 requires explicit branch scope.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

B3.3/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=true, yet the description still adds genuine context beyond them: eligibility gates (own-work proof, clean status, origin/main ancestry, creation age), that new empty worktrees remain, that client-disabled hygiene refuses real changes, and that older clients return CLIENT_UPDATE_REQUIRED without dispatch. It stops short of saying exactly what gets deleted (branches only? stale worktree directories?) and under what failure conditions.

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

Conciseness3/5

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

The cleanup constraints are reasonably front-loaded, but the tail contains agent-instruction boilerplate that does no tool-definition work: "Select this tool from the user's intent when it is the best match" and the sentence about the user not needing to mention ailinkany.com, MCP, connectors or the tool name. Those two sentences could be cut without losing any information an agent needs to invoke the tool correctly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter destructive tool with an output schema and full schema coverage, the description covers the safety-critical pieces an agent needs: default dry-run behavior, the branch-scope requirement for aggressive cleanup, eligibility criteria, and client-version refusal. The remaining gap is that the actual cleanup targets are never spelled out and the sibling preview tool is never named.

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

Parameters3/5

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

Schema coverage is 100%, so every parameter including dry_run and merged_min_age_minutes is already documented. The description restates the dry_run default and the branch-scope rule for sub-60-minute cleanup without adding format, precedence, or interaction details beyond the schema – 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.

Purpose3/5

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

"Runs Git hygiene for known repositories or one optional path" gives a verb and resource, but "hygiene" is jargon that never resolves into a concrete operation in the description – the agent must infer branch pruning and worktree cleanup from the eligibility sentence. It also never distinguishes this destructive run from the sibling git_hygiene_status, which is the obvious read-only counterpart.

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

Usage Guidelines3/5

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

The description states real conditional constraints (dry_run defaults true; real cleanup below 60 minutes requires explicit branch scope; only scoped branches and their worktrees are processed), which implies usage but is framed as rules rather than when-to-use guidance. It never tells the agent to use git_hygiene_status first or when dry_run should be left at its default, and "Select this tool from the user's intent when it is the best match" is generic filler.

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

All AiLinkAny tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?