Resume Booster Job Board

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

Annotations already establish readOnly, idempotent, openWorld, and non-destructive behavior. The description adds useful context beyond annotations by enumerating the statuses returned and disclosing the auth requirement ('Needs a key or a sign-in'), which is material for invocation.

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 short sentences with no filler. The core meaning—what statuses are included—is front-loaded, and the auth note is an essential second sentence.

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 low parameter count, rich annotations, and existing output schema, the description provides the key information an agent needs: what data is shown and that authentication is required. It stops short of explicitly steering the agent away from sibling tools, but the scope is clear enough for most cases.

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?

There is only one optional parameter, limit, and schema description coverage is 100%, so the schema fully documents it. The description adds no additional meaning about parameter syntax, defaults, or constraints beyond what the schema already 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 identifies the resource as the status of applications requested by the key owner's agent, and lists the possible statuses. It is distinguishable from sibling tools like request_application and key_status, though it lacks an explicit verb such as 'retrieves' or 'returns'.

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 when to use this tool—when checking the status of requested applications—and notes the auth prerequisite. However, it does not explicitly contrast it with alternatives like key_status or request_application, so an agent must infer the right context.

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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, and the description adds valuable behavior beyond these: it is served from cache, cheap to call, includes a freshness stamp, and behaves differently without a key by returning a withKey block. This gives an agent a realistic expectation of cost, freshness, and auth-dependent output.

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 single dense, information-rich sentence with no filler. Every clause adds meaningful guidance: cache-backed, cheap, specific metrics, board-vs-employer disambiguation, freshness stamp, and keyless behavior. The key facts are front-loaded and the length is appropriate for the content.

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 zero-parameter tool with an output schema available, the description is complete. It covers the data scope, the source and cost profile, the keyless mode, and the presence of a freshness stamp. There are no missing prerequisites, inputs, or behavioral caveats that an agent would need to invoke 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 has zero parameters and the schema confirms this, so parameter semantics are trivially complete. The description does not need to explain any parameter meaning and does not attempt to. A baseline of 4 is appropriate for a parameterless tool.

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 with a clear resource: 'Live board statistics from cache' and enumerates exactly what is included (posting totals, board counts, category set, freshness stamp). It also disambiguates 'boards, not employers' to prevent a common misinterpretation. This clearly distinguishes board_stats from the sibling employer-oriented stats 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 gives practical usage context: it is 'cheap to call' and serves data from cache, implying it is appropriate for quick or repeated statistics lookups. It also clarifies that it 'answers with no key too,' which helps an agent know it works without authentication. It does not explicitly name alternative tools or exclusion conditions, but for a zero-parameter read-only stats tool this is sufficiently clear.

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?

Beyond the annotations, the description adds useful behavioral context: non-supported systems still return the direct applyUrl for human use, the tool answers about the job rather than the key, and authentication is required. These details are not redundant with the readOnlyHint/idempotentHint/destructiveHint 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?

Three sentences, each earning its place: main purpose, fallback behavior, and alternative-tool routing plus prerequisite. The key scope differentiation is front-loaded and the entire description is free of filler.

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 a rich annotation set and an output schema present, the description covers what is needed to invoke the tool correctly: purpose, scope, job-vs-key distinction, fallback behavior, and authentication requirement. Nothing essential is missing for this level of complexity.

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 description for the single 'id' parameter, so the description must compensate. The text makes clear that the id refers to the job being checked ('this job'), especially by contrasting with key_status. It does not explicitly state the id's source or format, but for a single-parameter check tool, this is sufficient.

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 that the tool determines whether the apply agent can submit an application for a specific job on the user's behalf, and explicitly distinguishes it from key_status by noting this tool answers about the job, not the key. This gives a specific verb, resource, and scope that separates it from 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?

The description explicitly tells the agent when to use key_status instead: 'For whether THIS KEY may apply at all, call key_status.' It also clarifies the tool's scope and prerequisite ('Needs a key or a sign-in'), making the usage context unambiguous.

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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds crucial behavioral context beyond these: it reads the board's index rather than the employer's live site, and it is explicitly a weaker test than get_job. This informs the agent of the tool's limitations and the need to check the `basis` field, which annotations alone cannot convey.

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 and front-loaded with the core purpose, but it is slightly verbose. The phrase 'instead of spending a metered get_job per posting' is valuable guidance but could be integrated more compactly. Overall, it earns its place with no fluff, but a tighter phrasing would push it to 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?

The description covers the return format (open:{id:boolean} plus closed ids and basis), the caveat about basis, the prerequisite key/sign-in, and the tool's relationship to get_job. With an output schema present, it still provides essential behavioral context. Nothing an agent needs to decide when and how to call it correctly 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 input schema already provides a description for the `ids` parameter (from search_jobs, max 200, notChecked behavior) and has 100% schema description coverage. The description restates the 200-id limit but adds no new semantic detail beyond what the schema specifies. Per the rubric, with high schema coverage, baseline 3 is appropriate.

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 direct question and a clear statement of what the tool does: 'Are these postings still on the board? Answers up to 200 ids in one call'. It identifies the resource (job postings) and the action (checking open status), and explicitly contrasts with the sibling get_job, making differentiation 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 provides explicit when-to-use guidance: 'the tool for re-verifying a saved shortlist before acting on it, instead of spending a metered get_job per posting.' It also flags a key caution: 'it is a weaker test than get_job's — read `basis` before reporting a posting as live to a person,' and states the prerequisite 'Needs a key or a sign-in.' This is thorough and actionable.

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 readOnlyHint, openWorldHint, and idempotentHint, but the description adds valuable behavioral context beyond those hints: it details what the response covers (route, timings, count basis, fallback, ignoredFilters) and adds an authentication requirement ('Needs a key or a sign-in') that is not in the annotations. This is rich, non-redundant disclosure.

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 few sentences, front-loaded with the core purpose and usage, then detailing outputs and constraints. It is longer than minimal but each clause adds necessary context for a diagnostic tool of this complexity. No redundancy or filler; structure is logical and scannable.

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 complexity (24 parameters), the presence of an output schema, and rich annotations, the description is complete. It covers purpose, usage triggers, output highlights, and the auth requirement. It does not repeat return-value details (handled by the output schema) and leaves no critical question unanswered for an agent deciding or invoking.

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%, so the schema already documents all 24 parameters thoroughly. The description only references 'same arguments as search_jobs' and does not add parameter-level meaning. Per the rubric, a baseline of 3 is appropriate when the schema carries full weight; the description neither improves nor worsens parameter clarity.

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 clear verb and resource: 'Explain WHY a search returns what it does' and then enumerates the specific diagnostic outputs (parsed query, applied/ignored filters, route, rankings, timings). It also names the sibling it is not by referencing search_jobs, so an agent can immediately distinguish the tool's scope.

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 explicitly states when to reach for this tool: 'Use this when a search returns surprising, empty, or mis-ranked results.' It also notes that it takes the same arguments as search_jobs, giving the agent a clear alternative and a precise trigger condition. No inference is needed.

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?

The description adds significant behavioral context beyond annotations. It explains that 'unknown' is a result when a reading couldn't be taken, and it details the exact business logic (thresholds, per-board scope, net roles served). This transparency helps the agent understand edge cases and the meaning of outputs.

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 dense with useful details but is somewhat long. It front-loads the main question and then provides necessary nuances. While every sentence adds value, the structure could be more scannable, e.g., with bullet-point style, but the prose is efficient overall.

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 complex with multiple conditions and edge cases (e.g., unknown_reason), and the description covers all critical aspects: thresholds, board vs. employer, net roles, and the meaning of unknown. The output schema likely details the return format, so return values need no explanation.

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 already provides a complete description for companyTokens (from job cards or search_jobs, up to 20). The description adds no additional parameter-specific insight beyond what the schema states, but since schema coverage is 100%, a baseline of 3 is appropriate.

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 answers the exact question 'Did this employer's board grow?' by defining the judgment criteria (more roles served, thresholds of 10, 4, and 25%, 21-day tracking). It clearly distinguishes itself from sibling tools like board_stats or employer_hiring_record by focusing on board growth versus other statistics.

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 says this tool 'never ranks employers' and that no list of growing employers exists, which clarifies when not to use it. It does not explicitly name alternative tools for ranking or listing, but the context about scope (per board, not summed) provides clear usage 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?

Beyond the readOnly/openWorld/idempotent annotations, the description discloses subtle non-obvious behaviors: re-lists are excluded from closed_90d, superseded_90d is a floor, dates are lower bounds, tracking_days is capped at 90, and a takedown is explicitly not a hire. It also explains the 'unknown' record semantics as an instrument limitation rather than an employer verdict, and details layoff_filing's sources, freshness, and scope. This is far more than the annotations alone convey and is consistent with them.

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 long, but the complexity of the data semantics justifies most of the length, and the core record fields are front-loaded before the caveats. Some repetition ('Every row carries...' and the 'no part of record or any verdict' clauses) makes it slightly denser than necessary, but every sentence carries real information.

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 complex tool with one parameter and an output schema, the description covers input limits, field semantics, unknown states, data sources, freshness, limitations about what a takedown means, and required authentication. It even names the complementary tool. Nothing essential for selecting or invoking the tool correctly is left unresolved.

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 only parameter, companyTokens, is already fully described in the schema with minItems, maxItems, and an example, and schema description coverage is 100%. The description reinforces 'up to 20 per call' and calls companyToken an employer handle, but it does not add materially new parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.

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 (an employer's record on this board) and enumerates the exact fields returned, from open_roles now through feed_total, so an agent knows precisely what the tool produces. It also distinguishes itself from employer_growth by positioning that tool as the other half of 'Actively hiring', which separates the two in purpose.

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 clearly says 'Pair with employer_growth for the other half of what the site calls Actively hiring', giving a concrete complementary alternative. It also explains when the data is meaningful (board-level, not headcount, not summed across boards), but it does not explicitly enumerate exclusions for sibling tools like board_stats or check_jobs_open.

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?

Beyond the annotations (readOnly, openWorld, idempotent), the description discloses important behavior for dead ids: it returns what the board knows (watched closure, aged-out stub, or not found) in text and metadata, never a stale card. This adds meaningful behavioral context not present in the annotations or 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?

The description is dense but well-structured: it leads with the alias relationship, specifies the exact I/O shape, explains dead-id behavior, and closes with routing guidance. Every sentence adds distinct value, though the density makes it slightly less scannable than a minimal two-sentence description.

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 alias tool, the description covers all necessary runtime knowledge: where the id comes from, the exact output structure and fields, behavior for dead ids, and when to use the alternative get_job. With annotations covering safety and an output schema present, nothing critical 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% for the single 'id' parameter, so the baseline is 3. The description merely repeats 'from search' without adding format constraints or additional semantics, though it does reinforce the required input source.

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 explicitly states this is an alias of get_job with a fixed input/output shape (one id in, {id,title,text,url,metadata} out), and distinguishes it from the sibling get_job by naming the specific client context (ChatGPT deep-research and company-knowledge connectors) and directing other clients to call get_job. An agent can immediately tell what this tool does and how it differs from 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 explicitly says when to use this alias (when you are one of the ChatGPT connector shapes), the input source (id from search), and when not to use it ('Any other client should call get_job'). This is clear routing guidance with a named alternative.

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?

The description adds substantial behavioral detail beyond the annotations: it discloses the PAID requirement and the in-band refusal for free keys, explains that a null fit indicates missing stored description, and mentions it returns the CV terms read. These details are not in the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) and enrich agent understanding. While it doesn't cover every edge case, it goes well beyond a bare statement, so a 4 is appropriate.

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 single dense paragraph but every sentence contributes meaningful information: the core behavior, payment constraints, null semantics, and retry guidance. It is front-loaded with the primary purpose and then elaborates. Though somewhat long, it avoids fluff and is well-structured. It could be trimmed slightly but is not verbose, earning a 4.

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 has 6 parameters and an output schema, the description covers the core logic but leaves gaps. It explains the main flow (read occupation, search, score) and the output hints (null fit, returned terms), but does not clarify how optional parameters like remote, country, and location influence the search. The presence of an output schema reduces the need to describe return format, but the lack of explanation for these optional parameters, combined with their missing schema descriptions, makes the overall definition incomplete for an agent to confidently use all features. Thus a 3.

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 only 50% (limit and resumeText have descriptions; query, remote, country, location do not). The description clarifies resumeText (reads occupation from it) and query (alternative to resumeText), and implies limit (up to 20 results). However, it does not explain the remote, country, and location parameters at all, leaving them undocumented in both schema and description. Since the coverage is low and the description does not fully compensate for the missing parameters, a 3 is reasonable.

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: 'Score a résumé against open jobs' and elaborates on the mechanism (reads occupation from resumeText or query, searches board, scores 0-100). This differentiates it from sibling tools like search or get_jobs by focusing on matching a CV to jobs, not merely retrieving or listing them. The verb 'score' and resource 'résumé against the board' are 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 provides clear context: it is intended 'for an agent holding a CV' and explains the prerequisite of a paid key or sign-in. It also implies a usage loop by stating it returns terms so the agent can retry with a query. However, it does not explicitly mention alternatives or when not to use it (e.g., when you just need a job list), though that is implicitly obvious from the purpose. This gives clear context without explicit exclusions, warranting a 4.

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 signal read-only, idempotent, non-destructive behavior. The description adds valuable context beyond those annotations: the exact output contents, the need for a key/sign-in, quota implications, and the fallback path to fetch when unauthenticated.

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 dense sentences, each earning its place. The main purpose is front-loaded, and quota/auth/fallback details are grouped 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?

For a simple one-parameter, read-only tool with an output schema, this description covers sources of the id, what the response contains, auth requirements, quota behavior, and alternatives. Nothing an agent needs to call it correctly 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 schema already fully documents the id parameter with an example. The description adds meaningful extra context by explaining that the argument is the same id found in resumobooster.work/jobs links and is shared with fetch, check_apply_support, and request_application.

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 full detail for one job id, including description text and feed confirmation time. It clearly distinguishes itself from get_jobs by focusing on a single id rather than many.

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?

Explicitly says when to use this tool (one job id), when to use the alternative instead (several ids -> get_jobs, saving quota), and what to do without auth (call fetch). This is actionable 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 already declare readOnly, idempotent, openWorld, and non-destructive hints. The description adds valuable context: auth requirement, graceful handling of dead ids with reason reporting, and the performance implication of includeDescription=false (no vendor fetch). This goes beyond what annotations provide.

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?

A single paragraph of three sentences, no filler. The purpose is front-loaded, and each sentence earns its place. Slightly dense but efficient; no structural waste.

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 modest complexity (2 params, output schema provided), the description covers purpose, differentiation, edge cases, and auth. It doesn't detail return structure, but that's adequately handled by the output schema. No critical missing information.

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. The description enriches both parameters: 'ids' are explained via the resilience behavior, and 'includeDescription' gets a usage nuance ('cards and freshness only, much smaller') that complements the schema's character cap note. It adds meaning beyond the schema's dry field 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 operation: 'Full detail for up to 10 job ids in ONE call' and explicitly frames it as 'the shortlist form of get_job', instantly distinguishing it from the sibling tool. The verb and resource are specific, and the scope is bounded.

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 when to use this tool (multiple job ids) versus get_job (single full description), and gives a concrete usage tip: 'Set includeDescription=false for cards and freshness only'. However, it does not explicitly state exclusions or prerequisites beyond 'Needs a key or a sign-in', so it stops short of full when-not 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 already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond that: counts include the current call, an Agent Pass starts at the first call other than this one, and it names specific blockers. This gives the agent meaningful behavioral detail.

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 dense but every clause adds relevant information, and the key purpose is front-loaded. It is somewhat run-on and hard to parse due to dashes and nested clauses, but there is no fluff or repetition beyond the title echo.

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 output schema exists, the description does not need to explain return values. It covers what the tool reports, when to call it, and access prerequisites. The main limitation is the awkward prose, which may make some details easy to miss, but nothing critical appears absent.

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 and schema coverage is 100%, so there is nothing to clarify. The description still notes access requirements (key or sign-in), which is useful but not parameter-specific. Baseline for zero-parameter tools is appropriately strong.

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 what the tool reports: the API key's tier, remaining requests and calls, whether fit_resume and apply tools would work, and blocker details. It differentiates itself from siblings like application_status and check_apply_support by focusing on the key itself rather than job or application state.

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 says to call it first in a keyed session and after quota/rate refusals. It does not discuss when not to use it or name alternatives, but the use case is clearly specified.

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?

Beyond annotations (which declare destructiveHint=true, readOnlyHint=false, etc.), the description discloses that every application passes the same gates as the signed-in flow including an honesty classifier, that answers are drawn from the owner's profile and never invented, and that it requires a key or sign-in. It also hints at consumption by mentioning key_status reports how many applications are left. This goes well beyond the 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?

The description is dense but every sentence carries essential information: the action, prerequisites, the need to call key_status, consent requirement, and the honesty classifier behavior. It's front-loaded with the action and then the required steps. Slightly long, but no filler; a 4 is warranted for being thorough without being verbose.

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 complexity (mutation, external effects, prerequisites), the description covers everything an agent needs: what to do first (key_status), what to confirm (consent), what resources are required (key/plan/pass/mandate), and the behavioral guarantees (honesty classifier, profile-based answers). With an output schema present, return format is not required. The description is complete for correct 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 already provides 100% coverage with descriptions for both parameters: jobId is 'The job id from search_jobs' and note is 'Optional note stored with the request (not sent to the employer).' The description doesn't add extra parameter-specific guidance (e.g., format or usage of jobId), but with full schema coverage, the baseline of 3 is appropriate.

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: 'Ask the board's apply agent to submit an application to this job on behalf of the key's owner.' This clearly distinguishes it from siblings like application_status or check_apply_support, which are read/check tools. The core action is 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 provides explicit pre-call steps: 'call key_status first' to determine missing prerequisites, and 'Ask the person for a yes on this specific job id before calling.' It also enumerates required conditions (key, active plan/pass, mandate), effectively telling the agent when and how to use the tool. It doesn't name alternatives but gives a clear workflow.

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/idempotent, and the description adds substantial context beyond them: the 10-row limit, equivalence of board/ranking to unkeyed search_jobs, the semantics of each result's id (usable by fetch and other tools) and url (employer apply page vs. site posting page), and that disclosures ride alongside results. This is rich behavioral disclosure, not a restatement of 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?

Four dense sentences, all front-loaded with the alias identity and shape before the result-semantics details. Each sentence carries distinct information with no filler, though the 'disclosures ride beside the results' clause is a bit compressed. Slightly verbose but appropriately sized for the alias relationship it must explain.

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-only tool with an output schema and safety annotations, the description covers the invocation contract well: alias relationship, result semantics, result limit, and routing guidance. The only under-specified element is what 'disclosures ride beside the results' actually refers to; auth and rate-limit context are also absent but appear to be handled at the connector level given the sibling set.

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 query parameter's schema description already explains the accepted free text ('title, skills, a place, exclusions with a leading minus'). The description reinforces that query is the only parameter but adds little semantic detail about the parameter itself — the 'no filters here' contrast mostly serves usage guidance rather than param semantics. Baseline 3 is appropriate.

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 (search over jobs via an alias of search_jobs), defines the exact I/O shape, and explicitly distinguishes itself from its richer sibling 'search_jobs which takes every filter.' An agent can tell exactly what this tool does and how it differs from the 14 siblings 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?

The description names the exact caller ('ChatGPT's deep-research and company-knowledge connectors'), states the limiting condition ('one query string in'), and gives an explicit alternative with the selection rule: 'Any other client should call search_jobs, which takes every filter.' When-to-use and when-not-to-use are both explicit.

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 non-destructive, so the description's extra detail is additive, not redundant. It discloses the 30-day freshness cap, parsed pay/experience fields so prose parsing is unnecessary, and honesty mechanics (countUnavailable when totals are unknowable, ignoredFilters, intentFilters, spelling suggestions). This gives an agent a realistic model of response behavior not inferable from schema alone.

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 three-sentence description is dense but each clause earns its place: core purpose and source, return-card content and honesty disclosures, and the agentReadyOnly flag. It is front-loaded with the search action before going into output details, and it avoids repeating the schema.

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 24-parameter tool with no required parameters, an output schema, and read-only annotations, the description supplies the missing operational context: data freshness, sourcing, strictness of filters (ignoredFilters/intentFilters), and the agent-ready subset. Nothing an agent needs in order to decide whether to call this tool is absent.

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%, so the baseline is 3 even with minimal parameter prose in the tool description. The description adds useful context for output fields like salaryMinAnnual/salaryMaxAnnual and agentReadyOnly, but it does not explain parameter values beyond what each schema property already says.

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, resource, and scope: 'Search the live job board', with source ('employers' own hiring systems') and a 30-day freshness cap. It also names the related sibling board_stats as the carrier of live totals, which helps an agent tell this tool apart from other board tools. The return-card and disclosure content further clarify exactly what this tool produces.

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 makes the use case clear: search the live job board and get compact job cards, with an agentReadyOnly flag for direct submittable jobs. It notes that board_stats carries live totals, a useful pointer to an alternative for aggregate numbers. It does not, however, explicitly contrast search_jobs with sibling search/get_jobs/debug_search.

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