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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the response includes required skills and salary text, but says nothing about the remaining return shape, error behavior for a stale/unknown id, or rate limits. Adequate given the annotation coverage, but not rich.

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 sentence that front-loads what the tool returns, then the provenance of the id, then the notable payload fields. No filler or restated 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 one-parameter read tool with no output schema, the description covers purpose, source of the id, and the two most decision-relevant return fields. Only the full response shape and id-miss behavior are unstated, which is a minor gap.

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?

One parameter at 100% schema description coverage, with the schema itself giving the format and an example ('remotive:1923456'). The description adds no syntax or format detail beyond the schema, so the baseline of 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?

Names the resource (a posting's full description) and the exact payload it returns — skills and salary text. It also names the sibling tools that produce the ids it consumes (search_jobs, rank_jobs_for_me, market_snapshot), which cleanly separates it from those list-level 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?

By tying the tool to ids 'returned by search_jobs, rank_jobs_for_me or market_snapshot', it makes the usage context clear: call this after a search to expand a specific posting. It stops short of explicit when-not-to-use guidance or naming an alternative for bulk retrieval, so it is not 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?

The annotations already establish that this is a read-only, non-open-world operation. The description adds useful behavioral context by stating that the result covers both available job boards and which ones need configuration via API keys, though it does not describe output format in 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?

It is a single compact fragment with no wasted words. The key information — available sources and configuration status — is 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?

For a simple, zero-parameter, read-only listing tool, the description covers the essential output content and is supported by annotations that clarify safety. It could be slightly stronger by indicating the shape of the returned list, but no output schema exists and the description is largely sufficient.

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?

This tool takes zero parameters, so there is no parameter semantics for the description to explain. The baseline for a parameterless tool is 4, and nothing in the description misleads about inputs.

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 identifies the specific resource (job boards/sources) and what information is reported (availability and configuration needs). It is clear but omits an explicit verb and does not directly name or distinguish itself from the sibling job/market 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?

There is no explicit when-to-use guidance, no exclusions, and no mention of alternative tools. The content implies you call it when you need source availability or API-key configuration status, but the usage condition is left 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 and openWorldHint, so safety and external-fetch behaviour are covered. The description adds one genuine data-quality caveat – salary ranges only appear 'where postings publish them' – but says nothing about cost, latency, result limits, or what happens when the query matches nothing. Useful but thin 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?

Two sentences, front-loaded with what the summary contains, followed by a compact use-case cue. Every clause carries information (the enumerated outputs are the reason to pick this tool), though the output list is dense enough that it verges on a spec dump.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description correctly compensates by enumerating the returned aggregates, and it covers the primary call intents. Remaining gaps are minor: no mention of empty-result behaviour or how sources/location interact with the summary.

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% for all five parameters, so the input schema already documents query semantics, source selection, location handling, remote filtering, and the default 30-day window. The description adds no format or interaction detail beyond that, 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?

The description names a specific verb (summarise) and resource (a job-market search), and enumerates the aggregates produced: top skills with share, remote share, salary ranges, repeat hirers. It is clearly distinguishable from the list-oriented siblings (search_jobs, get_job) by implication, but never names them, so sibling differentiation is not 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 concrete when-to-use intents – 'what should I learn' and 'what does this role pay' – which tell an agent this is the aggregation tool rather than a posting browser. It offers no exclusions or named alternatives (e.g. 'use search_jobs when you need individual postings'), so it stops short of full 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 cover the safety profile (readOnlyHint, openWorldHint), so the bar is lower, and the description adds real behavioral context: results are ranked best-fit-first, each result carries matched and missing skills, and a summary aggregates the most commonly missing skills. With no output schema, this return-shape disclosure is genuinely valuable. It stops short of explaining scoring mechanics, board fan-out, or latency from external sources.

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, zero waste: purpose and ranking rule first, output shape second, input sourcing last. Nothing is repeated from the schema or annotations, and the most decision-relevant information is 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?

For a seven-parameter, open-world tool with no output schema, the description covers the essentials: what is scored, how results are ordered, and what each result and the summary contain. It leaves out scoring scale/interpretation (e.g. percentage vs ratio), behavior when no posting matches, and cross-board deduplication, which keeps it short of fully 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 100%, so the schema already documents all seven parameters, making 3 the baseline. The description adds only one piece of extra meaning, telling the agent to source the skills array from the user's CV/profile; the query, limit, sources, location, remote_only, and max_age_days semantics come entirely from 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?

The first sentence states a specific verb (score/rank) and resource (job postings) with the ranking criterion (share of requested skills the candidate already has) and ordering (best fit first). That ranking-by-skill-match semantic is inherently distinct from search_jobs or get_job, so an agent can tell what this tool uniquely does without opening any 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 closing line ('Pass the skills from the user's CV or profile') gives practical guidance on supplying the key input, which implies the usage context: you use this when you have a candidate skill set to match against. However, no alternative sibling (search_jobs, list_sources) is named and no when-not condition is stated, so usage is only implied rather than spelled out.

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 and openWorldHint, so the safety profile is covered. The description adds real value by enumerating returned fields (company, location, remote status, salary when published, skills) and that results are time-ordered newest-first, but omits cross-board de-duplication behavior, pagination, and what happens when a source is unconfigured.

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 with no filler, front-loaded on scope and sources. The second sentence earns its place because there is no output schema, so the return-field enumeration is the only place an agent can learn the response shape.

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 describing the return payload and ordering, and the fully documented six-parameter schema covers input. Remaining gaps are minor: no statement on de-duplication across the four boards or on behavior when no source matches.

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% for all six parameters, so the schema already carries defaults, bounds and enum values. The description contributes nothing extra about parameter syntax or interaction (e.g. how location interacts with remote_only); baseline 3 applies when the schema does the heavy lifting.

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 (tech job postings) with an explicit aggregation scope across four named boards, and links the result to the get_job sibling. It stops short of contrasting itself with rank_jobs_for_me or market_snapshot, which also operate on job data, so an agent still has to infer the boundary.

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 rather than stated: the breadth of the query and the note that results carry 'an id for get_job' hints at the search-then-fetch workflow. There is no explicit when-to-use or when-not-to-use, and no pointer to rank_jobs_for_me for ranked results or list_sources for board configuration.

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