Skip to main content
Glama

fundz

by net.fundz
OverviewDiscussionsAdmin

Search layoffs (news, SEC filings, WARN notices)

search_layoffs
Read-onlyIdempotent

Layoffs, plant closures and reductions in force from three sources, returned together by default: (1) layoffs announced or reported in the news (company, headcount and percent cut when stated, HQ, affected sites and teams, confirmed vs reported by sources, every article on the event), (2) SEC 8-K filings for restructuring or exit costs (Item 2.05) or a disclosed workforce reduction, and (3) state WARN Act notices employers must file before a mass layoff (the same feed as app.fundz.net/warn-notices). Use source to read one only. A news layoff and an 8-K for the same company are shown as one event. For WARN notices: company, worksite city and state, notice and effective dates, number of employees affected, layoff or closure type (permanent or temporary), industry and a link to the state source. Each row carries a 0-100 distress score that adds weight when the company also filed an SEC 8-K for restructuring (Item 2.05) or an executive or director departure (Item 5.02) within 90 days of the notice, the moment a company is most likely to replace leaders or reorganize. Filter by state, company, notice date, minimum employees affected and layoff type; sort by newest, effective date, size or distress. Use territory to match the states on this Fundz account.

Input Schema

NameRequiredDescriptionDefault
daysNoOnly the last N days (WARN default: all; news and filings default 30, max 180)
pageNoPage number, starting at 1 (default 1). The reply ends with the total and next_page when there are more.
sortNonewest (default, by notice date), effective_date, employees (largest first) or distress (highest distress score on each page)
limitNoResults per page (default 20, max 50)
sinceNoOnly notices on or after this ISO date, e.g. "2026-10-01". Overrides days.
stateNoUS state 2-letter code(s), comma-separated, e.g. "CA, NY". WARN: the worksite. News: the company HQ or an affected site. Filings: the company HQ.
sourceNoall (default: news, SEC filings and WARN notices), news, filings or warn; comma-separate to combine, e.g. "news, filings"
territoryNotrue = only the states in this Fundz account's targeting. Ignored when state is given.
layoff_typeNolayoff or closure (each matches permanent, temporary and not-yet-known), or a fuller value such as "Closure Permanent"
company_nameNoCompany name (partial, case-insensitive)
matched_onlyNotrue = only notices linked to a Fundz company profile (needed to look up contacts and executives next)
min_employeesNoMinimum employees affected, e.g. 100

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / days / description
      Previous value: -"Only notices filed in the last N days (default: all)"New value: +"Only the last N days (WARN default: all; news and filings default 30, max 180)"
    • addedInput schema / properties / source
      Added value: +{
+  "description": "all (default: news, SEC filings and WARN notices), news, filings or warn; comma-separate to combine, e.g. \"news, filings\"",
+  "type": "string"
+}
    • changedInput schema / properties / state / description
      Previous value: -"US state 2-letter code(s) of the worksite, comma-separated, e.g. \"CA, NY\""New value: +"US state 2-letter code(s), comma-separated, e.g. \"CA, NY\". WARN: the worksite. News: the company HQ or an affected site. Filings: the company HQ."
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover readOnly/idempotent/non-destructive, and the description layers on meaningful behavior beyond them: the combined-event dedup logic, the composition of the 0-100 distress score (8-K Item 2.05 restructuring or Item 5.02 departures within 90 days), and WARN filing semantics. This is exactly the extra context annotations cannot carry.

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-loads the three sources before the field detail, and every sentence carries substance, but the single dense paragraph could be broken into clearer segments. Slightly long, though not padded.

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 and 12 optional parameters, the description compensates by enumerating the returned fields per source (WARN: worksite, dates, employee count, type, industry, link; news: headcount, percent, HQ, sites, confirmation status) and explaining the distress score. An agent has everything needed to call and interpret the tool.

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 schema already documents all 12 parameters in detail, including territory's interaction with state and matched_only's purpose. The description's filter list ('state, company, notice date, minimum employees affected and layoff type; sort by newest, effective date, size or distress') largely restates the schema, so the baseline 3 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?

Names a specific verb (search) plus the exact resource (layoffs/plant closures/RIFs) and enumerates the three sources it draws from, with the fields each source returns. An agent can distinguish it from siblings like search_sec_filings or search_major_events purely from the description.

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?

Gives clear usage context: default behavior merges all three sources, 'Use source to read one only,' dedup rule that a news layoff and an 8-K for the same company appear as one event, and 'matched_only' is flagged as needed before looking up contacts next. It stops short of explicitly naming alternative sibling tools or when NOT to use it.

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

All fundz toolsInspect
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