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

Beyond the read-only and open-world annotations, it discloses the per-job charge to the caller's own Apify account, the per-call cost cap and its default, server-applied defaults, and the token-saving description behavior. It also identifies the exact external Apify actor and includes a non-affiliation notice.

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 purpose is front-loaded, and the remaining sentences cover operating modes, output tradeoffs, pricing, defaults, and implementation. The content is generally useful, but the dense single paragraph and duplication of schema details reduce scannability.

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, paid scraping tool, the description covers the essential source-selection modes, filtering, cost controls, description behavior, and backend, while the schema documents advanced monitoring and concurrency options. Because there is no output schema, it would be more complete with a brief overview of the returned job records or result structure.

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 19 parameters and the baseline is 3. The description usefully summarizes source selection, filters, includeDescription, maxCostUsd, and defaults, but most of this repeats structured parameter documentation rather than adding new constraints or syntax.

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 that the tool retrieves open jobs from companies using Ashby and identifies the jobs.ashbyhq.com board scope. This clearly distinguishes it from greenhouse_jobs, lever_jobs, workday_jobs, and broader job-search 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 gives concrete invocation paths: supply Ashby slugs, board URLs, or embedding careers pages, or set searchDirectory to true for directory-wide discovery. It also explains when to enable includeDescription, but does not explicitly route non-Ashby or general remote-job requests to sibling tools.

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 annotations already covering read-only, non-destructive, open-world behavior, the description adds valuable context: per-job cost, a maxCostUsd cap, token-saving defaults, and the upstream Apify Actor. It still does not describe return record shape or rate-limit behavior, so it is strong but not exhaustive.

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 front-loaded with purpose and usage, then covers filters, defaults, and cost. It is dense for a 34-parameter tool, and although a few filter mentions duplicate schema content, none are seriously 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 complex multi-ATS scraping tool, it supplies the key operational context: supported boards, usage condition, cost model, and default limits. It does not explain the output job record, but the annotations and full parameter schema carry much of the remaining burden.

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 input schema already carries the parameter meaning. The description mentions several filters and defaults, but mostly repeats what the schema says rather than adding new semantics.

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 ('Open jobs') and resource ('company career pages') and enumerates the supported ATS platforms. It also distinguishes the tool from single-ATS siblings by telling the agent to use it when there is a mix of companies or the ATS is unknown.

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 clear condition for use: mixed companies or unknown ATS. It implies, but does not explicitly name, the single-ATS alternatives such as greenhouse_jobs or lever_jobs, so the routing guidance is strong but not fully 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?

The description adds substantial context beyond the annotations: it discloses robots.txt discovery, sitemap-index traversal, .gz handling, the per-URL price ($0.0002) charged to the user's Apify account, the maxCostUsd cap, the maxTotalUrls=500 server default, and the backing Actor. The remaining gap is that it never mentions the default-mode run against the sample NASA sitemap when startUrls is omitted, which changes what an agent actually gets back.

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 opening sentence is front-loaded with the input-to-output contract, and cost/defaults/actor details are packed into short trailing sentences. It is dense for one paragraph but nearly every clause carries operational value; only the explicit Actor URL is arguably redundant.

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 14-parameter, zero-required tool with no output schema, the description covers the return fields, discovery mechanics, filtering, cost model, spend cap and key defaults, which is most of what an agent needs. It is incomplete only around the default startUrls sample run and around how results are returned (list, dataset, pagination).

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 every parameter already carries documentation, including the lastmodWithinDays-overrides-lastmodAfter precedence. The description adds only light reinforcement (regex nature of the patterns, lastmod-based filtering); it introduces no meaning not already in the schema, 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?

"Give a site ... or a direct sitemap.xml URL and get every listed URL with lastmod, changefreq and priority" names a specific verb, input form and returned fields. It is clearly distinguishable from sibling tools like extract_website_metadata or seo_audit_website, which operate on pages rather than sitemap discovery.

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?

"Use it to map a site's pages or find recently changed ones before crawling" gives a concrete when-to-use, and the include/exclude plus lastmod filter framing implies when a broader crawl tool would be needed instead. It stops short of naming an alternative sibling tool explicitly, so no exclusion guidance is provided.

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?

Goes well beyond the readOnly/openWorld/destructive annotations: it discloses the no-browser fetch method, robots.txt obedience, that failed URLs surface as free error rows, the exact pricing model ($0.001/URL, $0.00005 per Actor start) charged to the caller's Apify account, the default $0.25 cap, and the backing Actor. For a billed, external-network tool this is the information an agent needs before invoking.

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 with capability and return fields, then usage, then cost — a sensible priority order. It is dense and mostly earns its length, though the trailing Actor URL and the repeated default-charge figure are slightly redundant against 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?

With no output schema, the description explicitly enumerates the returned fields and the error-row behavior, so an agent knows what it gets back. Combined with pricing, cost ceiling, and failure handling, nothing material is missing for a six-parameter billed extraction tool.

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 all six parameters are already documented in the schema; the description's only parameter-touching sentence restates the maxCostUsd cap and default without adding new semantics. Baseline 3 applies since the schema does the parameter work.

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 ("Fetch a list of URLs") plus the exact return payload (title, meta description, canonical, language, OG/Twitter tags, JSON-LD, favicon, RSS, hreflang), and scopes it as plain HTTP with no browser. That is enough to separate it from seo_audit_website (broader audit) and extract_sitemap_urls (discovery) 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 concrete use cases — "link previews, enrichment or quick SEO checks of specific pages" — and the inline note that only supplied URLs are fetched (no crawling). It does not name a sibling alternative or state when to prefer seo_audit_website instead, so the routing guidance stops at clear 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 cover read-only, open-world, non-destructive and non-idempotent, and the description adds substantial context on top: pricing ($0.001 per job), the maxCostUsd charge cap, server-side defaults (maxTotalJobs=25, includeDescription=false), and an affiliation disclaimer. It also explains the token trade-off behind disabling descriptions, which is genuine behavioral context an agent cannot infer from 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?

Front-loaded with purpose, then input modes, then filters, then cost and defaults — the ordering matches how an agent needs the information. Dense but every sentence carries operative detail; the only filler is the 'not affiliated with Greenhouse' line and the Actor URL.

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 19-parameter, no-required-parameter scraper with no output schema, the description covers the decision-critical pieces: cost, caps, defaults, demo behavior and mode selection. What it omits is any sense of the shape of a returned job record, which leaves the agent guessing what fields come back without a description included.

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; the description still adds value by surfacing the cost-relevant defaults, the reason includeDescription is off (token savings), and a compact list of the filtering knobs (keywords, excludeKeywords, locations, remoteOnly, postedWithinDays). It does not resolve the mild tension between 'default maxTotalJobs=25' and the schema note that an empty field means 0/no limit.

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 specific verb+resource (open jobs from Greenhouse boards) and immediately scopes the source to companies hiring through Greenhouse, which cleanly separates it from lever_jobs, ashby_jobs, workday_jobs and search_remote_jobs by ATS. An agent can pick this tool 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 explains the two operating modes explicitly — pass companies (slug, boards.greenhouse.io URL, or careers page) or set searchDirectory=true to use the 147-board directory — plus a documented zero-input demo fallback. It never states when to prefer a sibling ATS tool or when this tool is the wrong choice, so exclusions are missing.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: per-job pricing of $0.001 charged to the caller's Apify account, the maxCostUsd cap, server-side defaults (maxTotalJobs=25, includeDescription=false), the demo-run behavior, and a non-affiliation disclaimer.

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?

Dense but front-loaded: purpose comes first, then input modes, filters, cost, and defaults. Some clauses duplicate schema defaults and the pricing/actor sentences are wordy, but every sentence carries information an agent needs.

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 19-parameter, zero-required tool with no output schema, the description covers invocation modes, cost limits, defaults, and directory search well enough to call it correctly. It does not describe the shape of returned job records, which would close the last 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?

Schema coverage is 100%, so the baseline would be 3 even with no parameter info. The description still adds value by tying includeDescription to token savings, explaining that searchDirectory covers 58 verified boards, and repeating the applied defaults for maxTotalJobs and includeDescription.

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 ('Open jobs from companies that hire through Lever') plus source coverage (jobs.lever.co, EU boards). Against siblings like greenhouse_jobs, ashby_jobs, and workday_jobs, the ATS is named explicitly, so the agent can route without opening a 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?

Explains the two input modes (companies list vs searchDirectory=true) and when to use each, plus how to filter and the demo-run fallback when companies is empty. It stops short of naming sibling tools as alternatives, so the when-not-to-use-this-tool guidance relies on the ATS name alone.

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 annotations, it discloses the paid, metered nature of the call ($0.00015 per item, capped at maxCostUsd default $0.25, max $5), that contact details are redacted by default, server-side defaults for omitted params, the 120-day seen-item retention for onlyNewItems, and the 1,000-hit pagination ceiling with its workaround. This is exactly the operational context annotations cannot carry.

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 with the two modes, then cost and defaults — a sensible priority order for a paid, multi-mode tool. Some redundancy remains, such as repeating maxItems=50 and the maxCostUsd default that the schema already declares.

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 17-parameter, two-mode tool with no output schema, the description covers purpose, cost, defaults, and job-record fields adequately. The search-mode result shape is left vaguer than the job rows, and no rate-limit or latency expectations are given, but nothing critical to correct invocation 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 description coverage is 100%, so the schema already explains every parameter in detail. The description adds cost math ('50 rows are about $0.0075') and states that maxCostUsd is passed to Apify as maxTotalChargeUsd, but otherwise restates defaults already present in the schema. 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 states two distinct modes with specific verbs and resources: keyword/points/date search over HN stories and comments via the Algolia HN Search API, and parsing of the monthly 'Ask HN: Who is hiring?' thread into job records. It even names the upstream actor and identifies the fields (company, role, location, remote, salary) produced in job mode, so an agent knows exactly what it gets.

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?

Mode selection and fallback behavior are clear ('Leave empty to list the newest items', sortBy tradeoffs, whoIsHiring = latest month by default). However, it offers no guidance against siblings such as search_remote_jobs or the ATS job tools, which overlap with whoIsHiring mode — the agent must infer when HN job posts are preferable to a dedicated job board.

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 read-only, open-world, non-destructive behavior, and the description goes well past them by disclosing metered pricing ($0.001 per job billed to the caller's Apify account), a per-call cost cap (maxCostUsd default $0.25), server-side defaults (maxTotalJobs=25), dedupe with source attribution, and the upstream Actor being run. Those are exactly the operational facts an agent needs before spending the user's money.

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 with what the tool returns and where it comes from, then filtering, then cost and defaults - a sensible order with no filler sentences. It is dense but every sentence carries information, though the trailing Actor URL is close to boilerplate for an agent choosing a 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?

For an 18-parameter, zero-required aggregator with no output schema, the description covers the essentials: result shape (deduplicated list with source labeled), primary filters, cost model, and defaults, while deep per-parameter detail is fully carried by the schema. The only mild gap is not describing the returned record fields (e.g. alsoListedOn, descriptionText), which the schema only partially implies.

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 description adds real value by surfacing the high-signal filters (keywords, excludeKeywords, locations, requireSalary, minSalaryUsd, postedWithinDays, includeDescription) and clarifying the cost-cap semantics of maxCostUsd. It also resolves an internal schema ambiguity by stating the server default of maxTotalJobs=25 where the schema text says 'Default 8'. It does not explain the board-specific filters (wwrCategories, jobicyGeo, jobicyIndustry, stateStoreName), but those are documented in-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?

States a concrete verb and resource ('deduplicated list of remote job postings') and enumerates the exact sources (Remote OK, We Work Remotely, Jobicy), which functionally separates it from the ATS-specific siblings like greenhouse_jobs and lever_jobs. The sourcing also tells the agent the results come from public aggregator feeds rather than a single employer's board.

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 the filter list and the cost note, but there is no explicit when-to-use/when-not statement and no naming of the ATS siblings as the alternative for company-specific searches. Hints such as turning on includeDescription 'for full descriptions' and onlyNewJobs for scheduled runs exist, but most of that guidance lives in the schema rather than the description.

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 discloses the full cost model ($0.003 per page, per-run Actor start fee), the maxCostUsd cap (default $0.25) and the server-side default maxPagesPerSite=10, plus the fact that only same-host links are crawled. It also states the return shape (one record per page with issues and a 0-100 score), so an agent knows what it will get back and what it will spend.

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 it is front-loaded with purpose and the alternative before moving to cost and defaults; almost every clause carries information. It is a single long block, however, and the Actor identifier/URL at the end is provenance rather than something an agent uses to invoke 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?

For a seven-parameter, pay-per-page crawl tool with no output schema, the description covers the crawl scope, defaults, cost ceiling, result granularity, and the sibling alternative. Nothing an agent needs in order to call it correctly, or to predict the bill, 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 description coverage is already 100%, so the baseline is 3; the description still adds cost meaning to parameters that the schema leaves abstract, tying each charged row to $0.003 and noting which failures still count as pages. The remaining cost and pagination semantics are largely delegated to the schema, so it does not fully earn a 5.

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 and resource ('Crawl a site ... and audit every page') and enumerates exactly what is checked (titles, meta descriptions, H1s, canonicals, noindex, alt text, JSON-LD, response time). It also explicitly distinguishes itself from the sibling extract_website_metadata, so an agent can choose without opening either 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 an explicit when-to-use rule ('use it to find what to fix on a site') paired with the alternative and its selection condition ('use extract_website_metadata instead when you only need the tags of known URLs'). The same-host restriction and robots.txt obedience are also stated up front.

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=false, but the description adds substantial context beyond them: per-job pricing ($0.002), a maxCostUsd cap, server-applied defaults (maxTotalJobs=25, includeDescription=false), external Actor provenance, and a non-affiliation disclaimer. However, it does not describe the returned record shape despite there being no output schema, so it does not reach a 4 or 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?

Front-loaded with purpose and the URL requirement, then filters, then cost/defaults. Dense but each sentence carries information; slightly long for a single paragraph yet not 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?

Given 28 parameters and no output schema, the description is fairly complete: it covers cost model, defaults, demo behavior, and state store usage. The main gap is that it does not describe the shape of returned job records.

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 parameters are already documented. The description reinforces a few (keywords, excludeKeywords, locations, remoteOnly, postedWithinDays, includeDescription, maxCostUsd) and states defaults, but does not add meaning beyond the schema for the 28 parameters.

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 specific verb and resource ('Open jobs from a Workday career site') and clarifies the URL-based input requirement with an example. It is distinguishable from greenhouse_jobs/lever_jobs/ashby_jobs by the Workday scope, though it never explicitly routes to those 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?

Explains key usage conditions: pass full career site URLs, bare names are skipped, empty companies triggers a demo run, and descriptions are off by default. No explicit when-to-use-versus-alternative guidance for the sibling ATS tools, which keeps it from a 5.

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