Skip to main content
Glama

Search deals

mergers_search
Read-onlyIdempotent

Deals from the merger-control authorities of the EU, the UK, Germany, France, Finland and the US, and from SEC filings, refreshed daily: the parties and their roles, the dates, the status and, where a filing states one, the value with the sentence it was read from. Search by a company (its id or name) as acquirer or target, by words of the deal, by country and by date; news reports join only when asked, marked unconfirmed. Each reply says how far back each source goes. Costs $0.01 per deal returned; nothing if none are found.

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": "mergers_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
roleNoThe company's part in the deal.any
textNoWords that must all appear in the deal's title, activities or sector.
limitNo
sinceNoThe earliest deal date, e.g. 2024-01-01.
untilNo
companyNoA company id from companies_search (gb:00578327, us:769520) or a name.
sourcesNo
countriesNoTwo-letter codes: the authority's country (EU for the Commission) or a party's.
with_valueNoOnly deals whose filing states a price.
include_newsNoAdd news reports (GDELT), marked unconfirmed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations it discloses freshness (refreshed daily), per-source coverage reported in each reply, the unconfirmed marking of GDELT news, and the cost model ($0.01 per deal returned, free when empty). These are exactly the traits an agent cannot infer from structured fields.

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 dense sentences that front-load the source scope before the query capabilities and the cost note. High information density with little waste, though the first sentence mixes provenance, freshness, and field list into one long span.

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?

For a 10-parameter, read-only search with no output schema, it covers what a caller needs: data sources, fields returned, defaults like news opt-in, coverage caveats and pricing. Only result ordering/pagination behavior across the limit is unaddressed.

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 70%, and the description still adds meaning: 'as acquirer or target' glosses the role enum, 'words of the deal' scopes text, 'news reports join only when asked' explains include_news, and the value field is described as read from a filing sentence. limit and with_value get no extra treatment, keeping it below a 5.

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?

States a specific resource (merger-control and SEC deal filings) with the covered jurisdictions and refresh cadence, and enumerates the returned fields (parties, roles, dates, status, value with source sentence). It never names the sibling tools it is not (mergers_get, mergers_acquirers, companies_search), so differentiation is left implicit.

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

Usage Guidelines3/5

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

Gives in-tool query guidance ('Search by a company ... as acquirer or target, by words of the deal, by country and by date') and an opt-in rule for news, but never says when to prefer this over mergers_get/mergers_acquirers or when not to use it. Usage is implied rather than routed.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources