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.
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
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. Sent as a string for Clay compatibility. | |
| 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. It is marked secret, so the value never renders on this page. | |
| 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. Sent as a string for Clay compatibility. | |
| 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. Sent as a string for Clay compatibility. | |
| 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. Sent as a string for Clay compatibility. | |
| 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. Sent as a string for Clay compatibility. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by explaining rate-limit sentinels (not_extractable is never zero), identity_mismatch for personal accounts, exclusion of forks and archived repos, and the reporting of that exclusion on the row. It also discloses cost and auth implications. No contradiction with the readOnly, idempotent, openWorld, or destructive annotations exists.
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 is compact and front-loaded: the first sentence states purpose and outputs, and each following sentence adds a necessary behavioral or operational detail. There is no filler, repetition of the schema, or vague framing.
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 tool with nine parameters and no output schema, the description covers the return values, edge cases, error semantics, data exclusions, authentication needs, and credit consumption. Combined with the fully described input schema, an agent has enough information to select and invoke the tool 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?
The input schema provides 100% description coverage, with every one of the nine parameters individually documented including enums, defaults, and Clay compatibility. The main description adds little parameter-level detail, so the baseline of 3 is appropriate because the schema carries the full burden.
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 description opens with a specific verb and resource: 'Resolve a company domain to its GitHub organization' and then enumerates the exact computed signals returned. It clearly distinguishes itself from the title by adding operational scope and output details. No sibling tools exist, so differentiation is not required.
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?
The description gives clear context for use, identifies the principal input (company domain), and states key prerequisites: it is read-only, requires an APIFY_TOKEN, and consumes Apify credits per call. It does not explicitly discuss when not to use the tool, but with no sibling alternatives the guidance is sufficient.
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.0.0scan_github_organization_signalsScored across 1 tool
Only one tool exists, so there is no possibility of confusing it with another tool. Its purpose is explicitly and comprehensively documented in the description.
The single tool name follows the verb_noun snake_case convention (scan_github_organization_signals), and with only one tool there are no naming inconsistencies possible.
One tool is below the typical 3-15 range, but the server's narrow purpose of scanning a single domain into one Clay-ready row does not obviously require additional tools. It feels slightly thin but reasonable rather than egregiously under-scoped.
The single tool returns a comprehensive set of GitHub organization signals, handles edge cases like rate limits and personal accounts, and accounts for exclusions. For the stated single-purpose scope, coverage is complete.
Apify MCP — run web-scraping Actors and fetch their dataset results.
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.
Hosted MCP server for live public-data APIs and Skills for AI agents.
