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_startups → pick a name → get_startup_signal(name) for the deep-dive → get_methodology if the user questions the ranking.

LIMITATIONS: Only covers startups with a meaningful open-source footprint. Does not include funding, revenue, headcount, or stealth companies — pair with Crunchbase for cap-table and round data. No historical series — each call is the latest weekly snapshot only.

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.

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.

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

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.

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:

• 100 credits = €19 one-time (€0.19 per call). Buy at https://signals.gitdealflow.com/agents/credits

• 1 credit consumed only on a successful match. found: false is FREE.

• Credits never expire.

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.

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.

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.