GitHub Followers and Following Export MCP Server

Export GitHub followers and following

export_github_followers_following

Read-onlyIdempotent

Export public GitHub followers and following lists as rows with login, name, company, location, bio, profile URL, and user ID, plus a completeness report per list.

Instructions

Export the followers and following lists of public GitHub accounts: one row per person with login, name, company, location, bio, profile URL, and user ID, plus a free report per list that says whether it was read to the end. No GitHub login. An optional buyer token reads faster with fewer fields.

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": "export_github_followers_following"
  }
}

Input Schema

Name	Required	Description
`list`	No	followers, following, or both (default).
`users`	No	Usernames or profile URLs of public GitHub accounts, up to 100 a run. Clay users: wrap a column in a one item list.
`github_token`	No	Optional. Your own GitHub token reads through the REST API at up to 5,000 requests an hour, with login, user ID, and avatar only: no name, company, location, or bio. Never stored or logged.
`max_charge_usd`	No	Optional. The run stops before a charge that would pass this amount. Summary rows are always returned.
`max_results_per_list`	No	Rows to return per list, from 1 to 100000. Default 1000. Each row is charged. Large lists also need a longer run timeout: about 400 rows a minute.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 9, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, yet the description adds substantial non-obvious behavior: a per-list 'read to the end' completeness report, no authentication requirement, and a rate/field trade-off for tokens. It still omits output format (file vs JSON rows) and what happens when a username cannot be resolved.

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 tight sentences: resource and output shape first, then the no-login fact, then the token trade-off. Every clause carries information, though 'buyer token' is undefined jargon that only becomes clear from the schema.

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?

For a 5-parameter, all-optional export tool with no output schema, the description covers output shape, completeness reporting, cost model and rate limits. Remaining gaps are peripheral — result format and error handling for unresolvable accounts.

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 list, users, github_token, max_charge_usd and max_results_per_list are all documented in the schema itself. The description only restates the token trade-off ('reads faster with fewer fields') and adds no new parameter meaning, matching the baseline for a fully documented schema.

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

Purpose5/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 ('Export the followers and following lists of public GitHub accounts') and enumerates the returned columns (login, name, company, location, bio, profile URL, user ID). An agent knows exactly what it gets without opening the schema, and there are no siblings to disambiguate against.

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

Usage Guidelines4/5

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

It gives clear operating context — works on public accounts, no GitHub login needed, and the token variant trades fields for speed. There is no explicit when-not-to-use guidance or mention of failure cases (private/suspended accounts, invalid usernames), so it stops short of full routing guidance.

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

Deploy Server

Other Tools

export_github_followers_followingA