KeyVex

get_tender_offers

Read-only

Returns SEC Schedule TO filings — public tender offer disclosures. Use this when the user asks about: who's bidding to acquire company X, what M&A offers are in flight, share buyback announcements, amendments to existing tender offers (price increases / extensions), or to pair with 13D activist stakes for the 'stake → bid' story. Source: SEC EDGAR full-text search. Forms covered: SC TO-T (third- party tender offer — someone outside the company bidding for shares), SC TO-T/A (amendments), SC TO-I (issuer tender offer — company buying back its own shares), SC TO-I/A (issuer amendments). v1 returns filing metadata only — bidder + target + form type + filing date + URL. Offer price, shares sought, and expiration date live inside the HTML attachment at primary_document_url; agents follow that URL to read the substantive terms. Amendment filings share the same target/bidder/file_number as the original offer; use file_number to group an amendment chain. Pure-publisher posture: KeyVex does not derive 'likely to close' or 'expected premium' signals. The data here is what was filed, no more.

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

Input Schema

Name	Required	Description
`limit`	No	Maximum filings to return. Default 50, max 500.
`since`	No	Filing date lower bound (ISO YYYY-MM-DD inclusive).
`until`	No	Filing date upper bound (ISO YYYY-MM-DD inclusive).
`form_type`	No	Exact form match. Useful for narrowing to amendments only ('SC TO-T/A') or original offers only ('SC TO-T').
`bidder_cik`	No	Bidder's SEC CIK. Find all tender offers by a particular acquirer.
`sort_order`	No	Default: desc (most recent filings first).
`target_cik`	No	Target's SEC CIK (10-digit zero-padded). Use when ticker is ambiguous (multiple share classes).
`bidder_name`	No	Case-insensitive substring against bidder_name. Bidders in SC TO-T are often private SPVs ('2025 Acquisition Company, LLC') — use this to find them by issuer / parent name.
`issuer_only`	No	When true, restricts to SC TO-I family (issuer buybacks). Default false.
`target_name`	No	Case-insensitive substring against target_name. Useful when ticker isn't known (e.g., private companies in TO-T filings).
`target_ticker`	No	Target company ticker (e.g., 'KZR'). For SC TO-T this is the company being bid for; for SC TO-I this is the company buying back its own shares (target == bidder).
`accession_number`	No	EDGAR accession number (e.g., '0001140361-26-020397'). Direct doc lookup, fastest path.
`third_party_only`	No	When true, restricts to SC TO-T family (third-party offers). Default false.
`exclude_amendments`	No	When true, drops /A amendment filings. Default false (amendments included).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly, non-destructive, openWorld). The description adds substantial behavioral context beyond them: v1 returns filing metadata only, substantive terms (price, shares sought, expiration) live in the HTML at primary_document_url, amendments chain via file_number, and a stated no-derivation 'pure-publisher' posture.

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?

Front-loaded with purpose and usage, then form taxonomy, then output limitations. Dense and largely earned, though the form-type parentheticals and the closing posture sentence add some length that could be trimmed without losing signal.

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?

With no output schema, the description must explain the return shape, and it does so precisely: metadata fields returned (bidder, target, form, date, URL) versus terms deferred to the attachment. A 14-parameter, zero-required tool is fully covered.

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 description coverage is 100%, so the schema carries the parameter burden (baseline 3). The description still adds interpretation beyond it — e.g., grouping amendment chains via file_number, the target==bidder relationship for SC TO-I, and SPV bidder naming in SC TO-T — which meaningfully guides filtering choices.

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?

States a specific verb+resource ('Returns SEC Schedule TO filings — public tender offer disclosures') and enumerates the exact form types covered (SC TO-T, SC TO-T/A, SC TO-I, SC TO-I/A) with plain-language glosses. It explicitly distinguishes itself from siblings by naming the 13D activist-stakes tool it pairs with.

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?

Provides an explicit 'Use this when the user asks about...' list covering bidder identification, in-flight M&A offers, buybacks, and amendments, plus the compound 'stake → bid' workflow with get_activist_stakes. An agent can route to this tool from a user question without inference.

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

All KeyVex 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?