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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description does add genuinely useful behavior beyond that: cursor pagination and the fact that repeated requests may repurchase data. However, the cost statement contradicts itself ('at least 10 Nexscope credits' versus '1 credit per request'), leaving the agent with an unreliable cost signal for a paid lookup.

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 first three sentences are well front-loaded and information-dense. The tail, however, is pasted supplier boilerplate that repeats 'Get public accounts a GitHub user follows' and restates pricing twice in unpunctuated run-on form, diluting the useful content.

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, non-destructive lookup with no output schema, the definition covers the essentials: what is returned, how to address the user, pagination, and that it is paid. Remaining gaps are the interaction between handle and url, and the inconsistent credit figures, but nothing an agent needs to make the call is wholly absent.

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 coverage is 100%, so the three properties are already documented, and the description correctly notes cursor pagination. It does add that the identity can be supplied as handle or full profile URL, but it references a 'username' input that does not exist in the schema and never explains how handle and url interact if both are supplied.

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 opening sentence names a specific verb and resource with correct directionality: 'Retrieves public accounts followed by a GitHub user,' which clearly separates it from the followers lookup sibling. It also enumerates the returned fields (login, avatar, profile URL, type, GitHub IDs), so the agent knows exactly what it gets. The raw appended 'GitHub Following API' boilerplate adds no differentiation beyond the first sentence.

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?

Usage is only implied: the description tells the agent it can 'Pass username, handle, or a full GitHub profile url' but never states when to prefer this tool over social_github_user_followers, social_github_user, or social_github_user_activity. There is no note that all three identifier parameters are optional and which one to prefer, which matters for a zero-required-parameter tool.

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