NextChapter jobs, résumé and layoff help

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds genuinely new context: the data source (Anthropic Economic Index), that results are matched from a free-text title, and the important interpretive caveat that this is observed current use rather than a prediction. It omits how matching failure is signalled when a title can't be mapped to an occupation.

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?

It is front-loaded with the invocation trigger and example utterances, then the capability, then the caveat. The enumeration of return fields is a slightly long list, but each item tells the agent what it can offer the user, so the length is largely earned.

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 single-parameter read tool with no output schema, the description covers invocation conditions, data provenance, returned fields, and the main interpretive limitation. The only real gap is what happens when a job title cannot be matched to an occupation.

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?

With one parameter at 100% schema description coverage, the schema already carries the semantics, so the baseline is 3. The description adds only the hint that input is a plain job title that gets matched to an occupation, which implies some input tolerance but gives no detail about ambiguous or unmatched 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 states a specific resource and measurement: how much of a job's work AI is already used for, sourced from the Anthropic Economic Index, matched from a plain job title. That is clearly distinct from siblings like search_jobs or score_resume, so an agent can route on it without opening the 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?

It gives explicit trigger phrasing ("is my job safe from AI", "how exposed are accountants") and a clear scope boundary: it measures observed use now, not a forecast of job loss. It stops short of naming an alternative sibling such as find_career_guide for users who want general career information rather than exposure data.

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

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

Annotations already cover safety (readOnlyHint true, openWorldHint false), and the description adds the return shape: guide title, short answer and link, which matters because there is no output schema. It says nothing about result counts, ranking, or what happens when no guide matches, so behaviour on an empty result is unknown.

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?

Front-loads the trigger condition and example questions before the topic inventory, so the most decisive information comes first. The topic list is dense but earns its place as retrieval vocabulary; nothing is obviously redundant.

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 single-parameter lookup with no output schema, the description covers the trigger, the input form, and the return contents. The remaining gap is disambiguation from topical siblings such as unemployment_benefits_by_state and score_resume, which it never addresses.

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?

With one parameter at 100% schema coverage, the schema already explains the argument. The description's example phrasings largely duplicate the schema's own example ("how do I negotiate severance") and add no new syntax or formatting rules beyond confirming natural-language questions are expected.

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 ("Finds NextChapter’s plain-language guides on layoffs and job search") and enumerates the covered topics. The enumeration carves out a recognisable scope, but it also overlaps sibling territory ("unemployment", "resumes and ATS") without saying how it differs from unemployment_benefits_by_state or score_resume.

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?

Opens with an explicit trigger condition ("Call this when someone asks how to handle a job loss or job search") reinforced by three sample queries. It gives no when-not guidance or named alternatives, so the agent must infer boundaries from the topic list alone.

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

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

Annotations only declare readOnlyHint and openWorldHint=false; the description adds substantial behavior on top: results are limited to programs verified against their official page, programs restricted to a group or profession are deliberately excluded, and each record carries amount, eligibility, status, official link and last-checked date. That is exactly the kind of verification-provenance and exclusion logic an agent cannot infer from structured fields.

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?

Front-loaded with the trigger condition and example queries, then the return shape, then filtering guidance — a sensible order. It runs long for a single paragraph and mildly repeats the goal categories already listed in the enum (retraining, relocation), but no sentence is truly dead weight.

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?

There is no output schema, so the description properly takes on return-value explanation, specifying the fields per program and the state-plus-nationwide ordering. Combined with the 100%-covered input schema and read-only annotations, an agent has everything needed to call this 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?

Schema description coverage is 100% and the enum values are already documented in the schema, so the schema carries the parameter burden. The description adds only a thin gloss — "Filter by goal to ask for retraining or relocation funding" — and says nothing extra about state or limit behavior beyond what the schema states. Baseline 3 applies.

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 concrete trigger and verb ("Call this when someone who lost a job asks what help, money or programs exist") and enumerates the resource categories: health coverage, relocation money, retraining, tax credits, free courses. That is well beyond a restatement of the name. It stops short of 5 because it never distinguishes itself from the sibling unemployment_benefits_by_state, which an agent could easily confuse with this tool's "benefits" framing.

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 clear and illustrated with three realistic user phrasings ("what benefits can I get after a layoff", "is there money to retrain", "help to relocate for work"), and it explains the goal filter as the way to narrow scope. The gap is the absence of any exclusion or alternative routing — nothing says when to prefer unemployment_benefits_by_state or recent_layoff_notices instead.

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

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

Annotations already declare readOnly/openWorld=false, and the description adds real value beyond them: data provenance (state labor departments), ordering (newest first), an explicit data limitation ("it does not say why"), and a licensing/attribution obligation (CC BY 4.0 with link back) that the agent must honor when citing.

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?

Front-loads the call condition and folds the trigger examples into a single sentence, then moves to filters, record contents, and caveats. It is slightly dense and repeats the "what you can ask" idea twice, but no sentence is wasted.

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 enumerates the returned fields (employer, place, workers named, filing date, state record, NextChapter link), plus ordering and coverage limits. That is everything an agent needs to call it and to describe results accurately.

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%, so every parameter including limits and defaults is already documented. The description only restates the filter axes (employer, state, days back) and omits limit entirely, adding no syntax or matching semantics beyond the schema — the correct baseline when the schema does the work.

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 resource (WARN Act layoff notices from U.S. state labor departments) and what it does (query/filter newest-first). It is clearly distinct from siblings like layoffs-adjacent benefits tools and unemployment_benefits_by_state, since it is about employer filings, not worker benefits.

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?

Gives explicit trigger conditions with concrete user phrasings ("I was laid off", "is [company] laying people off?", "which employers filed notices in [state]"). It stops short of naming a sibling alternative or an explicit when-not-to-use, so routing against laid_off_benefits_and_programs or unemployment_benefits_by_state is left to inference.

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

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

Annotations already mark this read-only and closed-world, and the description stays consistent while adding substance the annotations cannot convey: deterministic fixed-rule scoring, per-check pass/partial/fail with observed evidence and exact fix, and that the text is scored once and not stored. That last point is a meaningful privacy signal an agent would otherwise have to guess.

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?

Front-loaded with the trigger condition, then outputs, then scope limits, then the follow-on action — a sensible order with little waste. The list of checks in parentheses is slightly compressed (eight items stand in for the eleven claimed checks), a minor density cost rather than padding.

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 return-value burden itself and does so: score scale, per-check verdicts, evidence plus fix, and determinism. It also covers the tool's main limitation and the privacy/data-retention behavior, leaving nothing an agent needs before calling 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 coverage is 100% and the single parameter is already documented with its plain-text format and 400–20,000 character bounds. The description's "Pass the résumé as plain text" restates the schema rather than extending it (no note on what happens with PDFs, markdown, or truncated pastes), so baseline 3 applies.

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 (score a résumé) plus the output shape: a score out of 100 across eleven fixed checks. No sibling tool touches résumés, and the description makes that boundary obvious without the agent opening the 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?

Gives concrete trigger phrases ("check my résumé", "will this get past applicant tracking systems") and an explicit exclusion: it cannot judge whether experience suits a role. It also tells the agent what to do with the result (use findings to rewrite the résumé), which is real routing guidance.

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

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

Annotations only declare readOnlyHint and openWorldHint=false, so the description carries the real burden and does: no login required, results ordered newest first, deduplicated source, and explicit exclusion of hourly/per-diem/internship roles. It also enumerates the returned fields, including derived signals like AI exposure and 12-month layoff notices, so the agent knows what to expect without an output schema.

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?

Front-loads the invocation trigger, then scope/exclusions, then return shape — a sensible order with no filler sentences. It runs long as a single dense block and could be split into when-to-use, scope, and returns for faster scanning, which keeps it from a 5.

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 read-only search with no output schema, the description covers everything an agent needs: eligibility trigger, data source, freshness ordering, exclusions, auth requirements, and the exact fields returned. Nothing material 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?

Schema coverage is 100%, so the baseline is 3 and the schema already documents all four parameters. The description adds value by showing how the filters combine in practice ('remote director roles', 'senior finance manager in Denver'), which demonstrates realistic query/level/remote/location usage beyond the field-level text.

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 (search current professional job openings) and immediately bounds scope: NextChapter's own deduplicated board, U.S. employers, newest first, hourly/per-diem/internship roles excluded. This is clearly distinguishable from siblings like recent_layoff_notices or ai_exposure_for_job_title, which are single-signal lookups rather than job listings.

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?

Gives explicit triggering conditions with three concrete example utterances spanning role, location, remote, and post-layoff intent, which is more than most defs offer. It lacks an explicit 'when not to use this / use X instead' routing line to a sibling, so it stops just short of a 5.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint=false), and the description adds genuinely new behavioral context: results are single-state, and every fact is accompanied by an official source and a checked-on date, which tells the agent how to cite and how fresh the data is. It does not state what happens for an unsupported state code or whether the response can be empty, which is the remaining gap.

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 trigger condition and examples are front-loaded before the content inventory, so an agent can decide quickly. Sentences are dense but each carries useful information; the trailing provenance sentence could arguably fold into the content list, which keeps it from a 5.

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 correctly carries the burden of describing returns by enumerating the response fields, and the annotations cover safety. What is missing is edge-case behavior (invalid or non-covered state codes, data unavailability), which matters for a one-parameter lookup tool but is a minor omission overall.

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 single 'state' parameter is fully documented in the schema with the two-letter format and an example. The description reinforces that the scope is one state but adds no new syntax or validation meaning beyond what the schema already supplies, so baseline 3 applies.

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 verb+resource ('Unemployment insurance basics for one U.S. state') and then enumerates exactly what comes back: agency and filing location, min/max weekly benefit, max weeks, waiting week, severance and pay-in-lieu-of-notice treatment, and the work-search rule. This is far more specific than the name alone and clearly separates it from generic job-search or resume siblings.

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 an explicit trigger ('Call this when someone asks about unemployment benefits after a layoff or job loss') plus two concrete example utterances, which is strong when-to-use guidance. It stops short of naming the closest sibling (laid_off_benefits_and_programs) or saying when this tool is NOT the right choice, so it lands just below the top band.

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