Skip to main content
Glama
mambalabsdev

mcp-github-organization-signal-scanner

Scan GitHub Organization Signals

scan_github_organization_signals
Read-onlyIdempotent

Resolve a company domain to its GitHub organization and return repository, language, activity, and SDK signals for enrichment.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
skipCacheNoWhen 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_orgNoOptional. 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.
githubTokenNoYOUR 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_nameNoOptional 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_domainNoBare 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.
repoPageBudgetNoHow 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.
activeWindowDaysNoHow 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.
includeRepoDetailNoWhen 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.
includeContributorEstimateNoWhen 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.1.1
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / activeWindowDays / description
      Previous 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."
    • changedInput schema / properties / githubToken / description
      Previous 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."
    • changedInput schema / properties / includeContributorEstimate / description
      Previous 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."
    • changedInput schema / properties / includeRepoDetail / description
      Previous 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."
    • changedInput schema / properties / repoPageBudget / description
      Previous 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."
    • changedInput schema / properties / skipCache / description
      Previous 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."
  2. First observedv1.0.0

TDQS

A4.4/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server

Other Tools