# GitDealFlow — GitHub signals for startup investors (npm · @gitdealflow/mcp-signal)

GitHub signals for VC deal flow: trending startups, commit velocity, contributor growth, 20 sectors.

- Trust score: 65/100 (medium)
- Change this week: +16
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- npm · `@gitdealflow/mcp-signal`: 65/100 (this document), [markdown](https://verifymcp.io/servers/kindrat86-vc-deal-flow-signal/gitdealflow-mcp-signal.md), [page](https://verifymcp.io/servers/kindrat86-vc-deal-flow-signal/gitdealflow-mcp-signal)

## Channel facts

- Registry: `npm`
- Package: `@gitdealflow/mcp-signal`
- Version: `2.2.0`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Supply Chain Security**: 86/100
  - No malware found by supply-chain analysis.
  - Only part of the dependency tree could be resolved (94 of 98), so this covers what we could see, not the whole tree.
  - No install/post-install scripts declared.
  - Only part of the dependency tree could be resolved (94 of 98), so this covers what we could see, not the whole tree.
- **Provenance & Transparency**: 45/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 64 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 74/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 6713 tokens (~419/item across 16 items; 13 tools + 3 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 0/100
  - Stability not yet verified: not enough scan history yet (needs a 30-day window).
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

**Unverified: 1 category.** A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

## Install

### Claude

```bash
claude mcp add kindrat86-vc-deal-flow-signal -- npx -y @gitdealflow/mcp-signal
```

### Codex

```bash
codex mcp add kindrat86-vc-deal-flow-signal -- npx -y @gitdealflow/mcp-signal
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "kindrat86-vc-deal-flow-signal": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@gitdealflow/mcp-signal"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add kindrat86-vc-deal-flow-signal --command npx --arg -y --arg @gitdealflow/mcp-signal
```

### Hermes

```yaml
mcp_servers:
  kindrat86-vc-deal-flow-signal:
    command: "npx"
    args: ["-y", "@gitdealflow/mcp-signal"]
```

### Other

```json
{
  "mcpServers": {
    "kindrat86-vc-deal-flow-signal": {
      "command": "npx",
      "args": [
        "-y",
        "@gitdealflow/mcp-signal"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-02 (score 65, +27)

- [security regression] Provenance: unverified → fail
- [security improvement] Install scripts: unverified → pass
- [security improvement] Known CVEs: unverified → partial
- [security] Stability: Stability not yet verified: not enough scan history yet (needs a 30-day window).
- [functional improvement] Schema quality: unverified → excellent
- [functional improvement] License: unverified → pass
- [functional improvement] Dependency health: unverified → partial
- [functional improvement] Maintenance: unverified → pass
- [functional improvement] MCP protocol: unverified → pass
- [functional] Licence: MIT

### 2026-08-01 (score 38, +15)

- [security improvement] Malware scan: unverified → pass

### 2026-07-31 (score 23, −8)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 31, −18)

- [security regression] Malware scan: pass → unverified

### 2026-07-27 (score 49)

First indexed and scored.

## MCP tools (13)

### `get_trending_startups` (~547 tokens)

Get Trending Startups

Return the top 20 startups ranked by engineering acceleration across all 20 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 (~400 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…

Output parameters:

- `citation` (string): Suggested citation string for reports.
- `period` (string): Reporting period label, e.g. 'Q2 2026'.
- `source` (string)
- `startups` (array): Top 20 startups ranked by engineering acceleration.

### `search_startups_by_sector` (~901 tokens)

Search Startups by Sector

Return every tracked startup within one of 20 supported sectors, ranked by engineering acceleration for the current reporting period.

WHEN TO USE:
\- The user names a specific vertical: 'show me AI/ML startups', 'who's moving in fintech?', 'cybersecurity deal flow', 'climate-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: ai-ml, developer-tools, data-infrastructure. 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 20 enumerated slugs in `inputSchema.properties.sector.enum`. Map fuzzy user input BEFORE calling: 'AI' / 'artificial intelligence' / 'ML' → 'ai-ml'; 'crypto' / 'blockchain' → 'web3'; 'cyber' / 'infosec' / 'security' → 'cybersecurity'; 'SaaS' → 'enterprise-saas'; 'devtools' / 'developer experience' → 'developer-tools'; 'climate' / 'clean energy' / 'cleantech' → 'climate-tech'; 'biotech' / 'health'…

Input parameters:

- `sector` (string, required): Sector slug. Must be one of the 20 supported values. Map fuzzy user input to the closest slug (e.g. 'AI' → 'ai-ml', 'crypto' → 'web3', 'cyber' → 'cybersecurity', 'SaaS' → 'enterprise-saas').

Output parameters:

- `citation` (string)
- `period` (string)
- `sector` (object)
- `startupCount` (integer)
- `startups` (array): Startups within the sector, ranked by engineering acceleration.

### `get_startup_signal` (~671 tokens)

Get Startup Signal Profile

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 ~400 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…

Input parameters:

- `name` (string, required): Startup name or GitHub org name. Case-insensitive; punctuation and whitespace are ignored during matching.

Output parameters:

- `citation` (string)
- `found` (boolean)
- `startup` (object): A single startup ranked by engineering acceleration, as derived from public GitHub activity.
- `suggestion` (string): When found=false, a hint on how to discover the correct name or alternative tools to call.

### `get_signals_summary` (~501 tokens)

Get Dataset Summary

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…

Output parameters:

- `citation` (string)
- `dashboard` (string)
- `formats` (object)
- `lastDataRefresh` (string): ISO 8601 date.
- `period` (string)
- `sectorsActive` (integer)
- `startupsTracked` (integer)
- `updateFrequency` (string)
- `website` (string)

### `get_scout_receipts` (~631 tokens)

Get GitHub Scout Receipts

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…

Input parameters:

- `github_username` (string, required): GitHub username to compute Receipts for. Must match the public GitHub username format: 1-39 chars, alphanumeric + single hyphens, no leading/trailing hyphen.

Output parameters:

- `early_count` (integer)
- `matched_count` (integer)
- `og_image_url` (string)
- `personality` (string)
- `rank` (string)
- `score` (integer)
- `share_url` (string)
- `top_wins` (array)
- `total_stars` (integer)
- `username` (string)

### `get_methodology` (~567 tokens)

Get Signal Methodology

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…

Output parameters:

- `methodology` (string): Plain-text methodology write-up.
- `url` (string): Canonical methodology page on gitdealflow.com.

### `get_diligence_dossier` (~355 tokens)

Company Diligence Dossier

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}.

Input parameters:

- `company` (string, required): Company or entity name (target, acquirer, or tracked startup). Case-insensitive. Examples: 'Figma', 'Supabase', 'Broadcom', 'Auth0'.

Output parameters:

- `acquiredBy` (array): Public acquisitions where this entity was the target.
- `acquisitionsMade` (array): If the entity is an acquirer: companies it has publicly bought.
- `backedBy` (array): Funds in the tracked corpus that publicly disclosed backing it.
- `entity` (string): Resolved canonical entity name.
- `found` (boolean): True when at least one grounded fact exists; false is expected, not an error.
- `notes` (array): Plain-language notes on what is and isn't known.
- `signal` (object|null): Published engineering-acceleration signal, when tracked.

### `research_company` (~265 tokens)

Research Company (paid)

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.

Input parameters:

- `name` (string, required): Startup display name or GitHub org slug.

Output parameters:

- `_meter` (object): Billing meter. `tier` is 'payg' or 'insider'.
- `citation` (string)
- `peers` (array)
- `period` (string)
- `sectorRank` (object)
- `startup` (object): A single startup ranked by engineering acceleration, as derived from public GitHub activity.

### `compose_thesis` (~199 tokens)

Compose Investment Thesis (paid)

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 }.

Input parameters:

- `name` (string, required): Startup display name or GitHub org slug.

Output parameters:

- `_meter` (object): Billing meter. `tier` is 'payg' or 'insider'.
- `citation` (string)
- `company` (string)
- `peers` (array)
- `period` (string)
- `sector` (string)
- `sectorRank` (object)
- `signalType` (string)
- `snapshot` (object)
- `strengths` (array)

### `deep_dive_scan` (~289 tokens)

Deep-Dive Sector Scan (paid)

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 20 supported sector slugs.

RETURNS: { sector, period, summary: { total, breakouts, cold }, breakouts[≤10], cold[≤5], top10ByCommitVelocity[10], citation, _meter }.

Input parameters:

- `sector` (string, required): Sector slug. One of: ai-ml, fintech, cybersecurity, developer-tools, healthcare, climate-tech, enterprise-saas, data-infrastructure, web3, robotics, edtech, ecommerce-infrastructure, supply-chain, le…

Output parameters:

- `_meter` (object): Billing meter. `tier` is 'payg' or 'insider'.
- `breakouts` (array)
- `citation` (string)
- `cold` (array)
- `period` (string)
- `sector` (string)
- `summary` (object)
- `top10ByCommitVelocity` (array)

### `predict_funding` (~613 tokens)

Predict Funding Likelihood (with provenance)

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…

Input parameters:

- `name` (string, required): Startup display name or GitHub org slug. Case-insensitive; punctuation and whitespace are ignored during matching.

Output parameters:

- `caveats` (array)
- `company` (object)
- `disclaimer` (string)
- `evidence` (object): The evidence chain — every input that produced the score.
- `found` (boolean)
- `prediction` (object)
- `provenance` (object)
- `suggestion` (string)

### `shortlist_signals` (~741 tokens)

Shortlist Strongest Signals

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 fintech breakouts in the EU', 'who's accelerating hardest in AI 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 20 sector slugs (map fuzzy input first, e.g. 'AI'→'ai-ml').
\- `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.
\- `minVelocityChangePct` — integer; drop anything who…

Input parameters:

- `geography` (string): Optional region filter. Region tokens: US, EU, UK, APAC, LATAM, Canada. City/country aliases are normalized up to the region (no city-level filtering exists).
- `limit` (integer): How many results to return. Default 5, max 25.
- `minAccelerationScore` (integer): Optional floor on the 0-100 acceleration score.
- `minVelocityChangePct` (integer): Optional floor on commit-velocity change, in percent (e.g. 50 means >= +50%).
- `sector` (string): Optional sector slug. One of the 20 supported values.
- `signalType` (string): Optional exact signal-class filter.

Output parameters:

- `citation` (string)
- `consideredCount` (integer)
- `disclaimer` (string)
- `matchedCount` (integer)
- `methodologyUrl` (string)
- `notes` (array)
- `period` (string)
- `query` (object)
- `results` (array)
- `source` (string)

### `compare_signals` (~324 tokens)

Compare Signals Head-to-Head

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 }.

Input parameters:

- `names` (array, required): 2-5 startup display names or GitHub org slugs.

Output parameters:

- `citation` (string)
- `compared` (array)
- `disclaimer` (string)
- `methodologyUrl` (string)
- `notFound` (array)
- `period` (string)
- `recommendation` (string)
- `source` (string)

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/kindrat86-vc-deal-flow-signal/gitdealflow-mcp-signal#diagnostics

## Score history

- 2026-08-03: 65
- 2026-08-02: 65
- 2026-08-01: 38
- 2026-07-31: 23
- 2026-07-30: 31
- 2026-07-28: 49
- 2026-07-27: 49

## Links

- npm package: https://www.npmjs.com/package/@gitdealflow/mcp-signal
- Socket report: https://socket.dev/npm/package/@gitdealflow/mcp-signal
- Repository: https://github.com/kindrat86/mcp-deal-flow-signal
- Website: https://gitdealflow.com/
- Changelog RSS feed: https://verifymcp.io/servers/kindrat86-vc-deal-flow-signal/gitdealflow-mcp-signal/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/kindrat86-vc-deal-flow-signal/gitdealflow-mcp-signal/changelog.json
- HTML version of this page: https://verifymcp.io/servers/kindrat86-vc-deal-flow-signal/gitdealflow-mcp-signal