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

Annotations already cover the read-only, non-destructive, open-world profile, and the description goes beyond them by disclosing returned fields, newest-first sorting, and that completed lookups consume credits with possible repeat purchases. That pricing context is genuinely valuable for an agent deciding whether to call. However, the cost statements are internally inconsistent ('at least 10 Nexscope credits' vs. '1 credit per request'), which undermines confidence in the most decision-relevant sentence.

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 useful content is front-loaded, but the text then repeats itself: the purpose is restated ('Get public pull requests authored by a GitHub user'), the date filter is restated ('Filter by created date with since and until'), and the price is stated twice with conflicting values, followed by supplier boilerplate about units and non-guaranteed examples. Roughly half the text could be removed with no loss.

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?

With no output schema, the description correctly compensates by listing the returned fields (title, repo, state, created_at, url) and the sort order, and it documents date filters and the credit cost. What remains thin is pagination behavior — the cursor parameter exists but the description never explains paging or result limits — and how far back the public index reaches.

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 baseline is 3. The description does add meaning beyond the schema by stating that a username, handle, or profile URL are all acceptable for the handle parameter, which the schema text does not say. The cursor parameter and page-size behavior are never mentioned, so the addition is partial.

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 gives a specific verb and resource: search public GitHub pull requests authored by a specific user via GitHub's public search index. It is distinguishable from close siblings like social_github_user_activity or social_github_user_repositories, though the description never names those alternatives explicitly, so differentiation is inferred rather than stated.

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 implied by the framing (look up a user's PRs) and the description tells the caller what identifier to pass, but there is no explicit when-to-use/when-not-to-use guidance and no mention of which sibling tool to prefer for adjacent needs such as commits, issues, or repository activity. The one actionable hint — 'Pass username, handle, or url' — is useful but is parameter guidance, not selection guidance.

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