Skip to main content
Glama
diffbot-mcp

diffbot-mcp

Official

Search Deals

search_deals
Read-onlyIdempotent

Find funding rounds, investments, and acquisitions by company, investor, acquirer, series, amount, date, or industry to track deal flow, funding history, portfolios, and M&A lists.

Instructions

Funding rounds, investments, and acquisitions in the Diffbot Knowledge Graph by company, investor, acquirer, round series, amount, date, or the company's industry. Prefer for deal flow, a company's funding history, an investor's portfolio activity, M&A lists, and the largest deals in a period. For related company data use search_organizations. API docs: https://www.diffbot.com/docs/dql/

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_deals"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNofunding | acquisitions | anyfunding
sizeNoMax rows or buckets
sortNoDefault newest; `largest` for biggest deals first
facetNoBucket by series, investors, or amount
sinceNoEarliest date, YYYY-MM-DD
untilNoLatest date, YYYY-MM-DD
amountNoDeal size range, e.g. '50M+', '1M-10M'
offsetNoRows to skip
seriesNoRound, e.g. 'Series A'
companyNoCompany raising or acquired
acquirerNoAcquirer name
currencyNoCurrency of amountUSD
industryNoCompany's industry; free text ok
investorNoInvestor name

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety and idempotency are covered by structured data. The description adds no behavior beyond that – nothing about result caps, how size/offset pagination behaves, or how faceting changes the response shape. It only supplies a docs URL for deeper behavior.

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?

Two compact sentences plus a docs link; the resource scope is front-loaded before the usage scenarios, and there is no filler. The opening is a sentence fragment without a verb, a minor structural weakness but not a cost in length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be explained, and the rich annotations cover the safety profile. For a 14-parameter, zero-required search tool the description covers scope and selection adequately, though it omits any guidance on pagination depth or how the three facet buckets alter results.

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 description coverage is 100%, so every one of the 14 parameters is already documented in the schema, including enums and examples like '50M+' and YYYY-MM-DD. The description's list of filterable dimensions largely mirrors the parameter names rather than adding syntax or interaction rules (e.g. how facet interacts with size or sort). Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the specific resource (funding rounds, investments, acquisitions in the Diffbot Knowledge Graph) and the filterable dimensions (company, investor, acquirer, series, amount, date, industry). It also explicitly distinguishes itself from search_organizations for related company data. The verb is only implied by the tool name rather than stated, which keeps it just short of a 5.

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

Usage Guidelines4/5

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

It gives concrete when-to-use scenarios (deal flow, a company's funding history, investor portfolio activity, M&A lists, largest deals in a period) and routes the agent to search_organizations for adjacent needs. It stops short of stating when NOT to use it, e.g. when a custom DQL query via the dql sibling would be more appropriate.

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