github_get_repo

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description states it's a read operation ('get detailed information') and lists what fields are shown, which is helpful. However, it doesn't disclose whether an active connection/session is required, auth behaviors, rate limits, or error behavior (e.g., behavior when repo doesn't exist). For a read tool with zero annotation coverage, this leaves meaningful gaps.

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 with a clear purpose statement, then parameter notes. The two first sentences are useful; the generated 'Args:' block adds marginal value. No wasted prose, but the structure leans on the auto-generated parameter section which repeats schema titles with minimal added meaning.

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?

An output schema exists, so return-value documentation isn't required of the description. For a straightforward single-repo read operation, the description covers the purpose and key visible fields. The main gap is auth/session prerequisites, but overall this is reasonably complete for the tool's simplicity and given the presence of an output schema.

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 0%, so the description must compensate for the three undocumented parameters. It does list the three args inline (owner, repo, session_name) with brief descriptions ('Repository owner', 'Repository name', 'GitHub session to use'). This adds modest value beyond the schema, but the descriptions are terse and don't explain e.g., that session_name selects among saved credentials, or provide format guidance for owner/repo.

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 it gets detailed repository info and enumerates specific data fields (stars, forks, languages, default branch, license). The verb 'get' combined with the specific resource 'repository' is clear. It doesn't explicitly distinguish from siblings like github_list_repos or github_get_branch, but the informational scope is reasonably clear for a single-repo fetch.

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 implies this is for fetching info about a specific repository, and the parameter list (owner, repo) makes the use case clear. However, it doesn't explicitly differentiate from github_list_repos (which lists repos) or provide when-to-use guidance, nor state prerequisites like needing an active session/connection. Some guidance is implied but not explicit.

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