Summary: This MCP server resolves a company domain (or GitHub org) to its GitHub organization and returns a single flat, Clay-ready JSON row of engineering signals.
Resolve org identity — look up a company by company_domain or company name, or skip discovery entirely by passing a known github_org.
Get organization metrics — public repo count, followers, org creation date, location, and account type.
Extract repository signals — top languages, total stars, most-starred repo, most recent push, and count of repos active within a chosen window (30/90/180/365 days).
Detect public SDKs — flag whether the company ships a public developer SDK.
Control cost and completeness — tune repo page budget (1/2/3/5 pages of 100); the row reports repos sampled, excluded (forks/archived), and whether the sample was complete.
Estimate engineering surface — optionally read the contributor count of the most-starred repo.
Use your own GitHub token — run keyless at 60 req/hr or supply githubToken/GITHUB_TOKEN for 5,000 req/hr.
Cache and cap spend — successful lookups cached 7 days (skipCache to bypass) and a max_charge_usd cap per run.
Trustworthy edge handling — rate-limited calls report not_extractable (never a false zero), and personal accounts are flagged identity_mismatch; rejected candidates are recorded.
Stack with other actors — company_domain is the join key for every other Mamba Labs GTM Suite actor.
Read-only, requires an APIFY_TOKEN, and consumes Apify credits per call.
Resolves a company domain to its GitHub organization and reads organization and repository metadata to derive signals such as repository count, followers, creation date, top languages, total stars, recent push activity, active repositories, and public SDK presence.
An MCP server that resolves a company domain to its GitHub organization with repo, language and activity signals. It wraps the Mamba Labs GitHub Organization Signal Scanner actor on Apify and returns a Clay-ready flat JSON row to any MCP client.
Related MCP server: mcp-company-contact-details-extractor
Give it a company domain and it finds that company's GitHub organization and returns repository count, followers, creation date, top languages, total stars, the most recent push, how many repositories are actively worked on, and whether the company ships a public SDK. One flat row per company, read through GitHub's own documented REST API.
Forks and archived repositories are excluded from the language and star derivations, and the exclusion is counted on the row. A rate limited request reports not_extractable and never a zero, because a zero is a number a buyer would filter on. A login that resolves to a personal user account rather than an organization is reported as identity_mismatch. It reads organization and repository metadata only: it does not clone repositories, read source, scan for secrets or assess code quality.
All of the scanning runs on Apify. This package is a thin client that calls the actor and hands back the result unchanged.
You need Node.js 18 or newer and an Apify account with an API token.
Add this to your Claude Desktop config:
{
"mcpServers": {
"mamba-github-organization-signal-scanner": {
"command": "npx",
"args": ["-y", "@mambalabsdev/mcp-github-organization-signal-scanner"],
"env": {
"APIFY_TOKEN": "your-apify-token"
}
}
}
}Get your token at https://console.apify.com/account/integrations, paste it in, and restart Claude Desktop. The scan_github_organization_signals tool will be available.
Node.js 18 or newer
An Apify account with an API token
Optional: your own GitHub personal access token, free to create at github.com/settings/tokens with no scopes at all for public data, if you want to scan more than a handful of companies
"Find the GitHub organization for stripe.com and summarize its activity."
"Scan the GitHub org vercel and tell me its top languages and total stars."
"Does figma.com ship a public SDK? Check its GitHub organization."
"Scan notion.so's GitHub org, counting a repo as active if it was pushed in the last 30 days."
company_domain (optional): bare company domain, for example stripe.com. This is the lookup key and the join key for every other actor in the fleet.
company_name (optional but strongly recommended): what the identity gate checks a discovered record against, so supplying it is the cheapest way to reduce wrong matches.
github_org (optional): if you already know the organization login, for example stripe, put it here and the tool skips discovery entirely and goes straight to the API, which is faster and spends fewer rate limited requests.
includeRepoDetail (optional): when true (the default) the organization repositories are read and the language, star, activity and SDK signals are derived from them. Set false to return the organization record only, which is one request instead of several and is friendlier to the unauthenticated rate limit.
includeContributorEstimate (optional): when true one extra request reads the contributor count of the organization's most starred repository, as a floor on the size of its public engineering surface. False by default, because one extra request per company is real money against a 60 per hour unauthenticated budget.
activeWindowDays (optional): how recently a repository must have been pushed to count as active. One of 30, 90, 180 or 365, with 90 the default. This changes what active means on the row.
repoPageBudget (optional): how many pages of 100 repositories to read for a large organization. One of 1, 2, 3 or 5. This is a cost and completeness dial, not a change of answer: the row always reports how many repositories were sampled and whether the sample is complete.
githubToken (optional): your own GitHub personal access token, free to create with no scopes at all for public data. Without it the tool runs at GitHub's 60 requests per hour, which is enough for a handful of companies and not enough for a list. With it the limit is 5,000 per hour.
skipCache (optional): when false (the default) a successful lookup is cached for seven days and reused. Set true to force a fresh fetch.
max_charge_usd (optional): a cost cap in USD for this run. The actor stops before an item that could take its charges past this amount. Omit it to rely on the maximum cost per run set in Apify.
The tool returns the actor's flat JSON row for the company, with 32 snake_case fields and no nested objects. github_discovery says how the organization was found, github_rejected_candidate records a candidate the identity gate turned away, repos_sampled and repos_complete say how much of the organization was read, and repos_excluded counts the forks and archived repositories left out. See the Apify Store page for the full output schema.
{
"degraded": false,
"degradation_reason": null,
"company_domain": "stripe.com",
"company_name": "Stripe",
"github_org": "stripe",
"github_url": "https://github.com/stripe",
"github_discovery": "homepage_link",
"github_rejected_candidate": null,
"github_account_type": "Organization",
"public_repos": 98,
"followers": 3469,
"org_created_at": "2011-06-17T15:42:37Z",
"org_location": "San Francisco, CA",
"top_languages": "TypeScript, Go, Ruby, JavaScript, HTML",
"total_stars": 42821,
"most_starred_repo": "stripe-node",
"most_starred_repo_stars": 4485,
"most_recent_push_at": "2026-08-22T18:33:15.000Z",
"active_repos_90d": 56,
"has_public_sdk": true,
"repos_sampled": 98,
"repos_complete": true,
"repos_excluded": "forks=6, archived=5",
"rate_limit_remaining": 57,
"coverage": 1,
"fetch_status": "ok",
"run_date": "2026-08-22T19:23:50.177Z"
}Resolves a GitHub organization starting from a company domain
Repository count, stars, followers and top languages
Recent push activity and repositories active in a window you choose
Public SDK detection, a direct developer tooling signal
Runs keyless, with your own GitHub token available for scale
Rejected candidates recorded in github_rejected_candidate
32 flat snake_case fields, one row per company
Price per event on the Apify FREE plan, from the live pricing record; paid Apify plans pay less per event.
Event | Price (USD) |
Actor Start ( | 0.00005 |
Company checked ( | 0.003 |
Organization resolved ( | 0.0025 |
Repository signals extracted ( | 0.003 |
This server is a thin client and holds no scanning logic. For the complete input and output reference, pricing, and run history, see the Apify Store page:
https://apify.com/mambalabs/github-organization-signal-scanner
This server is one of the Mamba Labs GTM Suite MCP servers. Every actor in the suite takes a domain or a company and returns one flat row, so they stack in the same Clay table without reshaping anything. The actor behind this server is the GitHub Organization Signal Scanner, immutable Apify actor ID ahF8RRpv5mzPao5CN.
Built by Mamba Labs | npm | Apify Store
MIT
Built by Mamba Labs. https://apify.com/mambalabs
Resolve a company domain to its GitHub organization and return repository count, followers, creation date, top languages, total stars, the most recent push, how many repositories are actively worked on, and whether the company ships a public SDK. Returns one flat Clay ready row. Forks and archived repositories are excluded from the language and star derivations and the exclusion is counted on the row. A rate limited request reports not_extractable and NEVER a zero, because a zero is a number a buyer would filter on. A login that resolves to a personal user account rather than an organization is reported as identity_mismatch. Read only; requires an APIFY_TOKEN and consumes Apify credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| skipCache | No | When false (default) a successful lookup is cached for seven days and reused, which costs you nothing on a repeated run. Set true to force a fresh fetch. | |
| github_org | No | Optional. If you already know the organization login, for example "stripe", put it here and the actor skips discovery entirely and goes straight to the API, which is faster and spends fewer of your rate limited requests. | |
| githubToken | No | YOUR OWN GitHub personal access token, free to create at github.com/settings/tokens with no scopes at all for public data. OPTIONAL: without it the actor runs at GitHub 60 requests per hour, which is enough for a handful of companies and not enough for a list. With it the limit is 5,000 per hour. A token passed here travels in the tool call and stays in the chat transcript, so prefer setting GITHUB_TOKEN in this server's environment: when this argument is omitted the server sends that variable instead. | |
| company_name | No | Optional but strongly recommended. It is what the identity gate checks a discovered record against, so supplying it is the single cheapest way to reduce wrong matches. | |
| company_domain | No | Bare company domain, for example stripe.com. This is the only required input and it is the join key for every other actor in the fleet. | |
| repoPageBudget | No | How many pages of 100 repositories to read for a large organization. This is a cost and completeness dial, not a change of answer: the row always reports how many repositories were actually sampled and whether the sample is complete. | |
| activeWindowDays | No | How recently a repository must have been pushed to count as active. 90 days by default. This changes what "active" means on the row, so pick the window your own definition of an engaged engineering team uses. | |
| includeRepoDetail | No | When true (default) the organization repositories are read and the language, star, activity and SDK signals are derived from them. Set false to return the organization record only, which is one request instead of several and is much friendlier to the unauthenticated rate limit. | |
| includeContributorEstimate | No | When true the actor spends one extra request to read the contributor count of the organization most starred repository, as a floor on the size of its public engineering surface. Default false, because one extra request per company is real money against a 60 per hour unauthenticated budget. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description goes well beyond them: rate-limited requests report not_extractable and 'NEVER a zero,' a personal-account match is flagged identity_mismatch, forks/archived repos are excluded and counted, and it discloses an APIFY_TOKEN requirement plus per-call Apify credit spend. This is exactly the extra behavioral context the lower bar asks for.
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 front-loads the purpose and return shape before moving to failure modes and auth, and every sentence carries information. It is dense in places — the return-field list is a long comma chain — but for a 9-parameter tool with no output schema it wastes little.
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?
There is no output schema, so the description carries the return-value burden itself and does so: it lists the fields, explains the sentinel values (not_extractable, identity_mismatch), and states the fork/archive exclusion accounting. Combined with auth requirements and credit cost, an agent has everything needed to call this correctly.
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 100%, and the per-parameter schema text is itself unusually rich (defaults, cost tradeoffs, rate-limit math), so the baseline of 3 applies. The body text does not add syntax or format detail beyond what the schema already documents for each argument.
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 ('Resolve a company domain to its GitHub organization') and then enumerates the exact signals returned: repository count, followers, creation date, top languages, total stars, most recent push, active repo count, and public SDK presence. An agent knows precisely what this tool produces without opening any other field.
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?
It gives clear operational context on how to invoke it well — prefer the environment GITHUB_TOKEN over the inline argument for transcript safety, set skipCache=true to force a fresh fetch, and supply company_name as 'the single cheapest way to reduce wrong matches.' With no sibling tools there is no alternative to route against, so the absence of a when-not clause is expected rather than a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.1scan_github_organization_signals7 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / activeWindowDays / descriptionPrevious value: -"How recently a repository must have been pushed to count as active. 90 days by default. This changes what \"active\" means on the row, so pick the window your own definition of an engaged engineering team uses. Sent as a string for Clay compatibility."New value: +"How recently a repository must have been pushed to count as active. 90 days by default. This changes what \"active\" means on the row, so pick the window your own definition of an engaged engineering team uses."Input schema / properties / githubToken / descriptionPrevious value: -"YOUR OWN GitHub personal access token, free to create at github.com/settings/tokens with no scopes at all for public data. OPTIONAL: without it the actor runs at GitHub 60 requests per hour, which is enough for a handful of companies and not enough for a list. With it the limit is 5,000 per hour. It is marked secret, so the value never renders on this page."New value: +"YOUR OWN GitHub personal access token, free to create at github.com/settings/tokens with no scopes at all for public data. OPTIONAL: without it the actor runs at GitHub 60 requests per hour, which is enough for a handful of companies and not enough for a list. With it the limit is 5,000 per hour. A token passed here travels in the tool call and stays in the chat transcript, so prefer setting GITHUB_TOKEN in this server's environment: when this argument is omitted the server sends that variable instead."Input schema / properties / includeContributorEstimate / descriptionPrevious value: -"When \"true\" the actor spends one extra request to read the contributor count of the organization most starred repository, as a floor on the size of its public engineering surface. Default \"false\", because one extra request per company is real money against a 60 per hour unauthenticated budget. Sent as a string for Clay compatibility."New value: +"When true the actor spends one extra request to read the contributor count of the organization most starred repository, as a floor on the size of its public engineering surface. Default false, because one extra request per company is real money against a 60 per hour unauthenticated budget."Input schema / properties / includeRepoDetail / descriptionPrevious value: -"When \"true\" (default) the organization repositories are read and the language, star, activity and SDK signals are derived from them. Set \"false\" to return the organization record only, which is one request instead of several and is much friendlier to the unauthenticated rate limit. Sent as a string for Clay compatibility."New value: +"When true (default) the organization repositories are read and the language, star, activity and SDK signals are derived from them. Set false to return the organization record only, which is one request instead of several and is much friendlier to the unauthenticated rate limit."Input schema / properties / repoPageBudget / descriptionPrevious value: -"How many pages of 100 repositories to read for a large organization. This is a cost and completeness dial, not a change of answer: the row always reports how many repositories were actually sampled and whether the sample is complete. Sent as a string for Clay compatibility."New value: +"How many pages of 100 repositories to read for a large organization. This is a cost and completeness dial, not a change of answer: the row always reports how many repositories were actually sampled and whether the sample is complete."Input schema / properties / skipCache / descriptionPrevious value: -"When \"false\" (default) a successful lookup is cached for seven days and reused, which costs you nothing on a repeated run. Set \"true\" to force a fresh fetch. Sent as a string for Clay compatibility."New value: +"When false (default) a successful lookup is cached for seven days and reused, which costs you nothing on a repeated run. Set true to force a fresh fetch."v1.0.0scan_github_organization_signalsScored across 1 tool
There is only one tool, so there is no possibility of misselection or overlapping purposes. An agent will always pick the correct (and only) tool for this server's scope.
The single name, scan_github_organization_signals, follows a clear verb_noun snake_case convention that is self-consistent. There is no mixed style or ambiguity in the naming.
The server is intentionally a single-purpose scanner returning one flat row, so one tool is defensible and nothing is redundant. However, one tool is thin: there is no batch or multi-domain entry point, so scope flexibility is limited.
For a read-only signal scanner, the surface is quite complete: it aggregates org resolution, repo counts, languages, stars, activity, SDK presence, exclusion counts, and error states into one row. Minor gaps exist (no bulk/batch scanning of multiple domains and no follow-up detail drill-down), but core use cases are covered.
Apify MCP — run web-scraping Actors and fetch their dataset results.
17 data tools in one MCP server, run on Apify: Google Shopping, Flights, Hotels, News, Images, Videos, Ads Transparency, Jobs and Trends; YouTube transcripts; AI visibility checks; Google Maps leads; App Store and Google Play reviews. Pay per result. Sign in with Apify (OAuth) or an API token.
MCP server for Google search results via SERP API
Managed LinkedIn MCP server for AI agents: search, connect, message and enrich on accounts you own.
