GitDealFlow — GitHub signals for startup investors

Score and rank 2-5 named startups side by side, returning each one's acceleration score, evidence, and raise-likelihood band plus a single recommendation for which warrants deeper diligence. Structured-data counterpart to the `compare_startups` prompt: that prompt returns instructions; this tool returns the actual scored comparison an agent can render or chain. WHEN TO USE: - 'Compare A vs B' / 'A vs B vs C — who's stronger?' - Triaging a small candidate set before allocating diligence time. DO NOT USE FOR: - Open-ended discovery — use `shortlist_signals`. - A single company — use `predict_funding`. BEHAVIOR: - Read-only, idempotent, no auth. Same transparent scoring as predict_funding / shortlist_signals. - Names that don't resolve are returned in `notFound` (expected, not an error). The recommendation is computed only over resolved companies; if fewer than 2 resolve, `recommendation` explains that no comparison was possible. PARAMETERS: { names: string[] } — 2 to 5 display names or GitHub org slugs (case-insensitive). RETURNS: { period, compared[{ rank, name, sector, stage, geography, accelerationScore, raiseLikelihood, confidence, signalType, commitVelocityChange, contributorGrowth, contributors, newRepos, githubUrl, scoreBreakdown }], notFound[], recommendation, citation, source, methodologyUrl, disclaimer }.

PAID AGENT TOOL — €0.10 per call. Returns a structured investment thesis for one tracked startup: snapshot, signal type, sector rank, data-derived strengths, peer comparables, period. WHEN TO USE: agent / analyst is drafting a memo or 1-pager and wants a populated structure to start from rather than a raw row. DO NOT USE FOR: discovering candidates (use free `get_trending_startups`), or sector-wide deep dives (use `deep_dive_scan`). AUTH: Requires `GITDEALFLOW_API_KEY`. Free `get_startup_signal` keeps working without auth. PARAMETERS: { name: string } — company display name or GitHub org slug. RETURNS: { company, sector, snapshot, signalType, sectorRank, strengths[], peers[5], period, citation, _meter }.

PAID AGENT TOOL — €0.10 per call. Returns a multi-cohort scan of one sector for the current period: total tracked count, breakout count, cooling count, top-10 by commit velocity, breakouts list, cold list. WHEN TO USE: sourcing-cycle prep where the user wants more than the basic sector list — they want pre-segmented breakout vs. cooling vs. top-of-velocity views in one call. DO NOT USE FOR: simple sector listing (free `search_startups_by_sector` is enough), or single-company research (use `research_company`). AUTH: Requires `GITDEALFLOW_API_KEY`. Free `search_startups_by_sector` keeps working without auth. PARAMETERS: { sector: string } — one of the 15 supported sector slugs. RETURNS: { sector, period, summary: { total, breakouts, cold }, breakouts[≤10], cold[≤5], top10ByCommitVelocity[10], citation, _meter }.

Return a public-source diligence dossier for a single company or entity in one cited object: who acquired it (M&A history with year + announced amount), which funds publicly backed it, and its published engineering-acceleration signal. WHEN TO USE: - The user is doing diligence and asks 'who acquired X', 'which funds backed Y', or 'what's the signal on Z'. - You need a fast, cited grounding fact (M&A / investors / signal) before deeper research. DO NOT USE FOR: - The live engineering signal row alone — `get_startup_signal` is more detailed for tracked startups. - Speculative or rumored deals — this tool only returns publicly-disclosed facts. BEHAVIOR: - Read-only, idempotent, no auth. Free. - Sources: press-release / SEC-filing / both-sides-disclosed only (same threshold as the /acquirer and /fund pages). - Returns found:false (an expected outcome, NOT an error) with honest notes when the entity is outside the tracked corpus — it never guesses an acquirer, investor, or signal. PARAMETERS: { company: string } — company or entity name (target, acquirer, or tracked startup), case-insensitive. RETURNS: { entity, found, acquiredBy[], acquisitionsMade[], backedBy[], signal|null, notes[] }, plus a citation array. Human mirror: /diligence. HTTP analog: GET /api/diligence.json?company={name}.

Return the full methodology behind VC Deal Flow Signal: how startup engineering activity is sourced from the public GitHub API, how commit velocity and contributor-growth metrics are computed, how signal types are classified ('breakout' | 'acceleration' | 'steady' | 'cooling'), the refresh cadence, and the known limitations. WHEN TO USE: - The user asks 'how is this calculated?', 'what does breakout mean?', 'can I trust this number?', or any trust / interpretability question. - You are writing a report, memo, or footnote and need a methodology section or citation. - Due-diligence / compliance wants to audit the data pipeline before citing it. - You need to explain why a specific signal was assigned (what triggers 'breakout' vs 'acceleration'). DO NOT USE FOR: - Fetching the startup data itself — use `get_trending_startups`, `search_startups_by_sector`, or `get_startup_signal`. - Getting the list of supported sectors or the refresh date — use `get_signals_summary` (it returns live counts and freshness). - Confirming whether a specific startup is tracked — use `get_startup_signal`. BEHAVIOR: - Read-only, idempotent, no side effects. - Effectively static: methodology text is versioned with the service and only changes when the computation changes (rare — quarterly at most). Safe to call once per session and reuse across turns. - No authentication required. - Fetches `/llms-full.txt` and extracts the `## Methodology` section between the `## Methodology` and `## Glossary` headings. The canonical methodology URL is included in the response so agents can surface it for citations. - On upstream failure: returns `isError: true` with HTTP status. - On malformed upstream text (missing headings): returns an empty `methodology` string; still surfaces the canonical URL so the user can click through. PARAMETERS: None. RETURNS: `{ methodology: string, url: string }`. `methodology` is plain text covering data sources, metric definitions, classification thresholds, refresh cade…

Compute a Scout Score (0-100) for a GitHub user from their public starring history. Cross-references the user's starred repos against a curated database of ~75 validated unicorns (Series A+, $1B+ valuations, acquisitions, 25K+ stars in last 5 years) and grades how many they starred *before* the validation event. WHEN TO USE: - The user wants to evaluate a developer's investment taste retroactively (e.g. 'how good is @sindresorhus at spotting unicorns?'). - Vetting a potential angel investor or scout based on their public OSS taste. - Comparing two developers' early-call track records. - Generating shareable proof-of-taste content for a developer profile. DO NOT USE FOR: - Fetching live trending startups — use `get_trending_startups`. - Forward-looking predictions on whether a startup will raise — call `predict_funding` (scored claim with full evidence chain and provenance). - Looking up a startup's signal score — use `get_startup_signal`. BEHAVIOR: - Read-only, idempotent within a 24h window. - Hits `/api/receipts/{username}` which fetches public starring data from GitHub then scores against the validated-wins database. - 24-hour CDN cache; same username re-queried within 24h is served from cache. - No authentication required from the MCP client. Server-side uses a fine-grained PAT for elevated GitHub rate limits. - On user not found: returns `isError: true` with HTTP 404. - On GitHub rate limit: returns `isError: true` with HTTP 503. PARAMETERS: `github_username` (required) — GitHub username, 1-39 chars, alphanumeric + hyphens. RETURNS: `{ username, score, rank ('curious'|'scout'|'sharp'|'elite'|'oracle'), total_stars, matched_count, early_count, top_wins[], personality, share_url, og_image_url }`. `top_wins` lists up to 8 entries with org, name, event, starred_at, months_early, weight, points. `personality` is a one-paragraph templated commentary on the user's taste pattern. TYPICAL WORKFLOW: User asks 'is @X a good scout?' → `get_scout_receipts({ github_us…

Return a high-level snapshot of the VC Deal Flow Signal dataset: current reporting period, number of active sectors, total startups tracked, last-refresh timestamp, update frequency, citation string, and direct URLs to every data format (JSON, CSV, RSS, OpenAPI, llms.txt, full context, AI policy). WHEN TO USE: - Starting a research session and you want to know what data exists and how fresh it is. - Verifying freshness ('is this data from this week?') before including the numbers in an investor memo. - The user asks 'what is this service?', 'how do I cite your data?', or 'where can I download the CSV?'. - You need a bulk-download URL (CSV) or a feed URL (RSS) to pipe into another tool. - You need to show the user the full list of supported sectors before calling `search_startups_by_sector`. DO NOT USE FOR: - Fetching the actual startup rows — use `get_trending_startups` or `search_startups_by_sector`. - Explaining HOW signals are computed — use `get_methodology`. - Looking up a single startup — use `get_startup_signal`. BEHAVIOR: - Read-only, idempotent, no side effects. - Deterministic within a 7-day window: dataset metadata refreshes every Monday ~09:00 UTC alongside the rest of the feed. - No authentication required. - Hits `/api/changelog.json` only — the lightest endpoint in the suite. Safe to call once at the start of every session. - On upstream failure: returns `isError: true` with HTTP status. PARAMETERS: None. RETURNS: `{ period, sectorsActive, startupsTracked, lastDataRefresh (ISO 8601), updateFrequency, formats: { json, csv, rss, openapi, llmsTxt, llmsFullTxt, aiPolicy }, website, dashboard, citation }`. TYPICAL WORKFLOW: `get_signals_summary` (orient, check freshness) → `get_trending_startups` or `search_startups_by_sector` (explore) → `get_startup_signal(name)` (deep-dive) → `get_methodology` (explain). LIMITATIONS: Current-period snapshot only — no historical period metadata. For reproducing past weeks, download the CSV at `formats.csv` and ar…

Return the full engineering-acceleration profile for a single tracked startup: commit velocity, velocity change, contributor count and growth, new-repo count, signal classification, sector, stage, geography, and GitHub URL. WHEN TO USE: - The user names a specific company: 'tell me about Roboflow', 'what's Supabase's signal?', 'is Modular trending?', 'lookup SkyPilot'. - Preparing a deal memo, one-pager, or investor update about a named startup. - Verifying whether a startup is in the tracked universe before writing analysis. DO NOT USE FOR: - Discovering unknown companies or fuzzy exploration ('any good AI startups?') — call `get_trending_startups` or `search_startups_by_sector` first, then drill in here. - Listing candidates in a sector — call `search_startups_by_sector`. - Explaining what the signalType means — call `get_methodology`. BEHAVIOR: - Read-only, idempotent, no side effects. - Deterministic within a 7-day window: dataset refreshes every Monday ~09:00 UTC. - No authentication required. - Matching is case-insensitive and normalization-tolerant: whitespace, punctuation, and capitalization are stripped before comparison. 'Sky Pilot', 'skypilot', and 'SkyPilot' all resolve to the same entry. Accepts either the display name or the GitHub org slug. - On no match: returns `structuredContent: { found: false, suggestion: ... }`. This is an EXPECTED outcome (the startup is not in the tracked universe), NOT an error — do not retry, do not flag as failure. Instead surface the suggestion to the user and offer to run `get_trending_startups` or `search_startups_by_sector`. - On upstream failure: returns `isError: true` with HTTP status. - Open-world: only 350+ companies are tracked. This tool cannot add new ones — direct the user to the website submission form if needed. PARAMETERS: - `name` (required, string, 1–100 chars) — Startup display name OR GitHub org name. Case-insensitive; punctuation and whitespace are ignored during matching. RETURNS: `{ found: boole…

Return the top 20 startups ranked by engineering acceleration across all 15 sectors for the current reporting period. Each row includes commit velocity, contributor count, signal classification, and GitHub URL. WHEN TO USE: - A VC, scout, or analyst asks 'who's trending this week', 'what's hot right now', 'who should I look at', or 'what to watch'. - You need a fresh cross-sector shortlist for a deal-flow meeting or weekly watchlist. - You want to surface breakout companies before they appear in Crunchbase / PitchBook / press. DO NOT USE FOR: - Narrowing to one vertical — call `search_startups_by_sector` instead. - Looking up a named company — call `get_startup_signal` with the company name. - Explaining the ranking methodology — call `get_methodology`. - Discovering what sectors exist or how fresh the data is — call `get_signals_summary`. BEHAVIOR: - Read-only, idempotent, no side effects. Safe to call repeatedly. - Deterministic within a 7-day window: the dataset refreshes every Monday ~09:00 UTC, so identical calls within the same week return identical results. - No authentication required. No rate limit enforced by this server; the upstream CDN absorbs typical agent traffic. - Returns exactly 20 rows when the dataset is healthy; fewer only if the upstream feed is degraded. - On upstream failure: returns `isError: true` with the HTTP status in the text block — retry once after a short delay before escalating to the user. - Open-world: the tracked universe (350+ companies) evolves week to week as new orgs qualify or drop out. PARAMETERS: None. RETURNS: `{ period, startups[20], citation, source }`. Each startup row contains rank, name, sector, stage, geography, commitVelocity14d, commitVelocityChange, contributors, contributorGrowth, newRepos, signalType ('breakout' | 'acceleration' | 'steady' | 'cooling'), description, githubUrl, websiteUrl (when known, ~90% coverage), linkedinUrl (when known, partial coverage), profileUrl. TYPICAL WORKFLOW: `get_trending_s…

Return a TRANSPARENT, scored funding-likelihood claim for a single tracked startup, with the full evidence chain and citable provenance. This is the agentic counterpart to the browser-only /predict page: instead of an opaque number, it hands back the score, every component that produced it, a confidence level, honest caveats, and links to the methodology + SSRN paper so a downstream agent can cite the derivation. WHAT IT IS (and is NOT): - IS: a deterministic heuristic over public GitHub engineering-acceleration signals (commit velocity, contributor growth, new-repo creation, signal class). Same company → same score within a weekly period. - IS NOT: an ML black box, a guarantee of any financing event, or anything derived from private/cap-table/revenue data. The disclaimer is returned in every response — surface it. WHEN TO USE: - 'Is X likely to raise soon?', 'how strong is X's momentum?', 'should we reach out to X before they raise?' - Drafting a memo where you need a defensible, citable signal read rather than a gut call. DO NOT USE FOR: - Discovering candidates — use `shortlist_signals` or `get_trending_startups`. - A plain data row with no scoring — use `get_startup_signal`. BEHAVIOR: - Read-only, idempotent, no auth. Deterministic within the weekly period (refreshes Mondays ~09:00 UTC). - On no match: returns `{ found: false, suggestion }` — an EXPECTED outcome, not an error. SCORING (auditable — also returned in evidence.scoreBreakdown): - velocity: up to 40 pts, saturating at +300% commit-velocity change. - contributorGrowth: up to 25 pts, saturating at +200% (absolute contributor count is capped in the feed, so growth-rate is what matters). - newRepos: up to 15 pts, saturating at 10 new public repos in 30d. - signalType: up to 20 pts (Deploy frequency spike 20, Engineering hiring burst 17, Infrastructure buildout 14, Framework migration 8). - total 0-100 → raiseLikelihood band: >=70 high, 45-69 elevated, 25-44 moderate, <25 low. PARAMETERS: { name: st…

PAID AGENT TOOL — €0.10 per call. Returns an enriched dossier for a single tracked startup: full signal row, sector rank, top-5 peers in the same sector, period label, and citation. WHEN TO USE: VC, scout, or analyst wants more than a one-row signal — they want the company in context (rank, peers, trajectory) for a 1-pager or memo prep. DO NOT USE FOR: simple lookup of one row (free `get_startup_signal` is enough), browsing a sector (use `search_startups_by_sector` free), or composing an investment thesis (use `compose_thesis`). AUTH: Requires `GITDEALFLOW_API_KEY` in the MCP server env. Without it, the tool returns a polite hint pointing to /pricing. PARAMETERS: { name: string } — company display name or GitHub org (case-insensitive). RETURNS: { startup, sectorRank: { rank, of }, peers[5], period, citation, _meter }. The `_meter` block reports the tier (`payg` | `insider`), remaining balance for PAYG, calls-today for Insider.

Return every tracked startup within one of 15 supported sectors, ranked by engineering acceleration for the current reporting period. WHEN TO USE: - The user names a specific vertical: 'show me healthcare startups', 'who's moving in web3?', 'data-infrastructure deal flow', 'space-tech picks'. - You need a focused list for a thesis-driven investor or a sector report. - You're comparing momentum inside a defined market before a sourcing cycle. DO NOT USE FOR: - Cross-sector discovery — call `get_trending_startups` for the top-20 across all sectors. - Looking up a named company — call `get_startup_signal(name)`. - Discovering which sectors exist or how many startups are tracked overall — call `get_signals_summary` (it returns live counts and URLs). - Multi-sector filtering — the tool accepts exactly one slug per call; issue parallel calls if you need several. BEHAVIOR: - Read-only, idempotent, no side effects. - Deterministic within a 7-day window: dataset refreshes every Monday ~09:00 UTC. - No authentication required. No rate limit enforced by this server. - Returns between 5 and 30 startups per sector depending on open-source density. Dense: data-infrastructure, enterprise-saas, healthcare. Sparse: legal-tech, proptech, agtech. - On unknown sector slug: returns `isError: true` with the full list of valid slugs in `structuredContent.availableSectors` so the agent can retry with a correct value. - On upstream failure: returns `isError: true` with the HTTP status. - Open-world: the tracked universe changes week to week. PARAMETERS: - `sector` (required, string) — MUST be one of the 15 enumerated slugs in `inputSchema.properties.sector.enum`. Map fuzzy user input BEFORE calling: 'crypto' / 'blockchain' → 'web3'; 'SaaS' → 'enterprise-saas'; 'biotech' / 'health' / 'medtech' → 'healthcare'; 'data' / 'databases' → 'data-infrastructure'; 'real estate' → 'proptech'; 'agriculture' → 'agtech'; 'space' → 'space-tech'; 'games' → 'gaming'; 'community' / 'social' → 'social-com…

Return a ranked shortlist of the strongest engineering-acceleration signals matching a set of filters — the entire sourcing workflow in ONE call. Replaces the 'browse a sector, read each row, eyeball the strongest' loop: 'give me the 5 strongest signals in observability HQ'd in the US', 'top web3 breakouts in the EU', 'who's accelerating hardest in data-infrastructure right now'. WHEN TO USE: - Any 'top N in <sector> / <region> / <signal type>' sourcing request. - Building a corp-dev or scout watchlist filtered by thesis. - You want results already ranked by a defensible acceleration score, each with a one-line rationale and the evidence behind it. DO NOT USE FOR: - A single named company — use `get_startup_signal` or `predict_funding`. - Comparing 2-5 specific companies head-to-head — use `compare_signals`. BEHAVIOR: - Read-only, idempotent, no auth. Deterministic within the weekly period. - Scans the full tracked universe (~140 rows), scores each with the transparent engine (same scoring as predict_funding), applies filters, sorts by accelerationScore desc, returns the top `limit`. - GEOGRAPHY IS REGION-LEVEL ONLY. The feed has no city granularity — values are US / EU / UK / APAC / LATAM / Canada / Unknown. City or country aliases (e.g. 'NYC', 'New York', 'Berlin', 'London', 'Singapore') are normalized up to the enclosing region and the response `notes` says so. There is no way to filter to a city. PARAMETERS (all optional — omit to scan the whole universe): - `sector` — one of the 15 sector slugs (map fuzzy input first, e.g. 'crypto'→'web3', 'health'→'healthcare'). - `geography` — a region token (US/EU/UK/APAC/LATAM/Canada) or a city/country alias that normalizes to one. Unrecognized values return a note and are ignored (no filtering on geography). - `signalType` — exact label: 'Deploy frequency spike' | 'Engineering hiring burst' | 'Infrastructure buildout' | 'Framework migration'. - `minAccelerationScore` — integer 0-100; drop anything below. - `minVelocit…