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 repo count, followers, creation date, top languages, stars, recent push, active repos, and SDK presence in one row.

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. Sent as a string for Clay compatibility.
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. It is marked secret, so the value never renders on this page.
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. Sent as a string for Clay compatibility.
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. Sent as a string for Clay compatibility.
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. Sent as a string for Clay compatibility.
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. Sent as a string for Clay compatibility.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.5/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server

Other Tools