rolefig

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive behavior, so the safety profile is covered. The description adds real behavioral value not present in the schema: it discloses the return content ('blocking errors, recommended fixes and a summary per posting') and a key negative ('never the page itself'), which matters because there is no output schema. It omits fetch/auth/privacy caveats for the `url` mode, keeping it below a 5.

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?

Two sentences, no filler, and the core purpose plus validation target are front-loaded before the input-mode detail. Every clause carries 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?

With no output schema, the description correctly compensates by summarizing the return shape (errors, fixes, summary) and its exclusion of page content. Parameter semantics are fully covered, but behavior when both inputs are provided, or on fetch failure of `url`, is not addressed.

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 carry parameter meaning, and it does: `html` accepts page HTML or JSON-LD, `url` accepts a public page address. That clarifies both parameters and the either/or usage implied by zero required fields, though it doesn't address whether both may be supplied simultaneously or how conflicts are resolved.

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 ('Check') and resource ('a job post's schema.org JobPosting markup') and names the external authority it validates against ('Google's job search rules'). This is clearly distinguishable from siblings like get_job, search_jobs, or check_pay_transparency.

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?

Explains the two input modes ('Pass the page HTML or JSON-LD as `html`, or a public page address as `url`'), which is genuine usage guidance for choosing how to call it. It does not, however, state when to prefer this over siblings such as check_pay_transparency or get_job, so it stops short of explicit when/when-not routing.

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 establish readOnly, idempotent, non-destructive, closed-world behavior, so the description only needs to add context beyond that. It does: it discloses data freshness ('table checked 2026-10-05'), the full shape of what is returned (applicable laws, what the post shows, what may be missing, official sources), and an explicit scope boundary ('not legal advice').

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?

Two sentences, front-loaded with the core action before the input enumeration and the return/disclaimer clauses. The parenthetical enumerations are dense but each item adds real information, so nothing 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 correctly spends words on return contents and freshness, and it names a scope limit. It stops short of describing error or edge-case behavior (e.g., unmatched state, non-US posts) for a tool with three required inputs.

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 carry the parameter burden, and it largely does: 'the job's state, optional city or county, total employer size and remote status' maps onto state, place, employees, and remote, while the surrounding text implies text is the job post body. It still omits format expectations (e.g., whether state is a two-letter code or full name) for the required state parameter.

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 ('Check a US job post against state and city pay-range posting laws') and scopes it to US jurisdiction, so the purpose is unambiguous. It does not, however, differentiate itself from the sibling check_job_posting, which an agent could plausibly confuse it with.

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 the framing ('Check a US job post... for the job's state, optional city or county, total employer size and remote status'), which tells the agent what inputs to gather. There is no explicit when-to-use/when-not guidance and no mention of how it relates to the similar-sounding check_job_posting sibling.

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 annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds useful behavioral detail beyond annotations: overtime is paid at 1.5x and the `hour` unit blends base and overtime pay.

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?

Two dense sentences, front-loaded with the core operation and followed by critical calculation rules. Every sentence adds useful information with no 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?

The annotations cover safety and the description covers core conversion behavior, but with 6 parameters at 0% schema description coverage and no output schema, more detail is needed about schedule parameters and the return value. It is adequate for understanding the tool's purpose, but not fully sufficient for confident invocation across all inputs.

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 carry parameter meaning. It explains the unit values and mentions overtime hours, but it leaves daysPerWeek, hoursPerWeek, and weeksPerYear unexplained beyond the vague phrase 'stated schedule', and it does not clarify how those schedule parameters combine.

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 (Convert), resource (gross pay figure), and the full set of target units. It clearly distinguishes this pay-conversion utility from the job/company/resume siblings, so an agent can identify its purpose 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 clear context ('for a stated schedule') and an explicit scope exclusion ('Gross pay only: no taxes, benefits or deductions'), which tells the agent when this tool is not appropriate. It does not name alternative sibling tools, but no sibling performs pay conversion, so the practical guidance is strong.

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 readOnly/idempotent/non-destructive, so the bar is lower; the description still adds real value by disclosing that data is sent to 'rolefig' for remote formatting and that nothing is saved or submitted. It does not describe the shape of the returned resume text, which is the main remaining behavioral 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?

Three short sentences, scope constraint front-loaded, then exclusions, then the data-handling note. No filler, and each sentence changes how an agent would call the tool.

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?

No output schema exists, so the description should say what comes back; 'format into resume text' only gestures at it. Combined with seven undocumented required parameters, an agent knows the boundaries but not the input expectations or the return value.

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?

All 7 parameters are required with 0% schema description coverage, so the description carries the full burden and largely fails: it never explains what name, headline, summary, experience, skills, or education should contain or how they are formatted. Only the 'contact' field gets indirect guidance via the omit-contact-details sentence.

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 ('Format ... into resume text') and immediately bounds the scope with 'ONLY candidate-supplied facts'. No sibling tool formats resumes, and the description makes that distinct role obvious 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?

Gives clear usage conditions: format only supplied facts, omit contact details unless the candidate wants them included. It does not name an alternative tool or a when-not-to-use case, but no sibling performs comparable work, so the remaining guidance is adequate.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only the hint that the data is 'illustrative' with 'sample roles', which is mildly useful context about the nature of the content but does not disclose lookup failure behavior or scoping.

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 short sentence with no filler, front-loaded with the verb and resource. It is efficient, though its brevity comes partly from omitting needed detail rather than from tight editing.

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 and no annotations describing returns, the description should carry more of the burden: the meaning of 'slug', what a profile contains, and how it differs from published-company tools are all absent. The only completeness it offers is the vague 'sample roles' hint.

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 single required parameter 'slug' has no description in either place. The description says nothing about what a slug is, its format, or how to obtain one, so it fails to compensate for the schema gap.

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 verb (Read) and a resource (company profile, sample roles), so the basic purpose is legible. However, 'illustrative' is unexplained and the description does not distinguish this from the sibling get_published_company or get_job, leaving the agent to guess which company-reader applies.

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 when-to-use guidance, no prerequisites, and no mention of the alternatives (get_published_company, list_companies). The agent gets no routing signal for choosing among the several company-related siblings.

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, so safety is covered. The description adds genuinely useful behavioral context beyond them: the call returns a company profile as well as the posting, and applications on the demo record are closed. It says nothing about lookup failure behavior for a missing slug.

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?

Two short sentences, zero filler, and the resource is front-loaded before the caveat. Tight enough that nothing needs cutting, though it is arguably too terse given the undocumented parameter.

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 single-parameter read tool with annotations covering its safety profile and no output schema, the description covers return content adequately. The unexplained slug parameter is the main gap, leaving it minimally viable rather than 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% — 'slug' has only a type and maxLength, no description. The description does not compensate at all: it never explains what the slug identifies, where it comes from, or what happens on an unknown value.

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 concrete verb and resource: reads a job description plus its company profile, with the 'demo' qualifier flagging the dataset. It is distinguishable from get_company and search_jobs, but never names or contrasts with close siblings such as check_job_posting or list_company_openings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance and no alternative named. 'Applications are closed' is a domain caveat, not a routing condition, so an agent gets no help deciding between this and check_job_posting or list_company_openings.

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, non-destructive, and closed-world, so the safety profile is covered. The description adds genuine context beyond that: what fields are returned (source and application URLs), what is excluded (no applicant data, no submission), and a data-quality caveat that compensation text is authoritative while absent numeric pay/units are 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?

Three short sentences, front-loaded with the resource and scope before the caveats. The compensation-authority sentence is slightly tangential to tool selection but earns its place as a data-interpretation rule.

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 adequately conveys what is returned, what is excluded, and how to interpret the compensation field. The only real gap is any guidance on the slug parameter or when to prefer this over get_company.

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 one parameter (slug) with 0% schema description coverage, and the description never mentions it. The schema's regex pattern hints at a URL-style slug, but the description does nothing to compensate for the coverage gap, so an agent gets no added meaning from the prose.

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 ('Read') and resource ('a real company-published profile and its current published openings'), and the qualifier 'published' implicitly separates it from the sibling get_company. It never names get_company or list_published_companies explicitly, so sibling differentiation is left to inference.

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 scopes the tool ('no applicant data or application submission') and implies usage via 'company-published profile', but gives no explicit when-to-use condition or routing to alternatives such as get_company or list_published_companies. Usage is inferable but not stated.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds that results are public demo data and that role counts are included, which is genuine extra context, but it says nothing about pagination, result size, or whether the list is complete or truncated.

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?

One short, front-loaded sentence with no filler or repetition. It is efficient, though it may be under-specified rather than genuinely concise.

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?

Annotations carry the safety profile and there is no output schema, so the description need not explain returns, but the undocumented query parameter and the absence of any usage context leave real gaps for an agent choosing among many company-related 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 single 'query' parameter has 0% schema description coverage, and the description never mentions it at all. There is no indication of what the query string matches (company name? role? domain?) or what happens when it is empty (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?

States a specific verb ('List') and resource ('public demo company profiles and role counts'), and the 'public demo' qualifier loosely separates it from the published-company siblings. It stops short of naming the closest alternatives (list_published_companies, get_company), so an agent still has to infer which listing tool fits.

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 when-to-use statement, no prerequisites, and no mention of the alternatives among the ten sibling tools (list_published_companies, list_company_openings, get_company). The agent gets no routing guidance beyond the word 'demo'.

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, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description adds value beyond that: it discloses the result contents (application URLs, publication revision) and the filtering behavior (excludes drafts and closed jobs), plus reinforces the read-only boundary with 'Never submits an application'.

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?

Two tight sentences with no filler: the first states what is returned and scoped, the second states the two boundaries (what is excluded, what is never done). Fully front-loaded.

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 usefully names the return fields (application URLs, publication revision). For a single-parameter read-only listing, the remaining gap is minor: no mention of result size, ordering, or pagination behavior.

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?

Only one parameter with 0% schema description coverage, but the JSON Schema pattern already encodes the slug format (lowercase, hyphen-separated). The description contributes the semantic that it must be an existing company slug rather than a name or query string, which is real but modest added meaning.

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 ('Read') and resource ('current published openings'), constrains scope to a 'known company slug', and distinguishes itself from siblings like list_companies and search_jobs by being company-scoped and publication-status-filtered. An agent can tell what this returns 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 phrase 'for a known company slug' is a genuine precondition hint — it tells the agent it must already have a resolved slug (e.g., from list_companies) rather than a free-text query, which is what separates it from search_jobs. It does not explicitly name an alternative tool or a when-not condition, so it stops 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 declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely useful context beyond them: the result set is public company information only with no applicant data, and results are cursor-paginated.

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?

Two tight sentences, zero waste, with the core purpose front-loaded and the follow-up tool routing and data-scope caveat following in priority order.

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 usefully signals that the response carries a slug usable by other tools, and it bounds the data scope. The remaining gap is pagination semantics (how to obtain and reuse the cursor), which is only named, not explained.

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% for all three parameters, so the description must carry the load. 'search' implies what q does and 'cursor pagination' implies what after does, but nothing is said about limit, the cursor's opaque format, or default/maximum values.

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 ('Discover company-published profiles') plus the mechanism (search, cursor pagination), so the agent knows exactly what it returns. It stops short of explicitly differentiating from the sibling list_companies, leaving the published-vs-unpublished distinction to be inferred.

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 strong downstream guidance ('use the returned slug with get_published_company or list_company_openings'), which is implied usage for a discovery tool. However, it never says when to pick this over list_companies or when not to use it, so the selection guidance is incomplete.

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 read-only, idempotent, non-destructive behavior. The description adds two behavioral facts beyond annotations: pagination and that results are illustrative (not live offers). Pagination details (page size, offsets) are left to the 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?

Two short clauses front-loading purpose and filters, then pagination/disclaimer. No 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?

A read-only, 6-param search tool with no output schema. The description covers purpose, filter dimensions, pagination, and result nature. It could be more complete by noting that all results are non-live and pagination bounds, but overall adequate.

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 carry the load. It names the filter dimensions (keywords, company, work arrangement, minimum USD base salary) and clarifies currency/units for minSalary, which the bare schema does not. It does not clarify limit/offset semantics, but the names are conventional.

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 (search) and resource (roles) with inline scope of filters. The sibling get_job/get_company are single-entity lookups, so the plural search framing is distinguishable without opening schemas.

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 the filter list, but no explicit when-to-use guidance or alternatives are named. An agent could reasonably wonder whether check_job_posting or get_job is the better sibling for a specific role. No exclusions stated.

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