Skip to main content
Glama
deenesjakoruzh
kindrat86

mcp-deal-flow-signal

by kindrat86
OverviewSchemaSourceRelated ServersDiscussions(2)Admin
JavaScript
Remote

VC Deal Flow Signal — MCP Server

Search startup engineering acceleration signals directly from your AI assistant.

Glama A-Tier

Glama A-Tier (4.9 / 5.0). 13 tools — 10 free, no API key. One-line install for Claude Desktop, Claude Code, Cursor, Cline, and Continue via npx -y @gitdealflow/mcp-signal.

Claude querying VC Deal Flow Signal MCP server

Tracks commit velocity, contributor growth, and repository expansion across 15 sectors and 350+ startups. Built for angels, scouts, and technical operators looking for traction signals before they show up in traditional deal flow.

Install

Add to your Claude Desktop config (claude_desktop_config.json):

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

Or for Claude Code (.mcp.json in project root):

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

Related MCP server: Git Metrics MCP Server

Tools

All tools are read-only, idempotent, and fetch live data from the public API (no auth required). Responses include both human-readable text and structured JSON (structuredContent) matching each tool's outputSchema.

Free tools (10) — no API key, no account:

Tool

Input

Returns

get_trending_startups

—

Top 20 startups ranked by engineering acceleration across all sectors.

search_startups_by_sector

sector (enum of 15 slugs)

All tracked startups in the sector, ranked by acceleration.

get_startup_signal

name (case-insensitive)

Full signal profile for one startup: velocity, contributors, repos, classification.

get_signals_summary

—

Dataset snapshot — period, counts, refresh date, format URLs, citation.

get_methodology

—

How signals are sourced, computed, and classified, with known limitations.

shortlist_signals

filters (sector, stage, geography, signal type)

Ranked shortlist of the strongest engineering-acceleration signals matching your filters.

compare_signals

2–5 startup names

Side-by-side acceleration scores, evidence, and raise-likelihood for the named startups.

predict_funding

name

Transparent, scored funding-likelihood claim with the full evidence chain, citable.

get_diligence_dossier

company/entity name

Public-source diligence dossier in one cited object — M&A history, funding, key facts.

get_scout_receipts

GitHub username

Scout Score (0–100) computed from public starring history, cross-referenced against tracked startups.

Paid agent tools (3) — €0.10 per call, credits at signals.gitdealflow.com/agents/credits:

Tool

Returns

research_company

Enriched dossier for one tracked startup: full signal row, sector rank, top-5 sector peers, citation.

compose_thesis

Structured investment thesis: snapshot, signal type, sector rank, data-derived strengths, peer comparables.

deep_dive_scan

Multi-cohort sector scan: tracked/breakout/cooling counts, top-10 by velocity, breakout and cold lists.

The hosted remote endpoint (https://signals.gitdealflow.com/api/mcp/rpc, streamable-http) additionally exposes share_result (free) and get_deep_signal (€0.19/call).

Supported sectors: healthcare, edtech, ecommerce-infrastructure, supply-chain, web3, enterprise-saas, data-infrastructure, robotics, legal-tech, hr-tech, proptech, agtech, gaming, space-tech, social-community.

Data

All data is sourced live from the deal flow data API public API. No API key required. Updated weekly on Mondays.

Complementary: the Scout Game

If you want to put your own eye on the line, there's a prediction game on top of the same dataset at signals.gitdealflow.com/predict. Call which tracked startups raise a round in the next 6 months, earn points when your calls resolve, climb a public rank ladder from Curious to Oracle. Free tier: 3 predictions per month. Paid: 10 per month. Leaderboard: signals.gitdealflow.com/leaderboard.

Complementary: two Chrome extensions

Same dataset, different surfaces. Install one or both:

  • VC Deal Flow Signal — Crunchbase + Wellfound badge: a green "Accelerating" engineering-acceleration badge appears inline on any Crunchbase or Wellfound startup profile where the GitHub data is interesting. For investors who research deals in browser tabs.

  • VC GitHub Lookup — Startup Signals on Hover (NEW, May 2026): hover any GitHub repo or org link to see commit velocity (14d), velocity change vs prior period, contributor count and growth, signal type, and stage estimate. Chip injected on direct repo and org page loads. Toolbar opens a manual lookup form for any GitHub URL. For developer-investors who live on GitHub.

Both are free in perpetuity. Manifest V3, no analytics, no account.

Links

License

MIT

Available Tools

8 tools
get_deep_signalGet Deep Signal (paid)A
Read-onlyIdempotent

PAID per-request tool — costs 1 credit per match. Returns a deeply enriched signal profile for a single tracked startup, beyond what the free get_startup_signal returns: scored breakdown (velocity / growth / novelty / composite), in-sector rank and percentile, comparable startups, multi-period history, and a plain-English investment thesis.

PRICING:

AUTHENTICATION:

  • Set environment variable GITDEALFLOW_API_KEY to the v2 key delivered in the credit-pack welcome email (format: gdf_v2.cus_xxx.<hmac>). The server reads it once on each call.

  • Without a key, this tool returns an error pointing at the purchase URL — the other 6 free tools are unaffected.

WHEN TO USE (vs free get_startup_signal):

  • You already know the startup name and need scored / percentile / comparables / thesis output for a memo.

  • The agent's principal will read or quote the thesis line.

  • You're processing a watchlist programmatically and need a numeric composite score for ranking.

DO NOT USE FOR:

  • Discovery — call free get_trending_startups or search_startups_by_sector first.

  • Bulk scoring an unknown universe — that's not yet shipped; submit feedback via signal@gitdealflow.com.

  • Methodology questions — call free get_methodology.

PARAMETERS: name (required, string, 1-100 chars) — Startup display name OR GitHub org name. Case-insensitive matching, same as the free lookup.

RETURNS: { found: boolean, name, sector, stage, geography, signalType, scores: { velocity, growth, novelty, composite }, rank: { inSector, sectorTotal, sectorPercentile }, thesis, comparables[], history[], links, balance, charged, citation }. balance is the remaining credit count after this call. charged is 0 (miss) or 1 (hit).

ERRORS: 401 = invalid/missing key; 402 = insufficient credits (top up at the purchase URL); 400 = malformed request.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesStartup name or GitHub org name. Case-insensitive; punctuation and whitespace are ignored.

Output Schema

ParametersJSON Schema
NameRequiredDescription
foundYes
nameNo
sectorNo
stageNo
geographyNo
signalTypeNo
scoresNo
rankNo
thesisNo
comparablesNo
balanceNo
chargedNo
citationNo

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnlyHint, idempotentHint), the description adds critical behavioral details: per-request pricing, credit consumption only on success, authentication via env variable, error responses (401, 402, 400), and the inclusion of balance and charged in returns. No contradictions with annotations.

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 well-structured with clear section headings (PRICING, AUTHENTICATION, WHEN TO USE, etc.) and front-loaded with purpose and pricing. Every sentence provides valuable information with no redundancy.

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?

Given the tool's complexity (paid, authentication, rich output), the description comprehensively covers pricing, auth, usage guidelines, parameter details, return fields, and error handling. The existence of an output schema reduces the burden, but the description still adds context.

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 coverage is 100% with a single 'name' parameter fully documented. The description adds minimal extra value (case-insensitivity hint, reference to free lookup). Baseline 3 is appropriate.

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 clearly states the tool returns a deeply enriched signal profile for a single tracked startup, explicitly listing components like scored breakdown, in-sector rank, comparables, history, and thesis. It distinguishes itself from the free sibling get_startup_signal.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit WHEN TO USE and DO NOT USE sections, including specific scenarios (memo preparation, programmatic ranking) and alternatives for discovery, bulk scoring, and methodology. This offers excellent guidance for selecting this tool over siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_methodologyGet Signal MethodologyA
Read-onlyIdempotent

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 cadence, and known limitations. url is the canonical methodology page at https://signals.gitdealflow.com/methodology — cite this URL in generated reports.

TYPICAL WORKFLOW: User asks a trust / interpretability question → get_methodology → quote the relevant section in your response and link the canonical URL.

LIMITATIONS: Returns one monolithic text block; no structured thresholds or versioning metadata are exposed via the tool. If you need the full service context (not just methodology), fetch /llms-full.txt directly via the URL returned in get_signals_summary().formats.llmsFullTxt.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
methodologyYesPlain-text methodology write-up.
urlYesCanonical methodology page on gitdealflow.com.

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds extra behavioral details: 'Read-only, idempotent, no side effects', notes it is effectively static and safe to cache, explains error handling ('returns isError: true') and malformed response handling. No contradiction.

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 is well-structured with clear section headers (WHEN TO USE, DO NOT USE, BEHAVIOR, etc.) and front-loaded with purpose. While it is thorough, it remains efficient and each sentence adds value. Could slightly reduce length but overall good.

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?

Given no parameters, a readable output schema, and moderate complexity, the description covers all necessary aspects: usage context, behavior, return structure, typical workflow, and limitations. It provides complete guidance for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters (0 params, 100% schema coverage). The description does not need to add parameter info. It goes beyond by explaining the return structure ({ methodology: string, url: string }) and provides context about the return values. Baseline for 0 params is 4.

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 starts with 'Return the full methodology behind VC Deal Flow Signal' which clearly specifies the verb and resource. It lists exactly what the methodology covers (data sources, metrics, classification, etc.) and distinguishes from sibling tools like get_startup_signal, get_trending_startups, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description has explicit 'WHEN TO USE' and 'DO NOT USE FOR' sections with multiple bullet points, naming specific alternative tools for each forbidden case. This provides clear context and exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_scout_receiptsGet GitHub Scout ReceiptsA
Read-onlyIdempotent

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 — direct the user to https://signals.gitdealflow.com/predict (browser-only, not yet a tool).

  • 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_username: 'X' }) → quote the score, top wins, and personality, link the share_url for them to post.

LIMITATIONS: The validated-wins database is biased toward developer-tools, AI, and data/ops companies with public GitHub presence. Closed-source unicorns are not represented — false negatives possible. Score reflects backwards-looking taste only; not a predictor of future calls.

ParametersJSON Schema
NameRequiredDescriptionDefault
github_usernameYesGitHub username to compute Receipts for. Must match the public GitHub username format: 1-39 chars, alphanumeric + single hyphens, no leading/trailing hyphen.

Output Schema

ParametersJSON Schema
NameRequiredDescription
usernameYes
scoreYes
rankYes
total_starsNo
matched_countYes
early_countYes
top_winsYes
personalityNo
share_urlYes
og_image_urlNo

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnlyHint, idempotentHint), the description adds details: 24h cache, no client auth needed, error conditions, database bias, and returns structure.

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?

Well-structured with sections, front-loaded with core function. Slightly verbose but all information is relevant and organized.

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?

Includes limitations, return values, typical workflow, and error handling. Output schema is described comprehensively.

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?

Single parameter with 100% schema coverage; description includes typical workflow but adds little beyond schema details like format constraints.

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 clearly states the tool computes a Scout Score from public starring history, cross-referencing against validated unicorns. It distinguishes from sibling tools like get_trending_startups and get_startup_signal.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit 'WHEN TO USE' and 'DO NOT USE FOR' sections, listing specific use cases and alternative tools for different needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_signals_summaryGet Dataset SummaryA
Read-onlyIdempotent

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 archive it yourself (it's overwritten each Monday).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
periodYes
sectorsActiveYes
startupsTrackedYes
lastDataRefreshYesISO 8601 date.
updateFrequencyNo
formatsYes
websiteNo
dashboardNo
citationYes

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnlyHint, idempotentHint), the description adds behavioral details: deterministic within 7-day window, no auth, lightest endpoint, failure behavior. No contradiction with annotations.

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 well-structured with clear sections, front-loaded key info, and no fluff. Every sentence adds value for an AI agent.

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?

Given no parameters, rich annotations, and an output schema, the description still provides full coverage: return fields, usage timing, limitations, and typical workflow. It is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100%. The description correctly omits parameter details and instead explains the return structure and limitations, which is appropriate.

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 uses specific verbs and resources ('Return a high-level snapshot of the VC Deal Flow Signal dataset...') and lists concrete data points. It distinguishes from siblings by naming alternative tools for different tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'WHEN TO USE' and 'DO NOT USE FOR' sections provide explicit context and exclusions, directly referencing sibling tools with clear rationale.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_startup_signalGet Startup Signal ProfileA
Read-onlyIdempotent

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: boolean, startup?: {...}, suggestion?: string, citation }. When found=true, startup contains rank, name, sector, stage, geography, commitVelocity14d, commitVelocityChange, contributors, contributorGrowth, newRepos, signalType, description, githubUrl, profileUrl. When found=false, suggestion explains how to discover the correct name.

TYPICAL WORKFLOW: get_trending_startups or search_startups_by_sector (discover) → pick a name → get_startup_signal(name) (deep-dive) → get_methodology (explain signal classification in the response).

LIMITATIONS: Only returns data for currently-tracked startups. No historical series — each call is the latest weekly snapshot only. No relationship data (investors, cap table, team) — pair with Crunchbase for those facets.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesStartup name or GitHub org name. Case-insensitive; punctuation and whitespace are ignored during matching.

Output Schema

ParametersJSON Schema
NameRequiredDescription
foundYes
startupNoA single startup ranked by engineering acceleration, as derived from public GitHub activity.
suggestionNoWhen found=false, a hint on how to discover the correct name or alternative tools to call.
citationNo

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses read-only, idempotent, deterministic nature; no-auth requirement; case-insensitive and normalization-tolerant matching; no-match behavior (found:false, not error); open-world limitation (only ~400 companies). Annotations already provide readOnlyHint, idempotentHint, openWorldHint, but description adds crucial context (7-day refresh cycle, no historical series, expected non-error for unmatched names). No contradiction.

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?

Well-structured with clear sections (WHEN TO USE, DO NOT USE, BEHAVIOR, PARAMETERS, RETURNS, TYPICAL WORKFLOW, LIMITATIONS). Information is front-loaded with return fields. Slightly verbose but each sentence contributes. Could condense some behavioral details but still efficient.

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?

Comprehensive for a single-parameter tool with output schema described in RETURNS. Includes typical workflow linking to sibling tools, limitations (no historical data, no relationship info), and explicitly explains error handling (no-match vs. upstream failure). Output schema is described inline, so no missing pieces.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers the single parameter 'name' with description and examples. Description adds meaning: explains case-insensitivity, normalization (punctuation/whitespace stripping), and that it accepts either display name or GitHub org slug. Length constraints (1–100) are mentioned in description but not in schema. Overall adds value beyond schema.

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?

Clearly states it returns a full engineering-acceleration profile for a single tracked startup, listing specific fields. Distinguishes from sibling tools by focusing on individual startup deep-dive vs. discovery or methodology.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit WHEN TO USE (named company queries, deal memos) and DO NOT USE sections (discovery, sector listing, method explanation), with direct references to alternative tools (get_trending_startups, search_startups_by_sector, get_methodology).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_startups_by_sectorSearch Startups by SectorA
Read-onlyIdempotent

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' / 'medtech' → 'healthcare'; 'data' / 'databases' → 'data-infrastructure'; 'real estate' → 'proptech'; 'agriculture' → 'agtech'; 'space' → 'space-tech'; 'games' → 'gaming'; 'community' / 'social' → 'social-community'; 'logistics' → 'supply-chain'; 'law' / 'legal' → 'legal-tech'; 'recruiting' / 'HR' → 'hr-tech'; 'learning' / 'education' → 'edtech'; 'commerce' / 'retail infra' → 'ecommerce-infrastructure'; 'hardware' / 'drones' → 'robotics'. If no mapping is clear, call get_signals_summary and ask the user to pick.

RETURNS: { sector: {slug, name, description, url}, period, startupCount, startups[], citation }. Each startup row contains rank, name, sector, stage, geography, commitVelocity14d, commitVelocityChange, contributors, contributorGrowth, newRepos, signalType, description, githubUrl, websiteUrl (when known), linkedinUrl (when known), profileUrl.

TYPICAL WORKFLOW: search_startups_by_sector('fintech') → pick a name → get_startup_signal(name) → get_methodology if the user asks what the signal type means.

LIMITATIONS: One sector slug per call; no free-text sector search. For cross-sector views use get_trending_startups. No historical series — each call is the latest weekly snapshot only.

ParametersJSON Schema
NameRequiredDescriptionDefault
sectorYesSector 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 Schema

ParametersJSON Schema
NameRequiredDescription
sectorYes
periodYes
startupCountYes
startupsYesStartups within the sector, ranked by engineering acceleration.
citationYes

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (readOnlyHint, idempotentHint), the description adds critical behavioral details: deterministic within a 7-day window, no auth required, no rate limit, return count range (5-30), error handling for unknown and upstream failures, and open-world dynamic updates. No contradiction with annotations.

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 is lengthy but well-structured with clear sections and front-loaded purpose. Each section serves a purpose; no redundant fluff. Slightly verbose but appropriate for the complexity of the tool; scores a 4 rather than 5 due to minor redundancy (e.g., repeating 'one slug per call' in multiple places).

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?

Given the single parameter with full schema coverage, strong annotations, and implied output schema, the description covers all necessary aspects: purpose, usage, behavior, parameter semantics, error handling, limitations, and typical workflow. It leaves no gaps for an AI agent to misunderstand the tool's capabilities.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and includes description and enum. The description massively adds value by providing a comprehensive fuzzy-to-slug mapping table, examples, and the constraint that exactly one slug is accepted per call. This compensates beyond the schema's own documentation.

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?

Description explicitly states the function: 'Return every tracked startup within one of 20 supported sectors, ranked by engineering acceleration for the current reporting period.' The verb is specific, the resource is clear, and the scope is delineated. The 'DO NOT USE FOR' section further distinguishes it from sibling tools like get_trending_startups and get_startup_signal.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Contains dedicated 'WHEN TO USE' and 'DO NOT USE FOR' sections with explicit conditions, alternative tool names, and a typical workflow example. This provides clear guidance on when to invoke this tool versus others such as get_trending_startups or get_signals_summary.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

share_resultShare This Result (compose tweet/social)A
Read-onlyIdempotent

Generate a ready-to-share social-media post (tweet, Bluesky, Mastodon, LinkedIn, Telegram) about a result the user just received from another VC Deal Flow Signal tool, plus the install command for the MCP server. Returns the post body, character counts per platform, and one-click intent URLs to compose the post in each network. Built for the Russell-audit virality loop (Traffic Secrets §20): every share = one qualified MCP install candidate.

WHEN TO USE:

  • The user just got a get_trending_startups / search_startups_by_sector / get_startup_signal / get_deep_signal result and says 'share this', 'tweet this', 'post this', or 'how do I tell people about this?'.

  • The user is writing a thread/post about startup engineering signals and wants the canonical install command + share copy.

  • The user wants to credit the data source on a public post they're about to publish.

DO NOT USE FOR:

  • Posting on the user's behalf — this tool only composes the text + intent URLs. The user must click and confirm in the destination network.

  • Generating fake or speculative results — pass real data the agent received from another tool call.

BEHAVIOR:

  • Read-only, idempotent, no side effects, no authentication.

  • Composes platform-specific posts (Twitter ≤275 chars, Bluesky ≤300 graphemes, Mastodon ≤500, LinkedIn ≤700, Telegram ≤1000) with a consistent hook + insight + install URL + #vc / #devtools tags where idiomatic.

  • Returns intent URLs (e.g. https://x.com/intent/post?text=...) so the user/agent can open the destination network with the post pre-filled.

  • Always includes the canonical install command npx @gitdealflow/mcp-signal and the SSRN paper link for credibility.

  • Telemetry: logs that share_result was called (tool name only, never the post body).

PARAMETERS:

  • summary (string, required, 10-200 chars) — the one-line takeaway the user wants to share. Example: 'castle-engine commit velocity is up 344% over 14 days — gaming sector breakout'.

  • network (string, optional) — 'twitter' | 'bluesky' | 'mastodon' | 'linkedin' | 'telegram' | 'all' (default: 'all').

  • mention_handle (boolean, optional, default false) — whether to include @data_nerd in the post (only enabled for twitter/bluesky/mastodon).

RETURNS: { posts: { network: string, body: string, charCount: number, intentUrl: string }[], installCommand: string, methodologyUrl: string }. Each intentUrl opens the destination network's compose dialog with the body pre-filled.

TYPICAL WORKFLOW: User asks 'how do I tell people about this signal?' → agent calls share_result with the previous tool result's headline summary → agent surfaces the platform-specific posts and intent URLs → user picks one and clicks.

LIMITATIONS: Does not actually post. Does not handle threads (single posts only). Does not add hashtags beyond a small idiomatic set. The intent URLs work in browsers; on macOS/iOS native apps may register the URL handler.

ParametersJSON Schema
NameRequiredDescriptionDefault
summaryYesOne-line takeaway (10-200 chars) the user wants to share.
networkNoTarget network. 'all' returns one post per network.all
mention_handleNoInclude @data_nerd attribution. Only used on twitter/bluesky/mastodon.

Output Schema

ParametersJSON Schema
NameRequiredDescription
postsYes
installCommandYes
methodologyUrlYes

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description states the tool is read-only, idempotent, has no side effects, and requires no authentication, aligning with annotations. It also discloses telemetry logging of the tool name, and clarifies it only composes posts, not posts on behalf of the user.

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 is well-structured with clear sections but is verbose. However, given the tool's complexity, the length is justified and key information is front-loaded.

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?

The description covers typical workflow, limitations (does not post, no threads), and explains the return structure. With an output schema present, it provides enough context for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, providing baseline 3. The description adds value with concrete examples for the 'summary' parameter and explains the effect of 'network' and 'mention_handle', improving semantic understanding beyond the schema.

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 explicitly states the tool generates a ready-to-share social-media post about a result from another VC Deal Flow Signal tool. It clearly distinguishes itself from sibling tools that retrieve signals.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a 'WHEN TO USE' section listing specific scenarios and a 'DO NOT USE FOR' section clarifying it does not post on the user's behalf or generate fake results. This provides clear context for when to invoke the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv1.0.6
    • Addedget_deep_signal
    • Addedget_scout_receipts
    • Addedget_signals_summary
    • Addedshare_result
  2. 1 tool updatev1.0.5
    • Removedget_signals_summary
  3. 3 tool updatesv1.0.3
    • Changedget_startup_signal2 fields changed
      • addedOutput schema / properties / startup / properties / linkedinUrl
        Added value: +{
+  "description": "LinkedIn company page URL, when known. Populated opportunistically — often absent.",
+  "format": "uri",
+  "type": "string"
+}
      • addedOutput schema / properties / startup / properties / websiteUrl
        Added value: +{
+  "description": "Official company homepage, harvested from the GitHub org `blog` field when the org exposes one. Absent for roughly 10% of records where the org has no `blog` value.",
+  "format": "uri",
+  "type": "string"
+}
    • Changedget_trending_startups2 fields changed
      • addedOutput schema / properties / startups / items / properties / linkedinUrl
        Added value: +{
+  "description": "LinkedIn company page URL, when known. Populated opportunistically — often absent.",
+  "format": "uri",
+  "type": "string"
+}
      • addedOutput schema / properties / startups / items / properties / websiteUrl
        Added value: +{
+  "description": "Official company homepage, harvested from the GitHub org `blog` field when the org exposes one. Absent for roughly 10% of records where the org has no `blog` value.",
+  "format": "uri",
+  "type": "string"
+}
    • Changedsearch_startups_by_sector2 fields changed
      • addedOutput schema / properties / startups / items / properties / linkedinUrl
        Added value: +{
+  "description": "LinkedIn company page URL, when known. Populated opportunistically — often absent.",
+  "format": "uri",
+  "type": "string"
+}
      • addedOutput schema / properties / startups / items / properties / websiteUrl
        Added value: +{
+  "description": "Official company homepage, harvested from the GitHub org `blog` field when the org exposes one. Absent for roughly 10% of records where the org has no `blog` value.",
+  "format": "uri",
+  "type": "string"
+}
  4. 5 tool updatesv1.0.2
    • Changedget_methodology2 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "methodology": {
+      "description": "Plain-text methodology write-up.",
+      "type": "string"
+    },
+    "url": {
+      "description": "Canonical methodology page on gitdealflow.com.",
+      "format": "uri",
+      "type": "string"
+    }
+  },
+  "required": [
+    "methodology",
+    "url"
+  ],
+  "type": "object"
+}
    • Changedget_signals_summary2 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "citation": {
+      "type": "string"
+    },
+    "dashboard": {
+      "format": "uri",
+      "type": "string"
+    },
+    "formats": {
+      "properties": {
+        "aiPolicy": {
+          "format": "uri",
+          "type": "string"
+        },
+        "csv": {
+          "format": "uri",
+          "type": "string"
+        },
+        "json": {
+          "format": "uri",
+          "type": "string"
+        },
+        "llmsFullTxt": {
+          "format": "uri",
+          "type": "string"
+        },
+        "llmsTxt": {
+          "format": "uri",
+          "type": "string"
+        },
+        "openapi": {
+          "format": "uri",
+          "type": "string"
+        },
+        "rss": {
+          "format": "uri",
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "lastDataRefresh": {
+      "description": "ISO 8601 date.",
+      "type": "string"
+    },
+    "period": {
+      "type": "string"
+    },
+    "sectorsActive": {
+      "type": "integer"
+    },
+    "startupsTracked": {
+      "type": "integer"
+    },
+    "updateFrequency": {
+      "type": "string"
+    },
+    "website": {
+      "format": "uri",
+      "type": "string"
+    }
+  },
+  "required": [
+    "period",
+    "sectorsActive",
+    "startupsTracked",
+    "lastDataRefresh",
+    "formats",
+    "citation"
+  ],
+  "type": "object"
+}
    • Changedget_startup_signal6 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / name / description
        Previous value: -"Startup name or GitHub org name (e.g. 'roboflow', 'SkyPilot'). Case-insensitive."New value: +"Startup name or GitHub org name. Case-insensitive; punctuation and whitespace are ignored during matching."
      • addedInput schema / properties / name / examples
        Added value: +[
+  "roboflow",
+  "SkyPilot",
+  "Supabase",
+  "Hugging Face"
+]
      • addedInput schema / properties / name / maxLength
        Added value: +100
      • addedInput schema / properties / name / minLength
        Added value: +1
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "citation": {
+      "type": "string"
+    },
+    "found": {
+      "type": "boolean"
+    },
+    "startup": {
+      "description": "A single startup ranked by engineering acceleration, as derived from public GitHub activity.",
+      "properties": {
+        "commitVelocity14d": {
+          "description": "Commits across tracked repos in the trailing 14 days.",
+          "type": "number"
+        },
+        "commitVelocityChange": {
+          "description": "Percentage change in commit velocity vs. the prior 14-day window, e.g. '+142%'.",
+          "type": "string"
+        },
+        "contributorGrowth": {
+          "description": "Percentage change in contributor count vs. the prior 30-day window.",
+          "type": "string"
+        },
+        "contributors": {
+          "description": "Distinct contributors active in the last 30 days.",
+          "type": "integer"
+        },
+        "description": {
+          "description": "One-line summary of the startup.",
+          "type": "string"
+        },
+        "geography": {
+          "description": "Headquarters region if known.",
+          "type": "string"
+        },
+        "githubUrl": {
+          "description": "Primary GitHub org URL.",
+          "format": "uri",
+          "type": "string"
+        },
+        "name": {
+          "description": "Startup or GitHub org name.",
+          "type": "string"
+        },
+        "newRepos": {
+          "description": "New public repositories created in the last 30 days.",
+          "type": "integer"
+        },
+        "profileUrl": {
+          "description": "Public profile page on gitdealflow.com, when available.",
+          "format": "uri",
+          "type": "string"
+        },
+        "rank": {
+          "description": "1-indexed rank within this result set.",
+          "type": "integer"
+        },
+        "sector": {
+          "description": "Sector the startup is classified into.",
+          "type": "string"
+        },
+        "signalType": {
+          "description": "Classification label. Common values: 'breakout' (sudden surge), 'acceleration' (sustained growth), 'steady' (healthy baseline), 'cooling' (declining).",
+          "type": "string"
+        },
+        "stage": {
+          "description": "Funding stage if known (e.g. 'Seed', 'Series A', 'Unknown').",
+          "type": "string"
+        }
+      },
+      "required": [
+        "rank",
+        "name",
+        "commitVelocityChange",
+        "contributors",
+        "signalType",
+        "githubUrl"
+      ],
+      "type": "object"
+    },
+    "suggestion": {
+      "description": "When found=false, a hint on how to discover the correct name or alternative tools to call.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "found"
+  ],
+  "type": "object"
+}
    • Changedget_trending_startups2 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "citation": {
+      "description": "Suggested citation string for reports.",
+      "type": "string"
+    },
+    "period": {
+      "description": "Reporting period label, e.g. 'Q2 2026'.",
+      "type": "string"
+    },
+    "source": {
+      "format": "uri",
+      "type": "string"
+    },
+    "startups": {
+      "description": "Top 20 startups ranked by engineering acceleration.",
+      "items": {
+        "description": "A single startup ranked by engineering acceleration, as derived from public GitHub activity.",
+        "properties": {
+          "commitVelocity14d": {
+            "description": "Commits across tracked repos in the trailing 14 days.",
+            "type": "number"
+          },
+          "commitVelocityChange": {
+            "description": "Percentage change in commit velocity vs. the prior 14-day window, e.g. '+142%'.",
+            "type": "string"
+          },
+          "contributorGrowth": {
+            "description": "Percentage change in contributor count vs. the prior 30-day window.",
+            "type": "string"
+          },
+          "contributors": {
+            "description": "Distinct contributors active in the last 30 days.",
+            "type": "integer"
+          },
+          "description": {
+            "description": "One-line summary of the startup.",
+            "type": "string"
+          },
+          "geography": {
+            "description": "Headquarters region if known.",
+            "type": "string"
+          },
+          "githubUrl": {
+            "description": "Primary GitHub org URL.",
+            "format": "uri",
+            "type": "string"
+          },
+          "name": {
+            "description": "Startup or GitHub org name.",
+            "type": "string"
+          },
+          "newRepos": {
+            "description": "New public repositories created in the last 30 days.",
+            "type": "integer"
+          },
+          "profileUrl": {
+            "description": "Public profile page on gitdealflow.com, when available.",
+            "format": "uri",
+            "type": "string"
+          },
+          "rank": {
+            "description": "1-indexed rank within this result set.",
+            "type": "integer"
+          },
+          "sector": {
+            "description": "Sector the startup is classified into.",
+            "type": "string"
+          },
+          "signalType": {
+            "description": "Classification label. Common values: 'breakout' (sudden surge), 'acceleration' (sustained growth), 'steady' (healthy baseline), 'cooling' (declining).",
+            "type": "string"
+          },
+          "stage": {
+            "description": "Funding stage if known (e.g. 'Seed', 'Series A', 'Unknown').",
+            "type": "string"
+          }
+        },
+        "required": [
+          "rank",
+          "name",
+          "commitVelocityChange",
+          "contributors",
+          "signalType",
+          "githubUrl"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "period",
+    "startups",
+    "citation",
+    "source"
+  ],
+  "type": "object"
+}
    • Changedsearch_startups_by_sector5 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / sector / description
        Previous value: -"Sector slug, e.g. 'ai-ml', 'fintech', 'cybersecurity'"New value: +"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')."
      • addedInput schema / properties / sector / enum
        Added value: +[
+  "ai-ml",
+  "fintech",
+  "cybersecurity",
+  "developer-tools",
+  "healthcare",
+  "climate-tech",
+  "enterprise-saas",
+  "data-infrastructure",
+  "web3",
+  "robotics",
+  "edtech",
+  "ecommerce-infrastructure",
+  "supply-chain",
+  "legal-tech",
+  "hr-tech",
+  "proptech",
+  "agtech",
+  "gaming",
+  "space-tech",
+  "social-community"
+]
      • addedInput schema / properties / sector / examples
        Added value: +[
+  "ai-ml",
+  "fintech",
+  "cybersecurity",
+  "developer-tools"
+]
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "citation": {
+      "type": "string"
+    },
+    "period": {
+      "type": "string"
+    },
+    "sector": {
+      "properties": {
+        "description": {
+          "type": "string"
+        },
+        "name": {
+          "type": "string"
+        },
+        "slug": {
+          "type": "string"
+        },
+        "url": {
+          "format": "uri",
+          "type": "string"
+        }
+      },
+      "required": [
+        "slug",
+        "name"
+      ],
+      "type": "object"
+    },
+    "startupCount": {
+      "type": "integer"
+    },
+    "startups": {
+      "description": "Startups within the sector, ranked by engineering acceleration.",
+      "items": {
+        "description": "A single startup ranked by engineering acceleration, as derived from public GitHub activity.",
+        "properties": {
+          "commitVelocity14d": {
+            "description": "Commits across tracked repos in the trailing 14 days.",
+            "type": "number"
+          },
+          "commitVelocityChange": {
+            "description": "Percentage change in commit velocity vs. the prior 14-day window, e.g. '+142%'.",
+            "type": "string"
+          },
+          "contributorGrowth": {
+            "description": "Percentage change in contributor count vs. the prior 30-day window.",
+            "type": "string"
+          },
+          "contributors": {
+            "description": "Distinct contributors active in the last 30 days.",
+            "type": "integer"
+          },
+          "description": {
+            "description": "One-line summary of the startup.",
+            "type": "string"
+          },
+          "geography": {
+            "description": "Headquarters region if known.",
+            "type": "string"
+          },
+          "githubUrl": {
+            "description": "Primary GitHub org URL.",
+            "format": "uri",
+            "type": "string"
+          },
+          "name": {
+            "description": "Startup or GitHub org name.",
+            "type": "string"
+          },
+          "newRepos": {
+            "description": "New public repositories created in the last 30 days.",
+            "type": "integer"
+          },
+          "profileUrl": {
+            "description": "Public profile page on gitdealflow.com, when available.",
+            "format": "uri",
+            "type": "string"
+          },
+          "rank": {
+            "description": "1-indexed rank within this result set.",
+            "type": "integer"
+          },
+          "sector": {
+            "description": "Sector the startup is classified into.",
+            "type": "string"
+          },
+          "signalType": {
+            "description": "Classification label. Common values: 'breakout' (sudden surge), 'acceleration' (sustained growth), 'steady' (healthy baseline), 'cooling' (declining).",
+            "type": "string"
+          },
+          "stage": {
+            "description": "Funding stage if known (e.g. 'Seed', 'Series A', 'Unknown').",
+            "type": "string"
+          }
+        },
+        "required": [
+          "rank",
+          "name",
+          "commitVelocityChange",
+          "contributors",
+          "signalType",
+          "githubUrl"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "sector",
+    "period",
+    "startupCount",
+    "startups",
+    "citation"
+  ],
+  "type": "object"
+}
  5. 5 tool updatesv1.0.0
    • First observedget_methodology
    • First observedget_signals_summary
    • First observedget_startup_signal
    • First observedget_trending_startups
    • First observedsearch_startups_by_sector
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.7/5.0

Scored across 8 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: discovery (trending, sector search), lookup (single startup), metadata (summary, methodology), a paid deep-dive (get_deep_signal), a separate GitHub-user scoring tool (get_scout_receipts), and a sharing utility. No two tools appear to do the same thing.

Naming Consistency4/5

Most tools follow a `get_*` prefix (get_trending_startups, get_startup_signal, get_scout_receipts, get_deep_signal, get_methodology, get_signals_summary), but `search_startups_by_sector` and `share_result` break the pattern. Minor deviation but still predictable and clear.

Tool Count5/5

Eight tools cover the domain without excess. The count feels right for a specialized signal service: multiple query modes, one premium add-on, metadata, methodology, and a sharing helper.

Completeness5/5

The set covers the full workflow: orientation (get_signals_summary), broad discovery (get_trending_startups), sector filtering (search_startups_by_sector), single-company deep dive (get_startup_signal), premium insights (get_deep_signal), context (get_methodology), plus an auxiliary scout feature. No obvious gaps for its stated purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Git Metrics MCP Server

    jonmatum
    A
    license
    B
    quality
    C
    maintenance
    Analyzes git repository metrics to understand team health, development patterns, code quality, and collaboration through natural language queries. Provides insights on commit statistics, bus factor, velocity trends, technical debt, and burnout detection.
    12
    8 npm
    1
    MIT

  • Frontrun MCP Server

    jongall45
    A
    license
    A
    quality
    B
    maintenance
    Provides AI agents with native access to the Frontrun API to track venture capital activities on X in real time. It enables users to monitor new follows, detect multi-account convergence signals, and identify trending companies across monitored accounts.
    18
    109 npm
    1
    MIT