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

No annotations are provided, so the description carries the full behavioral burden. It discloses the radar prerequisite and summarizes the outputs, but it does not state whether the operation is read-only, what happens on failure, or any rate/latency constraints beyond the schema's with_news note.

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 action and outputs, with the prerequisite appended without excess. It does not waste space restating schema details.

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 convey return values; it does at a high level by naming ghost likelihood, competition chance, and supporting facts. Combined with full schema coverage and the radar prerequisite, it is mostly complete, though it omits failure and availability details.

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 schema already documents job, company, and with_news. The description adds no parameter-level meaning beyond saying it grades a job posting, so 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?

States a specific verb, "Grade," and resource, "job posting," and names the distinct outputs: ghost-job likelihood, competition chance, and supporting facts. This clearly differentiates it by function from the sibling detail and search tools, even without naming them.

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?

Provides a prerequisite that the radar must be running and implies the tool is for ghost-job assessment. However, it does not explicitly say when to choose it over get_linkedin_job_details or search_linkedin_jobs, nor when not to use it.

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?

With no annotations, the description carries the full burden, and it does usefully disclose the return payload (criteria fields, posted time, applicant count as shown publicly). It says nothing about failure behavior for an invalid or expired job id, whether the applicant count can be absent, scoping to public page data, or any auth/rate constraints.

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 a single front-loaded sentence with no filler, and the enumerated return fields are the most valuable part. The nested parenthetical and the trailing 'shown on the public job page' make it slightly dense but not wasteful.

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 lookup with no output schema, the description adequately covers what comes back, which is the main thing an agent needs. The remaining gap is error/edge-case behavior for unresolvable job identifiers, a minor omission given the tool's simplicity.

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 a single required 'job' parameter and schema coverage is 100%, with the schema itself documenting that it accepts a job id or a job URL. The description adds no extra meaning such as URL formats accepted or whether a slug-only URL works, 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 uses a specific verb ('Get') and enumerates the resource precisely: one job's full description, criteria (seniority, employment type, industries), posted time, and applicant count. The word 'one' plus 'full description' implicitly contrasts with search_linkedin_jobs, but no sibling is named explicitly, so it stops short of a 5.

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 only implied: an agent can infer this is the drill-down call after search_linkedin_jobs returns job ids, but the description never states when to use it, when not to, or why to prefer it over check_ghost_job. No prerequisites or alternate paths are given.

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?

With no annotations supplied, the description carries the full burden and does so: read-only, no sign-in required, request spacing, one-hour per-search caching, the 10-jobs-per-request latency cost, and the failure mode (success false plus error when LinkedIn rate-limits). It even documents the response fields despite no output schema existing.

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?

Structure is front-loaded: purpose first, then behavioral traits, then sibling routing. The long second sentence uses semicolons and colons densely but every clause carries distinct operational information, and nothing is repeated from the schema or title.

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 12-parameter, zero-required, mutation-free tool with no annotations and no output schema, the description supplies the return shape, failure behavior, latency model, caching semantics, and next-step tools. An agent has everything needed to call it correctly and to interpret a result.

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 city, geoId, page/limit, and the enum filters. The description still adds genuinely useful meaning beyond the schema by explaining that LinkedIn serves results in batches of 10 and that each batch costs roughly a second, which informs how to set limit and page.

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 opening line names a specific verb and resource ("Find open jobs on LinkedIn") and pins the default ordering ("newest first"). It is immediately distinguishable from the two siblings, which are named later with their distinct roles.

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 routes the agent explicitly: use get_linkedin_job_details on a returned jobUrl for descriptions/applicant counts, and check_ghost_job to verify a posting is real. That is clear alternate-tool guidance. It stops short of stating when not to use this tool at all (e.g., non-job searches), so it is short of a full 5.

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