Deal Radar

deal_events_8k

Public-company 8-K filings filtered by item code or event type (M&A, executive change, financing, bankruptcy, or the default deal items). Each row has the item codes, a plain-English event type, a one-line summary from the filing, company, website and domain when EDGAR has one, state, SIC industry, parsed dollar amount when the text states one, and the sec.gov filing link. Missing values are null. Up to 50 events per call, date windows up to 31 days. Costs $0.01 USDC.

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

Input Schema

Name	Required	Description
`items`	No	Comma-separated 8-K item codes or plain-English types (M&A, executive change, financing, bankruptcy). Default codes: 1.01,2.01,2.03,3.02,5.01.
`limit`	No	Events returned, 1-50, default 25.
`states`	No	Comma-separated business-state codes, e.g. NY,CA.
`endDate`	No	YYYY-MM-DD, default today.
`minAmount`	No	Minimum dollar amount parsed from the event text. Events with no parsed amount are omitted.
`startDate`	No	YYYY-MM-DD, default yesterday.
`industries`	No	Comma-separated words matched against the SEC SIC description, e.g. software, bank.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 28, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses per-call row limits, the 31-day date-window cap, null handling for missing values, and a $0.01 USDC cost that implies payment/auth requirements. Remaining gaps are pagination behavior and error semantics beyond the caps.

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?

Three sentences, front-loaded with the resource and filter model, then return shape, then hard limits and price. Every clause carries operational information; nothing is repeated from the title.

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 7-parameter, no-output-schema read tool, the description explicitly enumerates the returned row fields (item codes, event type, summary, company, domain, state, SIC, amount, sec.gov link), which substitutes for a missing output schema. Pagination and ordering are the main omissions.

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%, so the baseline is 3. The description reinforces the items filter (including the default code set) and explains that minAmount drops events with no parsed amount, but adds little beyond what the schema already documents for the other six parameters.

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 verb/resource combination: 8-K filings filtered by item code or event type, with the event categories enumerated. It is clearly distinct from formd_leads and ping by resource type, but it never names or contrasts those siblings explicitly, so it falls 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 Guidelines3/5

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

Usage context is implied by describing what filters exist and by noting the default deal items, plus the 31-day window and 50-row cap. There is no explicit when-to-use vs when-not, and no guidance on preferring formd_leads for private-company raises.

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

All Deal Radar tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?