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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds two useful behavioral facts beyond that: it makes no network calls ('without touching the network') and it reuses the exact heuristics of the search filters, implying deterministic, consistent offline classification. It does not describe cost, caching, or category output shape, so it stays at a solid-but-not-rich 3.

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, front-loaded with the core action and constraint ('Judge one job title without touching the network'), followed by the rationale. Nothing is redundant and nothing is padded.

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 one-parameter classification tool with an output schema present, the description covers purpose, offline behavior, and the motivating use case. The only gap is that it does not hint at what the classification returns (categories/labels), which the output schema presumably handles, so remaining context is minor.

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 parameter and schema coverage is 100%, with the schema itself giving an example ('Senior MLOps Engineer'). The description adds no format, validation, or normalization guidance for the title string, so the baseline 3 for a fully-documented schema 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 states a specific verb and resource — judging a single job title — and adds that it 'exposes the same heuristics the search filters use,' which distinguishes it from the filtering siblings. It is clear what the tool does, though it never names the sibling it is a dry-run for (search_jobs/search_many), so differentiation is implied rather than explicit.

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 a use context — 'so a caller can see how a title will be treated before trusting a filtered search' — which tells the agent this is a pre-validation step. However, it names no alternative tools and states no when-not-to-use conditions, leaving the choice between this and the search tools largely to inference.

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

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

Annotations cover the safety profile (readOnlyHint, openWorldHint), and the description adds a genuinely non-obvious behavioral trait: results are memoized for the process lifetime, which tells the agent repeat calls may return cached data. It stops short of describing what happens on a miss or how many network sources are hit by default beyond the schema's own 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?

Three short sentences, front-loaded with the core purpose and each carrying weight — the LinkedIn/Greenhouse example clarifies return multiplicity and the caching sentence carries the only behavioral disclosure. Slightly more than strictly needed, but 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?

An output schema exists, so return shape needn't be explained, and the schema covers parameter formats. The remaining gap is edge-case behavior (no boards found, whether the check is exhaustive or best-effort), which is minor for this tool's 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?

Schema description coverage is 100%, so both parameters (company, sources) are already documented with formats and defaults in the schema. The description reinforces the multi-source reporting behavior but adds no new parameter-level syntax or constraint, matching the baseline 3.

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?

Specific verb+resource: 'Find which job boards carry a company's postings,' with the multi-source semantics made concrete via the Greenhouse/LinkedIn example. It does not name any sibling (e.g. source_status, search_jobs) to distinguish itself from, so it falls 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?

The description states what the tool does but never says when to reach for it versus siblings like search_jobs, search_many, or source_status. There are no prerequisites, no exclusions, and no alternative-routing guidance, leaving usage entirely to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and reach profile is covered. The description adds that the posting's body text is included (a useful content hint), but says nothing about failure modes for a bad job_id, cross-source behavior, or token/cost concerns of pulling full descriptions.

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 front-loaded clause with zero filler — the resource and its scope come first. It is arguably terse for a tool whose value is the full posting body, but 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 an output schema present, return values need not be enumerated, and the annotations cover the read-only/open-world profile. Combined with 100% schema coverage on three simple parameters, the only real omission is guidance on when to prefer this over a search call.

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 all three parameters are already documented (including the source-specific job_id format note). The description adds no parameter-level meaning beyond what the schema provides, which is the expected baseline when the schema carries the load.

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 ('one posting') and states the scope of the return ('Full detail ... including its description'), which distinguishes it from the list-oriented search_jobs/search_many siblings. It stops short of naming those siblings explicitly, so it is clear but not fully differentiated.

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

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

Usage is only implied: 'one posting' suggests fetching a single record after a search, and the schema reinforces this by telling the agent to take job_id/source from a search result. There is no explicit when-to-use statement or named alternative, so the agent must infer the 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 readOnlyHint=false, idempotentHint=true and openWorldHint=true, so safety/idempotency are covered. The description adds real behavioral value the annotations don't: values are verified before acceptance, so a bad token/host fails at registration rather than silently yielding empty results later.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded imperative with the trigger condition first, then the URL-extraction guidance and the verification rationale. Every sentence earns its place; 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?

An output schema exists, so return values need no explanation, and the description covers the genuinely tricky part (where the parameter values come from) plus validation behavior. Complete enough for correct invocation, though it doesn't say what happens after a successful registration.

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% (baseline 3), and the description goes beyond it by explaining how to derive the token/tenant/host/site values from careers URLs, with concrete Greenhouse and Workday URL shapes. That mapping is not in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb (pin/register) plus resource (board), with the scoping condition 'when discovery can't guess it' that separates it from the find_board sibling. An agent immediately knows this is the manual-fallback path for board registration.

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 it ('when discovery can't guess it'), which implicitly routes the agent to find_board first. It stops short of naming find_board or stating exclusions, but the trigger condition is 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 cover read-only and open-world safety, and the description adds meaningful behavior beyond that: sources are queried concurrently, empty sources silently contribute nothing, and a failing source surfaces in `errors` without discarding successful results. That partial-failure semantics is exactly the kind of context annotations cannot convey. It does not address rate limits or deduplication across boards.

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 with the core action front-loaded. The second sentence about per-source failures is useful rather than filler. Minor inefficiency: the 'contributes nothing' clause is somewhat redundant with the errors clause.

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 an output schema present, return values don't need explaining, and the annotations handle safety. The description covers concurrency, defaults, and partial-failure reporting, which is nearly everything an agent needs; it only omits deduplication, pagination, and rate-limit 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?

Schema description coverage is 100%, so all six parameters including sources, limit, and ai_ml_only are documented in the schema itself. The description adds no additional parameter meaning (e.g., how `query` matching works or board-name syntax), so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource with scope: 'Search one company's open roles across job boards.' The single-company scope implicitly contrasts with the multi-company sibling search_many, but that sibling is never named, so the differentiation is inferential rather than explicit.

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 context is implied by 'one company's open roles' and the note that sources default to greenhouse and workday. There is no explicit when-to-use/when-not guidance and no mention of when to prefer search_many, get_job, or classify_title as follow-ups.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true). The description adds genuinely non-derivable behavior: companies are searched sequentially so throttled sources pace themselves, and companies with no board hits land in `unresolved` rather than failing the batch. That failure semantics is useful context beyond the 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, front-loaded with the core action, followed by execution and error-handling specifics. Every sentence carries information; only slight tightening is possible (the throttling rationale could be one clause shorter).

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?

An output schema exists, so return-value explanation is not required, and the description is complete enough for a read-only batch search: it defines scope, execution model, and partial-failure handling. It could note source prerequisites but leaves nothing critical to guesswork.

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 fully documents all five parameters and the baseline is 3. The description adds nothing per-parameter beyond the schema, though it does clarify the `unresolved` output bucket, which is return-side rather than parameter-side.

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 with scope: "Search several companies and return one merged list." The word "several" signals the batch distinction versus a single-company search (e.g. the sibling search_jobs), but it never names a sibling 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 implied by "search several companies" – batch is the raison d'être – but there is no explicit when-to-use, when-not, or alternative named among search_jobs, find_board, or source_status. The agent must infer that this is the multi-company variant.

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 readOnlyHint, so the safety profile is covered. The description goes further by disclosing per-source reporting semantics: public boards always report available, LinkedIn surfaces reachability and throttle state, letting a caller distinguish 'not configured' from 'quota spent'. That is real behavioral context beyond the annotation.

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 what the tool reports, followed by the per-source detail. Every clause earns its place, though the second sentence is on the long side and could be tightened.

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 an output schema present, the description need not explain return values, yet it usefully characterizes the semantics of the reported statuses. For a zero-parameter diagnostic tool this is close to complete; only explicit usage framing 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 tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify about inputs, and it correctly focuses on output semantics instead.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource and scope: it reports which sources are configured and remaining quota. It is clearly a diagnostic/status tool distinguishable from sibling search/board tools, though it never names a sibling to reinforce that contrast.

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 — a caller would use this to check configuration and quota, and the 'not configured' vs 'quota spent' distinction hints at the diagnostic use case. But there is no explicit when-to-use statement, no prerequisites, and no named alternative among the sibling tools.

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