ScrapeCreators MCP Server

User

github_user

Retrieve public GitHub user details like name, bio, avatar, company, location, blog, followers, repos, and account timestamps by username, handle, or URL. Requires confirm=true for paid API use.

Instructions

Retrieves public GitHub user details including name, bio, avatar, company, location, blog, follower counts, public repo counts, and account timestamps. Pass username, handle, or a full GitHub user url. Potentially consumes paid API credits; requires confirm=true. Read-like POST requests do not publish to social platforms.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "github_user"
  }
}

Input Schema

Name	Required	Description
`url`	No	GitHub user URL, e.g. https://github.com/torvalds.
`handle`	No	GitHub username/handle of the user you want the details for
`account`	No	Named private ScrapeCreators account; selects credentials, not a remote account ID.
`confirm`	No	Must be true for the specific approved credit-consuming research call.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.0Oct 2, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false, which would otherwise puzzle an agent calling a simple profile lookup; the description resolves this by disclosing that it is a "read-like POST" that does not publish to social platforms. It also adds two genuinely non-schema facts: possible paid credit consumption and the confirm=true gate. It omits rate-limit or failure behavior, keeping it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the payload contents before operational caveats. Every sentence carries information, and the credit/confirm note is placed after the core purpose. The read-like-POST clarification is slightly boilerplate but earns its place given readOnlyHint=false.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, but the description enumerates the returned fields, which compensates. It covers the credit cost and confirm requirement, and the identifier input forms. It leaves gaps around what happens without confirm and whether the identifier parameters are alternatives, so it is strong but not exhaustive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters are already documented by the schema, making 3 the baseline. The sentence "Pass username, handle, or a full GitHub user url" mostly restates the url/handle descriptions and does not clarify the alternative semantics of the account parameter or whether url/handle are mutually exclusive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ("Retrieves public GitHub user details") and enumerates the returned fields (name, bio, avatar, company, location, blog, follower counts, repo counts, timestamps). The scope is unmistakably the profile-lookup tool rather than the sibling github_repositories or github_followers. It stops short of explicitly naming a sibling to differentiate against, so it lands just under a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It tells the agent what to pass (username, handle, or full GitHub url) and that confirm=true is required, which is actionable. However, it never contrasts with alternatives such as github_followers, github_contributions, or github_repositories, and gives no when-not guidance. Usage is implied rather than instructed.

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

Deploy Server