WARN layoffs, H-1B/LCA visas, SEC 8-K, bankruptcies, DOL claims & JOLTS for all 50 US states.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4/5 across 12 of 12 tools scored. Lowest: 2.7/5.
Several tools overlap in function: get_recent_layoffs, get_state_summary, and search_layoffs all return layoff notices with various filters. get_state_intelligence also overlaps with get_state_summary but adds cross-dataset information. Descriptions help, but an agent may struggle to choose the right tool without careful reading.
Most tools follow a get_verb pattern and use snake_case consistently. A few deviations like authenticate (verb-only), search_layoffs, and export_records are action-oriented but acceptable, making the overall pattern mostly predictable.
With 12 tools, the server is well-scoped for a labor market intelligence API. Each tool serves a distinct purpose, and the count is neither sparse nor overwhelming for the domain.
The tool set covers core workflows: authentication, search, bulk export, state-level intelligence, risk signals, and talent pipeline. Minor gaps exist, such as no company-level cross-dataset view (similar to state_intelligence for a company) and no direct record-by-ID retrieval, but these are workable.
authenticateAInspectAuthenticate with your WARN Firehose API key. Returns your tier and access level.
Args:
api_key: Your WARN Firehose API key (starts with wf_)
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It discloses the return value (tier and access level) and the API key format (starts with wf_), but does not mention failure modes, error responses, or any session side effects, leaving some behavioral gaps.
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 short, front-loaded with the core action, and the Args block adds necessary parameter context not present in the schema. No redundant sentences.
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?
The tool is simple with one parameter and no output schema; the description adequately states what it does and what it returns. However, it could further explain what happens on invalid credentials or how the returned access level should be used, but this is not critical for basic invocation.
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 schema provides only 'api_key' as a string with no description (0% coverage). The description compensates by explaining that this is the WARN Firehose API key and adding the 'wf_' prefix constraint, giving the agent actionable validation information.
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 states the tool authenticates using the WARN Firehose API key and returns the user's tier and access level. This specific verb and resource distinguish it from the sibling data-retrieval tools.
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 doesn't explicitly name alternatives or exclusions, but its unique role as the only authentication tool among data-focused siblings makes its usage context clear. It implies that authentication is needed to obtain tier and access level, which can inform subsequent data calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_recordsAInspectExport WARN records in bulk. Requires Pro tier or higher.
Returns up to 500 records with full field details. For CSV/Parquet
downloads, use the REST API at /api/export/.
Get your API key at warnfirehose.com/account
Args:
api_key: Your WARN Firehose API key (Pro tier required)
state: Optional 2-letter state code filter
company: Optional company name filter (partial match)
days: Look back this many days (default 90, max 730)
limit: Max records to return (default 100, max 500)
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No | ||
| state | No | ||
| api_key | Yes | ||
| company | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses key behavioral details: requires Pro tier, returns up to 500 records, includes full field details, and specifies parameter defaults (days=90, limit=100) and maximums (days max 730, limit max 500). It also mentions the API key requirement. This goes beyond minimal transparency, though it doesn't detail error handling or response format beyond 'full field details.'
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 well-structured, front-loading the purpose, then requirements, behavior, alternative method, and an organized Args list. It includes a redundant mention of the API key in two places and a URL that could be trimmed, but overall every sentence serves a purpose and the format is clear.
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 annotations, no output schema, and simple parameters, the description covers purpose, all parameters, limits, auth requirements, and an alternative download path. It states return details ('up to 500 records with full field details') but doesn't enumerate fields or describe error cases. For a straightforward export tool, this is largely complete, though slightly more detail on response structure would elevate it.
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 0%, so the description must explain all parameters. It does so thoroughly: api_key (purpose and tier), state (2-letter filter), company (partial match), days (lookback with default/max), and limit (max records). This adds significant meaning beyond the bare schema property names and types, fully compensating for the lack of schema descriptions.
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 states the tool's function: 'Export WARN records in bulk.' The verb 'export' and resource 'WARN records' are specific, and the bulk nature distinguishes it from tools like search_layoffs or get_recent_layoffs. The purpose is unambiguous and well-differentiated.
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 implies usage for bulk exports and notes an alternative for CSV/Parquet downloads via the REST API, but it does not explicitly contrast this tool with sibling tools. It mentions the Pro tier requirement, but lacks direct guidance on when to choose this over search_layoffs or get_state_summary. The REST API alternative is useful but not a sibling-tool comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_company_layoffsAInspectGet all WARN Act layoff notices for a specific company.
Args:
company: Company name to search for (partial match supported)
api_key: Optional API key for higher rate limits
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| company | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It mentions partial matching and the optional API key for higher rate limits, but does not discuss pagination, default time range, required authentication, or read-only nature. This is moderate disclosure, leaving some gaps.
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 a concise two-sentence docstring, front-loading the main purpose and using an Args block for parameter details. Every sentence adds value with no wasted words.
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?
Given the existence of sibling tools like search_layoffs and get_recent_layoffs, the description lacks guidance on when to use this tool specifically. However, the output schema exists and parameters are simple, so it satisfies the basic need but is not fully complete for selection among siblings.
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 description adds meaning to both parameters: company includes partial match behavior, and api_key explains its purpose (higher rate limits). Since the schema has 0% description coverage, this fully compensates and goes beyond the bare titles.
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 states the tool fetches all WARN Act layoff notices for a specific company, with partial match support. This differentiates it from sibling tools like get_recent_layoffs and search_layoffs by specifying a company-scoped resource.
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 implies use for company-specific queries by stating 'for a specific company' and partial match support, but does not explicitly address when to choose this over alternatives like search_layoffs or get_recent_layoffs, nor provide exclusion criteria. This is implied usage rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_pulseAInspectGet a single-call market snapshot across all 6 datasets.
Returns: WARN stats (30d trend), top industries, at-risk companies,
LCA/H-1B counts, DOL claims, SEC filings, bankruptcies, JOLTS snapshot.
Args:
api_key: Optional API key for higher rate limits
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses rate-limit behavior via 'Optional API key for higher rate limits' and lists return contents, but does not explicitly state read-only behavior or other side effects/caveats.
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 compact and front-loaded with the core purpose, followed by a structured Returns list and an Args section. Every line contributes value without redundancy.
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?
The tool is a broad aggregate with an output schema present, so the description's Returns list sufficiently covers what to expect. It lacks explicit authentication requirements or limitations, but the optional api_key line partially addresses access concerns.
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 schema has no descriptions for api_key (0% coverage), but the description compensates by explaining its purpose: 'Optional API key for higher rate limits.' This adds meaningful context beyond the schema's type and default.
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 starts with 'Get a single-call market snapshot across all 6 datasets,' which identifies a specific verb and resource. The Returns list further distinguishes it from narrower sibling tools like get_company_layoffs or get_state_intelligence.
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?
Usage is implied by 'single-call market snapshot' and 'across all 6 datasets' — it's positioned as the comprehensive overview tool. However, it does not explicitly state when to use it over alternatives or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pricingAInspectReturn WARN Firehose pricing tiers, included tools, and signup URLs.
Use this when the user asks about pricing, hits a rate limit, or wants to upgrade. Returns tier prices, daily call limits, included datasets, and direct signup links so the user can act immediately.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It frames the tool as read-only ('Return') and enumerates output items, implying no side effects. It could add notes on data freshness or authentication, but the zero-parameter informational nature makes this adequate.
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, each earning its place: front-loaded purpose, explicit use cases, and a clear list of return content. No redundant or vague wording.
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?
This is a low-complexity tool with no input parameters and no output schema. The description fully covers what it does, when to use it, and what it returns, making it complete for an agent to select and invoke.
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 has zero parameters, so the baseline is 4. The description adds context about what the tool returns, which is unnecessary for parameter semantics but harmless. The schema coverage is effectively complete (100%).
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 uses a specific verb, 'Return', and identifies the exact resource: 'WARN Firehose pricing tiers, included tools, and signup URLs.' This clearly distinguishes it from all data-focused sibling tools.
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 explicitly states when to use the tool: 'when the user asks about pricing, hits a rate limit, or wants to upgrade.' It does not mention when not to use it or name alternatives, but the use cases are very clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recent_layoffsAInspectGet the most recent WARN Act layoff notices.
Args:
days: Look back this many days (default 30)
state: Optional state filter (2-letter code)
limit: Max results (default 25, max 100)
api_key: Optional API key for higher rate limits
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No | ||
| state | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses parameter defaults, state format, limit constraints, and the role of api_key in raising rate limits, which is useful operational context. However, it does not explicitly state this is a read-only operation, nor does it mention response ordering, error behavior, or any prerequisites beyond the optional API key.
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 concise and well-structured: a single front-loaded purpose sentence followed by a bullet-point argument list. Every sentence provides useful information without verbosity or redundancy, making it easy to scan and parse.
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?
The description is adequate for typical usage, covering all parameters, defaults, and constraints. However, it omits mention of response contents (though an output schema exists) and does not explicitly state the operation is read-only. It also lacks any pointer to sibling tools for alternative use cases, which would have made the context more complete.
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 schema has no parameter descriptions, so the description must add meaning. It does so thoroughly: 'days' defines the lookback period with a default, 'state' specifies the format (2-letter code), 'limit' states max and default, and 'api_key' explains its purpose. All four parameters are clearly explained, significantly exceeding what the schema provides.
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 states the tool retrieves 'the most recent WARN Act layoff notices,' which is a specific action and resource. It distinguishes itself from sibling tools like get_company_layoffs (company-specific) and search_layoffs (broader search) by its focus on recent notices. The purpose is unambiguous and differentiates well.
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 provides no explicit guidance on when to use this tool versus alternatives such as search_layoffs or get_company_layoffs. While the phrase 'most recent' hints at a time-sensitive use case, there is no stated exclusion or comparison, leaving the agent to infer the intended usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_risk_signalAInspectGet companies ranked by composite distress signal across all datasets.
Combines WARN layoff volume/recency, SEC restructuring filings,
bankruptcy filings, and H-1B denial rates into a single risk score.
Levels: Critical (7+), Elevated (4-6), Moderate (2-3), Low (1).
Requires Starter tier or higher. Get your API key at warnfirehose.com/account
Args:
state: Optional 2-letter state code to filter
min_score: Minimum risk score (default 3)
limit: Max results (default 15, max 50)
api_key: Your WARN Firehose API key (Starter tier required)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| state | No | ||
| api_key | No | ||
| min_score | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently mentions the required Starter tier, the need for an API key, and the risk level thresholds. It does not cover error handling or pagination, but provides meaningful context beyond a simple 'get' operation.
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 well-structured, starting with the core purpose, then data sources, risk levels, auth note, and a clean arg list. It is slightly verbose with the API key URL but every sentence contributes useful information. The arg list is logically formatted.
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?
The description covers the tool's purpose, composite scoring methodology, risk levels, authentication requirements, and all input parameters. Since an output schema exists, not explaining return values is acceptable. It lacks details on potential errors or sort order, but for a scoring tool this is reasonably complete.
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 0%, but the description fully compensates by documenting all four parameters with clear meanings and defaults: state (2-letter code), min_score (minimum risk score), limit (max results with max 50), and api_key (required tier). This adds substantial value beyond the bare schema.
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 states a specific verb and resource: 'Get companies ranked by composite distress signal across all datasets.' It clearly distinguishes this from siblings by explaining it combines WARN layoffs, SEC filings, bankruptcy filings, and H-1B denial rates into a single risk score, which is unique among the listed tools.
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 provides clear context on what the tool does and its data sources, making it easy to infer when to use it. However, it does not explicitly mention alternatives or exclusions, such as 'use get_recent_layoffs for raw layoff data instead.' It falls short of the explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_state_intelligenceAInspectGet a unified state profile combining all 6 datasets for a US state.
Returns WARN notices, LCA petitions, H-1B approvals/denials, DOL claims,
bankruptcy matches, JOLTS data, and a composite distress score.
Requires Pro tier or higher. Get your API key at warnfirehose.com/account
Args:
state_code: Two-letter state abbreviation (e.g. CA, TX, NY)
api_key: Your WARN Firehose API key (Pro tier required)
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| state_code | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that Pro tier is required and enumerates the returned data categories, which is useful. However, it does not mention rate limits, error handling, or behavior on invalid state codes, leaving some operational uncertainty for a first-time 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 concise and well-structured. It front-loads the main purpose in the first sentence, then lists the return data, requirement, and parameters in a logical order. Every sentence contributes information without redundancy or fluff.
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?
The description covers the tool's scope, required access level, and return contents. Since an output schema exists, detailed return value documentation is available elsewhere. It could mention error handling, but for a data retrieval tool with a clear data list and access requirement, the description is sufficiently complete.
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 schema provides no parameter descriptions (0% coverage), so the description must compensate. The Args section explains state_code as 'Two-letter state abbreviation' with examples, and api_key as the user's API key with a Pro tier note, adding meaning to both parameters. A minor ambiguity remains because api_key is optional in the schema but implied as necessary; still, the description significantly enhances schema semantics.
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 states the tool's function: 'Get a unified state profile combining all 6 datasets for a US state.' It lists the specific datasets included, making it distinct from sibling tools like get_state_summary. The verb 'Get' and resource 'state profile' are specific and unambiguous.
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 Pro tier requirement and provides an API key link, giving clear context on prerequisites. However, it does not explicitly say when to use this tool versus alternatives like get_state_summary or get_market_pulse. Usage is implied by the 'unified state profile' phrase, but no exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_state_summaryAInspectGet a summary of WARN Act layoff data for a specific US state.
Args:
state: Two-letter state code (e.g. CA, TX, NY, FL)
api_key: Optional API key for higher rate limits
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of disclosing behavior. It only mentions that api_key is optional for 'higher rate limits' but does not disclose whether the operation is read-only, requires authentication, handles invalid states, or what errors may occur. This is insufficient for a tool with no annotation support.
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 concise and front-loaded with a clear verb and resource. The Args block efficiently documents both parameters without unnecessary text. Every sentence serves a purpose.
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?
Given the tool's simplicity and the presence of an output schema, the description covers the essential parameters and purpose. However, it lacks guidance on when to choose this tool over similar siblings and does not mention authentication prerequisites, making it slightly incomplete for an agent operating in a broader toolset.
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 description adds meaningful context beyond the schema by explaining that state is a two-letter code with examples (CA, TX, NY, FL) and that api_key is optional for higher rate limits. This compensates for the 0% schema description coverage, though it could provide more detail on accepted formats or validation.
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 states the tool's function: 'Get a summary of WARN Act layoff data for a specific US state.' It specifies the verb (get), the resource (summary of WARN Act layoff data), and the scope (specific US state), which distinguishes it from siblings like get_state_intelligence or get_recent_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?
The description implies the tool is for state-level summary data but does not explicitly state when to use it over alternatives like get_state_intelligence or search_layoffs. There is no mention of when not to use it or which scenarios favor this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_statsCInspectGet overall statistics about the WARN Firehose database.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of transparency. The verb 'Get' implies a read-only operation, but the description omits authentication requirements (despite the api_key parameter), any caveats about data coverage, or what kind of statistics are returned.
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 one concise, front-loaded sentence with no filler. It loses a point because its brevity results in under-specification rather than efficient completeness.
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?
The tool has low complexity (one optional parameter) and an output schema exists, so the description does not need to explain return values. However, the lack of parameter semantics and usage guidance makes it minimally adequate but not contextually complete for an agent choosing among many sibling tools.
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 0%, and the description does not mention the api_key parameter at all. Since there is only one parameter, the description should explain whether it is required for authentication or how it affects the results; it does neither.
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 states a specific action ('Get') and resource ('overall statistics about the WARN Firehose database'). However, it does not differentiate this from siblings like get_state_summary or get_market_pulse, which also appear to provide aggregate views.
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?
There is no guidance on when to use this tool versus the sibling tools. The phrase 'overall statistics' implies an aggregate use case, but no explicit context, prerequisites, or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_talent_pipelineAInspectFind available talent from recent layoffs, cross-referenced with LCA visa roles.
Shows what occupations/skills each laid-off company was hiring for.
Useful for recruiters targeting skilled workers from recently laid-off companies.
Requires Starter tier or higher. Get your API key at warnfirehose.com/account
Args:
state: Optional 2-letter state code
days: Look back this many days (default 90)
limit: Max results (default 15, max 50)
api_key: Your WARN Firehose API key (Starter tier required)
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No | ||
| state | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the API key requirement and Starter tier, which is helpful for authentication. However, it does not mention rate limits, read-only nature, or error behavior, leaving some transparency gaps.
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 efficiently structured with an intro, use case, requirement, and args block. Each sentence earns its place, though the API key URL could be considered slightly verbose. Overall, it is concise and well-organized.
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?
Given the presence of an output schema and 4 parameters, the description covers purpose, usage, authentication, and parameters. It does not explain return values, but the output schema likely does. Minor gap: no explanation of what 'cross-referenced with LCA visa roles' means operationally, but overall complete.
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 schema has minimal descriptions (0% coverage), but the description's Args section explains each parameter: state as a 2-letter code, days as lookback, limit with max 50, and api_key with tier requirement. This adds meaning beyond the schema's default values and types.
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 states the tool's purpose: 'Find available talent from recent layoffs, cross-referenced with LCA visa roles' and explains it shows 'what occupations/skills each laid-off company was hiring for.' This specific verb+resource combination distinguishes it from siblings like get_recent_layoffs or get_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?
The description provides clear usage context: 'Useful for recruiters targeting skilled workers from recently laid-off companies.' It does not explicitly mention alternatives or when-not-to-use, but the use case is specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_layoffsAInspectSearch WARN Act layoff notices by company name, city, or keyword.
Args:
query: Search term (company name, city, etc.)
state: Optional 2-letter state code to filter (e.g. CA, TX, NY)
limit: Max results to return (default 20, max 100)
api_key: Optional API key for higher rate limits
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| state | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It mentions the limit cap (default 20, max 100) and that api_key enables higher rate limits, which is useful. However, it does not explain matching semantics (exact vs substring), whether results are sorted, or any authorization requirements beyond the optional api_key.
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 opens with a one-sentence summary followed by a concise, well-labeled argument list. Every line adds value with no redundancy, and the structure makes it easy to parse.
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?
The description covers all parameters and the core purpose, and an output schema exists so return values are handled. However, it does not mention how this tool relates to siblings or any potential limitations (e.g., data coverage, result ordering), leaving minor gaps for a search tool.
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 0%, and the description compensates fully by explaining each parameter: query (search term), state (optional filter with examples), limit (max results), and api_key (rate limits). This adds significant meaning beyond the raw schema.
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 states the tool searches WARN Act layoff notices by company name, city, or keyword, with a specific verb and resource. This distinguishes it from sibling tools like get_company_layoffs (exact company lookup) and get_recent_layoffs (recency-based listing) by emphasizing free-form search.
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 implies usage for broad keyword searches but does not explicitly state when to prefer this over siblings such as get_company_layoffs or get_recent_layoffs. It gives context on parameters but no clear when-to-use / when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!