Source-cited register of layoffs linked to AI, plus a live 0-100 AI job-loss index. No key.
Scored across 4 tools
Each tool occupies a distinct query space: count_ai_job_losses returns aggregate headline figures, get_ai_layoffs_index returns a single scaled index reading, get_company_ai_layoffs answers a company-specific verdict, and search_ai_layoff_events browses underlying events. There is no meaningful overlap in purpose, and the descriptions reinforce the boundaries (e.g. counts are whole-register published figures, not search sums).
All names use consistent snake_case with a leading verb (count_, get_, get_, search_) followed by a noun phrase, which is highly predictable. Minor terminology drift between 'job_losses' and 'layoffs' for the same domain slightly reduces clarity, but the pattern is otherwise clean.
Four tools is on the lean side but each earns its place by covering a different access mode (aggregate count, index score, company lookup, event search). A shallow surface, but nothing redundant and nothing clearly trivial.
The surface covers the core lifecycle of the domain: headline totals, a composite index, per-company verdicts, and filterable event search with source citations. Minor gaps exist (e.g. no explicit trend/time-series or company-listing operation), but agents can largely work around them via search filters and the index change value.
Answers 'how many jobs has AI replaced (or cost) this year?' with the register's published count: roles disclosed in layoffs linked to AI, roles where the employer itself named AI, the evidence-weighted headline figure, and the independent Challenger, Gray & Christmas count of US cuts attributed to AI. Each figure carries its scope (worldwide or US), its period and its definition, plus the ready-made answer sentence. The totals are computed over the whole register, so they are the published figures, not a sum of search results. Takes no arguments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond that: counts are computed over the whole register, are published figures not sums of search results, and each figure includes scope, period, and definition. This helps set correct expectations for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat dense but every sentence contributes useful information: the question answered, the list of figures, the metadata carried, the computation method, and the lack of arguments. It is front-loaded with the main purpose and does not waste words, though it could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument, read-only tool with full schema coverage and no output schema, the description is remarkably complete. It tells the agent what figures will be present, their scope/period/definition, and clarifies that totals are register-wide published numbers rather than search-derived sums. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the description states 'Takes no arguments,' matching the schema coverage of 100%. Per the rubric, a 0-parameter tool gets a baseline of 4, and no additional semantic detail is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly answers a specific question ('how many jobs has AI replaced...') with a specific resource (the register's published count), and distinguishes itself from siblings that fetch indexes, company-level details, or search events. It enumerates the exact figures returned, leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the exact question this tool answers, which implicitly defines when to use it. It does not mention alternatives or exclusions, but the context is clear enough for an agent to select it for aggregate count queries. A 5 would require explicit sibling routing, which is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current reading of the AI Layoffs Index, a 0-100 score of AI-attributed job-loss pressure scaled against AI's own history since 2023 (not a share of all jobs). Returns the value, its band, the uncertainty range, the change vs last month, the three weighted components with what each reads, the as-of date, and a ready-made citation string. Takes no arguments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it readOnly, idempotent, and non-destructive, so the description only needs to add context. It adds the important scale interpretation ('scaled against AI's own history since 2023, not a share of all jobs') and lists the exact returned fields, including the as-of date and uncertainty range, which help the agent understand the result without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the tool's essential purpose and metric clarification, and then lists the output contents efficiently. The 'not a share of all jobs' caveat is placed early where it prevents misinterpretation, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because there is no output schema, the description takes on the burden of describing the return value, and it does so thoroughly (value, band, uncertainty range, change, components, as-of date, citation string). With no parameters, read-only annotations, and low complexity, nothing essential is missing for an agent to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema is empty and there are no parameter semantics to document. The description explicitly confirms 'Takes no arguments,' which is more than enough; per the rubric, zero-parameter tools get a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (the AI Layoffs Index) and a clear action (returns the current reading), and explains the metric's scale and scope ('0-100 score... not a share of all jobs'). This clearly differentiates it from sibling tools that count or search individual layoff events/company layoffs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to prefer this tool over its siblings (count_ai_job_losses, get_company_ai_layoffs, search_ai_layoff_events). The phrase 'Current reading' implies the tool is for the aggregate index snapshot, but there are no explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Did a specific company cut jobs because of AI? Returns the register's verdict for that company (explicit, mixed or blamed: the strongest grade among its cuts), its answer (the strongest position its own words hold: declared, cited, conflicting, attrition, denied, not-named, or statement for a workforce statement with no cut), a plain-language summary, the roles it disclosed vs the roles counted as AI-attributed, and every recorded event with the employer's own words and source. It also lists the company's later cuts that the register checked and left out because neither the employer nor credible press linked them to AI (later_cuts_not_ai_linked, never counted), so a question about the newest layoff is answered either way. Accepts a company name such as 'Klarna' or 'Salesforce'. If the company is not in the register, says so and what that does and does not mean.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company name, e.g. 'Klarna', 'IBM', 'Salesforce'. Partial names work. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, yet the description adds real behavior: the verdict grading scheme, the answer categories, and that later_cuts_not_ai_linked are deliberately never counted. It also discloses the not-found response, which is exactly the kind of edge-case behavior an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Key question is front-loaded and the dense clauses each carry return semantics rather than filler, which is justified because there is no output schema. It is one long run-on paragraph with some redundancy ('answered either way') that bullets could tighten.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing the response and does so thoroughly: verdict grades, answer categories, roles disclosed vs AI-attributed, per-event employer words and sources, and excluded later cuts. The not-in-register behavior is also covered, so an agent knows what it will and will not get.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the single 'company' parameter including partial-name support and example values. The description's 'Accepts a company name such as Klarna or Salesforce' largely restates the schema, adding little beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — returns the register's verdict for one named company — and the company-scoped framing cleanly separates it from the siblings (count_ai_job_losses, get_ai_layoffs_index, search_ai_layoff_events). An agent can tell what it does and that it is the per-company lookup without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The leading question ('Did a specific company cut jobs because of AI?') plus 'Accepts a company name such as Klarna or Salesforce' gives clear context for when to reach for this tool, and the not-in-register fallback is spelled out. It never names the alternatives (index, search, count) or states when not to use it, so it stops short of explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the source-cited register of layoffs linked to AI (one row per event, 2023 to date). Filter by company, free text, attribution, evidence tier, execution status, country, sector, affected role and date range; call with no arguments for the most recent events. Each event returns the employer's own stated reason (claim), roles counted vs reported but not counted, execution status, and a link to its source and its ailayoffs.org company page; set full_context for each event's longer context paragraph.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Affected function or occupation, partial match, e.g. 'customer service', 'engineering'. | |
| sort | No | newest first (default), oldest first, or the largest disclosed cut first. | |
| limit | No | Maximum events to return (default 10, at most 50). | |
| query | No | Free text matched against the company, the stated reason, the context paragraph, sector, country, affected roles and source name. Every word must appear. Example: 'customer service'. | |
| since | No | Earliest event date, inclusive: YYYY, YYYY-MM or YYYY-MM-DD. | |
| until | No | Latest event date, inclusive: YYYY, YYYY-MM or YYYY-MM-DD. | |
| sector | No | Sector, partial match, e.g. 'Financial', 'Software'. | |
| company | No | Company name or part of it, e.g. 'Klarna'. | |
| country | No | Country as recorded, partial match, e.g. 'United States', 'India', 'Sweden'. For US-based roles use us_only. | |
| us_only | No | Only events whose affected roles are US-based. | |
| execution | No | Keep only these execution statuses. executed: The reduction has been carried out. partial: Some of the cut is done, the rest pending. announced: A stated plan, not yet carried out (often multi-year). unknown: Execution status not established. reversed: The cut was rolled back or rehired against (e.g. Commonwealth Bank). | |
| attribution | No | Keep only these attribution levels. explicit: The company itself declared the layoff AI-related, without citing other material factors. blamed: A credible source named AI, but the company did not. Shown as context and never counted: the register's standard requires the employer's own words to name AI, so a blamed event is a failed claim, not a discounted one. mixed: AI was cited alongside other material factors (cost, demand). | |
| counted_only | No | Only events whose roles the register counts as AI-attributed (drops events that are reported but not counted). | |
| full_context | No | Also return each event's context paragraph. Several times longer, so best with a small limit; get_company_ai_layoffs always includes it for one company. | |
| evidence_tier | No | Keep only these evidence tiers. tier1 (Primary-source attributed): AI named as a workforce driver in the company's own SEC filing, on-record earnings call, or official statement, with the event corroborated by a structured source. tier2 (Reputable-press attributed): AI named as a cause by credible journalism quoting a named company source, but not yet in a company filing. tier3 (Inferred / single-source): Attribution from one secondary tracker, an unnamed source, or vague forward-looking language. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description goes beyond them by disclosing the return shape — the employer's own stated reason (claim), roles counted vs merely reported, execution status, and source plus ailayoffs.org company page — and by flagging the full_context payload-size tradeoff. That is meaningful behavioral context the annotations do not carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the purpose and scope before the filter list and the return description. The middle sentence is dense but each clause maps to a distinct capability, so there is little wasted text; it is slightly long relative to what the schema already covers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing returns and does so adequately (claim, counted vs reported roles, execution status, source link, optional context paragraph). Combined with 100% schema coverage on 15 params and clear annotations, an agent has enough to call the tool correctly; only the sibling-routing story is thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% across 15 parameters, so the schema already documents every field, including enums and examples. The description restates the same filter list without adding syntax, defaults, or interaction rules beyond what the schema provides, so it earns the baseline 3 rather than more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb+resource and scope: 'Search the source-cited register of layoffs linked to AI (one row per event, 2023 to date).' It also enumerates the filter dimensions, so an agent immediately knows what the tool is. Sibling differentiation is only partial — get_company_ai_layoffs is mentioned, but count_ai_job_losses and get_ai_layoffs_index are not contrasted, and that routing information is buried inside a parameter description rather than the main body.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear default path ('call with no arguments for the most recent events') and notes that full_context is 'best with a small limit' while get_company_ai_layoffs 'always includes it for one company', which steers the agent between tools. What is missing is explicit when-not-to-use guidance against the counting/index siblings, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
search_ai_layoff_events1 field changedInput schema / properties / attribution / descriptionPrevious value: -"Keep only these attribution levels. explicit: The company itself declared the layoff AI-related. blamed: A credible source named AI, but the company did not. Shown as context and never counted: prong 1 of our standard requires the employer's own source to name AI, so a blamed event is a failed claim, not a discounted one. mixed: AI was cited alongside other material factors (cost, demand)."New value: +"Keep only these attribution levels. explicit: The company itself declared the layoff AI-related, without citing other material factors. blamed: A credible source named AI, but the company did not. Shown as context and never counted: the register's standard requires the employer's own words to name AI, so a blamed event is a failed claim, not a discounted one. mixed: AI was cited alongside other material factors (cost, demand)."search_ai_layoff_events2 fields changedInput schema / properties / full_context / descriptionPrevious value: -"Also return each event's context paragraph and the register's caveats. Several times longer, so best with a small limit; get_company_ai_layoffs always includes them for one company."New value: +"Also return each event's context paragraph. Several times longer, so best with a small limit; get_company_ai_layoffs always includes it for one company."Input schema / properties / query / descriptionPrevious value: -"Free text matched against the company, the stated reason, the context notes, sector, country and affected roles. Every word must appear. Example: 'customer service'."New value: +"Free text matched against the company, the stated reason, the context paragraph, sector, country, affected roles and source name. Every word must appear. Example: 'customer service'."count_ai_job_lossesget_ai_layoffs_indexget_company_ai_layoffssearch_ai_layoff_eventsSourced, task-level facts on how AI changes jobs, for agents answering 'what should I do?'
Open jobs and hiring changes per company, daily. Free keyless lookup. AI-compiled from job boards.
Free, read-only data on about 4,900 AI companies, open AI jobs and dated AI news, with source links.
WARN Act layoff notices — state-by-state.
Add one secure layer between your agents and this server.