git_config

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

The description reinforces the annotations with 'Does NOT modify configuration — it is read-only,' and adds critical behavior: 'Returns: the value of the requested config key, or the full git config --list output when key is omitted; an unset key returns a specific message without error.' This goes beyond annotations by detailing the return behavior for omitted and unset keys.

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 logically structured, with each sentence carrying purpose. However, the 'Best for' line largely repeats the earlier 'Use this' sentence, creating slight redundancy; still, it remains efficient overall.

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 simple tool with no output schema, yet the description covers the core action, usage context, read-only safety, return format for key/none, and unset-key behavior. Combined with fully described parameters, the description is sufficiently complete for an agent to invoke 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?

The schema already provides 100% description coverage for both parameters, including default values and behavior for empty key. The description adds minimal parameter-specific meaning beyond the schema; most of its added value pertains to return behavior rather than parameter semantics.

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 opens with a specific verb and resource: 'Read git configuration values from the repository, either one key or the full list.' This clearly distinguishes it from sibling git tools, and it explicitly points to git_remote for remote URLs, differentiating scope.

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 explicit guidance: 'Use this to verify settings like user.name, user.email, core options, or remote URLs before operating' and 'Best for: checking settings...' It also states the read-only nature and suggests an alternative: 'use git_remote for a friendlier view of remote URLs.' This gives both when-to-use and an alternative.

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