List Git installation repositories

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

Annotations already state readOnlyHint and destructiveHint, but the description adds substantial behavioral context: live provider reads, failure on inactive installations, truncation at 500 repositories, 404 for non-customer installations, and rate limiting with 429 responses. No contradiction with 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?

The description is longer than typical but every sentence carries distinct behavioral or usage information. It is front-loaded with the core purpose, followed by practical caveats and downstream references. Slightly dense but not padded.

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 read-only list tool with one parameter and no output schema, the description covers provider scope, failure modes, truncation, rate limits, and downstream usage. It stops short of explicitly listing response fields, but the mention of 'owner, name and a branch' gives a useful hint about returned data.

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, `uuid`, is fully documented in the schema with 100% coverage, so the baseline is 3. The description does not add new parameter semantics but reinforces that the installation should be active, which is already implied by the usage guidance.

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 states a specific action ('Lists the repositories'), the resource ('the Git installation can access'), and a distinguishing qualifier ('read live from the provider'). It also scopes supported providers (github/gitlab), making it clearly distinct from sibling tools like hosting_listGitInstallationsV1.

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 tells when to use the tool ('Use an active installation') and what happens otherwise ('suspended or pending one is still queried and the call fails'). It also provides a when-not-to-use rule ('when the account has more, name the repository directly instead of searching this list') and references downstream consumers, giving strong practical guidance.

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