github_fork_repo

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

The description is written as an Args-style listing, essentially mirroring the parameter names without adding behavioral context. It does not disclose side effects (e.g., the fork is created asynchronously on GitHub, no webhook/callback), permissions needed, or what happens on conflict. With no annotations provided, the description carries the full burden but adds minimal beyond parameter semantics.

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: a single purpose sentence followed by an Args block. The Args block is largely redundant with the input schema, which already documents each parameter. It is not padded, but it is not particularly front-loaded either, and the args list adds little informational value beyond the schema.

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 tool has an output schema, which reduces the need to document return values, but the description is thin for a mutation tool with no annotations. Given the many sibling tools in the github_* family (including create_repo, delete_repo), the description does not clarify the relationship between 'create repo' and 'fork repo' beyond the obvious. Provides no guidance on auth/connection prerequisites (e.g., does it require an active session?).

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. It lists each parameter in Args style with a brief inline phrase (e.g., 'empty = your personal account', 'empty = keep original name'). These inline notes genuinely add semantics beyond the schema's default markers, clarifying the empty-string defaults for org and new_name. However, session_name simply says 'GitHub session to use', which adds little beyond its name. Meaningful but modest value.

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?

'Fork a repository to your account or an organization' uses a specific verb (fork) with a clear resource (repository) and destination (account/org). It clearly communicates the tool's action. However, among the many sibling tools it does not explicitly distinguish itself beyond the verb itself, though the verb 'fork' is distinct enough given siblings are create/delete/update/get.

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 gives no when-to-use vs alternatives guidance. It does not mention that forking copies a repo for independent modification, when to prefer github_create_repo over forking, or any prerequisite such as needing an authenticated/active session. The sibling list is large and includes github_create_repo, so explicit guidance on choosing fork vs create would be valuable but is absent.

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