Skip to main content
Glama
kindrat86

mcp-deal-flow-signal

Get Dataset Summary

get_signals_summary
Read-onlyIdempotent

Retrieve a summary of the VC Deal Flow Signal dataset: current period, active sectors, tracked startups, last refresh, update frequency, citation, and download links for CSV, JSON, RSS, and more.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
periodYes
sectorsActiveYes
startupsTrackedYes
lastDataRefreshYesISO 8601 date.
updateFrequencyNo
formatsYes
websiteNo
dashboardNo
citationYes

Implementation Reference

  • src/server.ts:451-529 (registration)
    Tool registration for 'get_signals_summary' in the TOOLS array — defines name, title, description, inputSchema, outputSchema, and annotations.
    {
      name: "get_signals_summary",
      title: "Get Dataset Summary",
      description: [
        "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).",
      ].join("\n"),
      inputSchema: {
        type: "object" as const,
        properties: {},
        additionalProperties: false,
      },
      outputSchema: {
        type: "object" as const,
        properties: {
          period: { type: "string" },
          sectorsActive: { type: "integer" },
          startupsTracked: { type: "integer" },
          lastDataRefresh: { type: "string", description: "ISO 8601 date." },
          updateFrequency: { type: "string" },
          formats: {
            type: "object",
            properties: {
              json: { type: "string", format: "uri" },
              csv: { type: "string", format: "uri" },
              rss: { type: "string", format: "uri" },
              openapi: { type: "string", format: "uri" },
              llmsTxt: { type: "string", format: "uri" },
              llmsFullTxt: { type: "string", format: "uri" },
              aiPolicy: { type: "string", format: "uri" },
            },
          },
          website: { type: "string", format: "uri" },
          dashboard: { type: "string", format: "uri" },
          citation: { type: "string" },
        },
        required: [
          "period",
          "sectorsActive",
          "startupsTracked",
          "lastDataRefresh",
          "formats",
          "citation",
        ],
      },
      annotations: {
        title: "Get Dataset Summary",
        readOnlyHint: true,
        destructiveHint: false,
        idempotentHint: true,
        openWorldHint: true,
      },
    },
  • Input schema (no parameters) and output schema for get_signals_summary — defines the shape of the structured response including period, sectorsActive, startupsTracked, lastDataRefresh, formats, website, dashboard, citation.
      inputSchema: {
        type: "object" as const,
        properties: {},
        additionalProperties: false,
      },
      outputSchema: {
        type: "object" as const,
        properties: {
          period: { type: "string" },
          sectorsActive: { type: "integer" },
          startupsTracked: { type: "integer" },
          lastDataRefresh: { type: "string", description: "ISO 8601 date." },
          updateFrequency: { type: "string" },
          formats: {
            type: "object",
            properties: {
              json: { type: "string", format: "uri" },
              csv: { type: "string", format: "uri" },
              rss: { type: "string", format: "uri" },
              openapi: { type: "string", format: "uri" },
              llmsTxt: { type: "string", format: "uri" },
              llmsFullTxt: { type: "string", format: "uri" },
              aiPolicy: { type: "string", format: "uri" },
            },
          },
          website: { type: "string", format: "uri" },
          dashboard: { type: "string", format: "uri" },
          citation: { type: "string" },
        },
        required: [
          "period",
          "sectorsActive",
          "startupsTracked",
          "lastDataRefresh",
          "formats",
          "citation",
        ],
      },
      annotations: {
        title: "Get Dataset Summary",
        readOnlyHint: true,
        destructiveHint: false,
        idempotentHint: true,
        openWorldHint: true,
      },
    },
  • Handler logic for 'get_signals_summary' tool in the CallToolRequestSchema switch statement. Fetches /api/changelog.json, extracts currentPeriod data, builds formats object with all data format URLs, and returns both a human-readable text block and structuredContent with period, sectorsActive, startupsTracked, lastDataRefresh, updateFrequency, formats, website, dashboard, citation.
    case "get_signals_summary": {
      const changelog = (await fetchJSON(
        "/api/changelog.json"
      )) as unknown as ChangelogData;
      const cp = changelog.currentPeriod;
      const formats = {
        json: `${BASE_URL}/api/signals.json`,
        csv: `${BASE_URL}/api/signals.csv`,
        rss: `${BASE_URL}/feed.xml`,
        openapi: `${BASE_URL}/api/openapi.json`,
        llmsTxt: `${BASE_URL}/llms.txt`,
        llmsFullTxt: `${BASE_URL}/llms-full.txt`,
        aiPolicy: `${BASE_URL}/ai.txt`,
      };
      return {
        content: [
          {
            type: "text" as const,
            text: [
              `VC Deal Flow Signal — Data Summary`,
              ``,
              `Current Period: ${cp.name}`,
              `Sectors Active: ${cp.sectorsActive}`,
              `Startups Tracked: ${cp.startupsTracked}`,
              `Last Data Refresh: ${cp.lastDataRefresh}`,
              `Update Frequency: Weekly (Mondays)`,
              ``,
              `Data Formats:`,
              `- JSON API: ${formats.json}`,
              `- CSV: ${formats.csv}`,
              `- RSS: ${formats.rss}`,
              `- OpenAPI: ${formats.openapi}`,
              `- LLMs.txt: ${formats.llmsTxt}`,
              `- Full context: ${formats.llmsFullTxt}`,
              `- AI policy: ${formats.aiPolicy}`,
              ``,
              `Website: https://gitdealflow.com`,
              `Dashboard: ${BASE_URL}`,
              ``,
              `Citation: "VC Deal Flow Signal (signals.gitdealflow.com), ${cp.name} data."`,
              ``,
              FOOTER,
            ].join("\n"),
          },
        ],
        structuredContent: {
          period: cp.name,
          sectorsActive: cp.sectorsActive,
          startupsTracked: cp.startupsTracked,
          lastDataRefresh: cp.lastDataRefresh,
          updateFrequency: "Weekly (Mondays)",
          formats,
          website: "https://gitdealflow.com",
          dashboard: BASE_URL,
          citation: `VC Deal Flow Signal (signals.gitdealflow.com), ${cp.name} data.`,
        },
      };
    }
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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kindrat86/mcp-deal-flow-signal'

If you have feedback or need assistance with the MCP directory API, please join our Discord server