SiteCheck Jobs & Property

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

Beyond the readOnly/openWorld annotations, the description discloses the data source and its limitations (no salary or location fields exist in the feed, so they are absent from results), and a full cost/payment model: $0.002 USDC per successful call via x402 on Base/Solana/Arc, with failed calls not charged. That is exactly the kind of context annotations cannot convey.

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 returns and immediately followed by the two facts an agent cannot get elsewhere: absent fields and per-call pricing. No filler or repetition of the 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?

An output schema exists, so return structure need not be restated; the description nonetheless names the key fields and explicitly rules out salary/location. Combined with the pricing and failure-charge policy, an agent has everything needed to decide and invoke.

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, limit, and the schema already documents its range (1–50) and default (10) at 100% coverage. The description adds nothing about limit behavior or ordering beyond 'newest,' so the baseline 3 for high schema coverage 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 a specific verb and resource — newest 4-day-week and flexible job postings — and identifies the exact source (4dayweek.io's public RSS feed), plus the fields returned (role title, company/author, link, publish time). That niche framing cleanly separates it from the many general job-board siblings like jobs_indeed or jobs_flexjobs.

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 implies usage context by scoping to 4-day-week/flexible roles, so an agent can infer when this source is relevant. However, it never explicitly states when to prefer it over a sibling (e.g. FlexJobs, We Work Remotely) or any exclusions, leaving the routing decision 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 cover read-only/open-world, and the description adds substantial non-annotation behavior: paid access at $0.002 USDC per successful call, x402 payment over Base/Solana/Arc, and the fact that failed calls are not charged. It also discloses the attribution requirement imposed by alternative.me, an obligation the agent would otherwise not know about.

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 compact sentences: what it returns, where it comes from plus the attribution duty, then what it is not. Pricing and payment rails follow immediately. Front-loaded with the payload and 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?

Output schema exists, so return format need not be explained; the description still covers source, range, granularity, cost model, payment options, billing on failure, and attribution. Nothing an agent needs before invoking is absent.

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 parameter 'days' is fully documented in the schema (1-30, default 7) and the description only repeats the ceiling with 'up to 30 previous days.' With 100% schema coverage the baseline of 3 applies; the description adds no format or edge-case detail beyond 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?

States a specific resource (Crypto Fear & Greed Index 0-100 from alternative.me), the exact payload (today's value and label plus up to 30 prior days), and the granularity (daily). It also explicitly rules out the misreading its 'jobs_' name invites with 'Not a job or salary dataset,' which is exactly the differentiation an agent needs among 60+ job-board 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?

Clearly signals the use case (crypto market sentiment, daily history up to 30 days) and negatives the wrong one (not jobs/salary data), which is the main confusion risk given the name. There are no true sibling alternatives to route between, so no exclusions or comparisons are missing, but there is no explicit 'use when' clause either.

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 only mark it read-only and open-world, yet the description adds genuinely non-obvious behavior: the 300-posting ceiling, the exact return fields, the absence of a salary field, and full pricing mechanics ($0.002 USDC per successful call via x402 on Base/Solana/Arc, failed calls free). That pricing and charging-failure semantics are things no structured field conveys.

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 dense sentences, front-loaded with source and scope, then return shape, then pricing. No repetition and every clause 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 zero-required-parameter read-only tool with full schema coverage and an output schema, the description covers source, scope, return contents, known gaps (no salary), and cost. Nothing material for 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 coverage is 100% and both parameters (limit, remoteOnly) are documented inline in the schema, so the baseline is 3. The description does not add anything about the parameters, but the schema already carries that burden.

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 the specific source (Arbeitnow public job board API), the region ('mostly Europe, many remote roles'), and the exact slice returned ('newest 300 postings'). This names the resource well enough to distinguish it from the many sibling job-board tools, though it does not explicitly contrast itself with 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?

Usage is implied by the source description and the 300-posting cap, giving the agent a sense of scope, but there is no explicit when-to-use/when-not guidance or named alternative such as jobs_weworkremotely or jobs_nodesk_remote_jobs.

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, but the description adds real context on top: data is scraped from the job list embedded in the public page, the company name is structurally absent and therefore not returned, and each successful call costs $0.002 USDC via x402 while failures are free. That cost and data-gap disclosure is exactly the kind of thing the agent needs before invoking. No pagination or rate-limit detail, though.

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?

Purpose is front-loaded in the first clause, followed by returned fields, the company-name caveat, and pricing; each sentence carries information. The field enumeration is slightly long given an output schema exists, but it is 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?

With an output schema present, the description doesn't need to explain return shapes, and it covers the essentials: source, field coverage, known data gap, and per-call cost. The only gap is guidance on result-set sizing beyond what the schema already states.

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 with 100% schema description coverage ('How many jobs, 1 to 30 (default 10)'), so the schema carries the burden. The description adds nothing about the limit or default, hence 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?

The description states a specific verb and resource — remote engineering roles listed on Arc.dev — and pins the exact source site plus the fields extracted (title, job type, experience level, posted time, pay, skills). Against 60+ sibling job-board scrapers, naming Arc.dev is what lets an agent distinguish it 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?

Usage is only implied: an agent infers it should call this when Arc.dev listings are wanted. There is no statement of when-not to use it and no pointer to an alternative sibling such as jobs_we_work_remotely or jobs_wellfound_jobs for overlapping remote-engineering coverage.

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 only cover read-only and open-world; the description adds substantial context they don't: the billing model ($0.002 USDC per successful call via x402, failures not charged) and the returned field set plus the salary's absence. That pricing and coverage disclosure is the kind of behavior an agent needs before invoking a paid endpoint.

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 source and scope come first, then returned fields, then caveats and pricing, each in a short clause. Dense but front-loaded; the parenthetical example earns its place, though the pricing clause 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 needn't explain return values yet lists them usefully, and it covers the cost and the salary gap—the two things most likely to surprise a caller. Minor gap: no mention of pagination or behavior when org is unknown.

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 both parameters are already documented; the description adds only a matching example ('e.g. ashby') and reinforces the single-company constraint. It adds marginal meaning but nothing beyond the schema on the limit parameter or range behavior.

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 ('Open roles from one company's public Ashby job board') and the source scope (one company per call), which is exactly what differentiates it from the many other job-board siblings. An agent can tell this returns Ashby-hosted postings and not a general aggregator.

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?

Implies when to use it via 'pass its organization name' and 'one company per call', and offers a caveat ('Ashby gives no salary in this feed') that steers an agent away when salary is required. But it never names an alternative sibling or states explicit when-not conditions, leaving routing 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?

Adds substantial context beyond readOnlyHint/openWorldHint: exact pricing ($0.002 USDC per successful call), payment rails (x402 on Base, Solana, Arc), and the explicit guarantee that failed calls are not charged. It also discloses sort order and that a total count is returned — real behavioral value for an agent deciding whether to call.

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?

Purpose is front-loaded and the pricing caveat is placed last where it belongs. The long enumerated field list is dense but largely informative; it is somewhat redundant given an output schema exists.

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?

Covers filtering, sorting, total count, and cost/payment model, which is what an agent needs before spending money on a call. Field enumeration duplicates the output schema, and it says nothing about rate limits or result-coverage scope, keeping it just under 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 q, page, limit, type and category. The description only restates that keyword/category/type filters exist, adding no format or edge-case detail beyond 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?

Opens with a specific verb+resource ("Open jobs on Authentic Jobs") and scopes the niche (design, engineering, product, marketing), which distinguishes it from generic boards in the sibling list. It stops short of explicitly contrasting with other job-board siblings like jobs_dice or jobs_themuse_jobs.

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?

States that keyword, category and type filters are optional and that results are newest-first, implying a browse/search use case. It never says when to pick this board over the many sibling job boards, nor any when-not conditions or prerequisites.

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 readOnlyHint/openWorldHint annotations: discloses the residential-proxy data path, the ~30-jobs-per-page cap, and a precise cost/auth model ($0.01 USDC via x402 on Base/Solana/Arc, failed calls free). Cost and billing semantics are exactly the kind of context an agent cannot infer from structured fields.

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-loads purpose and region, then fields, then cost/billing in a logical order with no filler. It is a single dense run-on sentence whose long field enumeration could be trimmed, but 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?

An output schema exists, yet the description still signals the payload shape, and it covers the two things an agent most needs and cannot infer: the per-page ceiling and the paid-call billing mechanism. Nothing material is missing for correct invocation.

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% and mirrors the description's mention of query, country, optional city and page. The description adds little parameter-level detail beyond phrasing like 'up to ~30 jobs per page', which the schema's page range (1-10) already governs, 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 source (Bayt.com), a region (MENA), the query shape (keyword in a country, optionally a city), and enumerates the returned fields. This clearly separates it from the many generic job-board siblings such as jobs_indeed or jobs_linkedin_jobs without needing to open 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 MENA scope plus 'for a keyword in a country (optionally a city)' gives an agent clear context for when this tool fits versus global boards. However, it never explicitly names an alternative or states when NOT to use it, 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 already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds materially beyond that: pricing ($0.002 USDC per successful call), payment rails (x402 on Base, Solana or Arc), and the notable fact that failed calls are not charged — all decision-relevant for an agent.

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-loads identity and source, then usage, then cost — a sensible order. The field enumeration is somewhat long, but every element maps to an actual output field, so little 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, the description needn't explain return values, and it covers inputs, cost, and payment mechanics. The only omission is any note on result limits or pagination behavior, which for a multi-result listing tool an agent would want to know.

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% and each parameter is described there, so the schema carries the semantics. The description only restates the filters generically ('optional keyword and remote-only filters') and adds no syntax or format detail beyond 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?

States a specific verb and resource ('Open positions of a company that hires through Breezy HR') plus the exact data source (public career-site feed), and enumerates returned fields. Naming Breezy HR as the platform is precisely what separates it from the many sibling job-board 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?

Explains how to supply the required identifier ('Give the company's Breezy subdomain — the part before .breezy.hr') and mentions the optional keyword and remote-only filters. It does not explicitly say when to prefer this over sibling boards, though the platform-specificity makes the choice fairly evident.

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, but the description adds genuinely useful context beyond them: pricing at $0.002 USDC per successful call via x402, failed calls not charged, and the 25-per-page volume. It could go further on pagination behavior or rate limits, but the cost model is a strong disclosure.

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 dense sentence that front-loads the resource and source, then the returned fields, then the pricing. It is run-on but every clause (including cost and page size) is decision-relevant.

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 doesn't need to enumerate return fields but does so helpfully; the pricing/payment mechanism is the key missing-context item and it is covered. The main gap is lack of sibling differentiation for a crowded tool category.

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% and already documents both params (search as job title/skill, page 1-20 default 1). The description restates the search term and page volume but adds no syntax or format detail the schema lacks, 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?

States a specific resource and scope: tech/startup jobs from Built In for a search term, with the fields returned and 25-per-page volume. The source ('Built In's public job search page') implicitly distinguishes it from sibling job boards, though no sibling is named explicitly.

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 despite dozens of sibling job-board tools (dice, indeed, linkedin_jobs, wellfound_jobs, etc.). An agent gets no signal about when Built In is preferable to alternatives, nor any exclusions.

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 behavioral detail beyond the annotations: how source systems are identified, how missing boards are reported, that salary is often absent, and that billing is $0.002 per successful call via x402 with failed calls not charged. This is exactly the kind of operational context annotations do not cover.

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 most sentences carry useful information about sources, missing boards, return fields, salary gaps, and pricing. The return-field list is somewhat redundant given the output schema, keeping it from a perfect score, but overall it is efficient for a multi-API paid 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 paid, multi-source ATS lookup tool, the description covers the key operational details: scope, source attribution, not-found behavior, field availability, salary limitations, and payment terms. With the schema and output schema handling parameters and return shape, an agent has enough information to call it correctly.

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 are already documented in the schema. The description reinforces that the company input is an ATS token, but does not add syntax, defaults, or constraints beyond 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?

The description states a specific verb and resource: retrieving open roles for one company token. It also scopes the tool to three named ATS APIs (Greenhouse, Lever, Ashby), which clearly distinguishes it from the many single-ATS sibling 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?

The description makes the intended context clear: use it when you have one company token and want roles across Greenhouse, Lever, and Ashby. It does not explicitly name when to prefer the individual ATS siblings, but the usage context is otherwise 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 only declare read-only and open-world, so the description carries most of the burden and does: it discloses the fixed 20-per-page pagination, the total match count, the field set returned, and — critically — a paid-access model ($0.002 USDC via x402 on Base/Solana/Arc, failures not charged). Auth/payment cost is exactly the kind of context annotations cannot express.

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-loads the resource and scope, then packs output fields, pagination, and pricing into two sentences with no filler. The field enumeration is dense but each item is concrete; only the overlap with the output schema makes it slightly longer than strictly necessary.

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?

Covers scope, input, output shape, pagination, and the unusual payment prerequisite — the last being the piece an agent could not infer from schema or annotations. With an output schema present, the field listing is a bonus rather than a gap-filler.

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 both parameters are already documented. The description adds only the fixed page size of 20, which gives useful context for the 'page' parameter, but nothing about keyword syntax or matching behavior. Baseline 3 for a schema-complete tool 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 resource (ClearanceJobs postings), the input (a keyword), and a precise scope: US defense/intelligence roles requiring a security clearance. That niche framing alone separates it from generic boards like jobs_indeed or jobs_dice 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 domain constraint ('US defense and intelligence jobs that need a security clearance') plus 'From the public search page' gives a clear picture of when this tool applies, and the results shape (20/page, total count) implies the browsing workflow. It stops short of naming alternatives or exclusions, so it lands at 4 rather than 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?

Goes well beyond the readOnly/openWorld annotations: it discloses the data source (public search pages via a rendering residential proxy), a hard pagination ceiling (20 per page, page 1 to 5), the truncation behavior of the total ('10,000+'), and the pricing model ($0.02 USDC per successful call via x402 on Base/Solana/Arc, failures not charged). The failure-not-charged detail is exactly the kind of cost-safety context an agent needs before retrying.

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?

Purpose and scope are front-loaded, and the field list is compact. The enumeration of returned fields is somewhat dense for a tool that also has an output schema, but every sentence (payment terms, proxy source, page limits) carries operational weight.

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 needn't describe return values, and it still covers the non-obvious operational facts: paid-per-success cost, payment rails, scraping source, and pagination ceiling. Nothing an agent needs to invoke this correctly 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 coverage is 100%, so baseline is 3, but the description adds real meaning: location is a 'town or postcode' (the schema only says town/city/region) and page is bounded to 1-5 with 20 results each. It does not explain how q interacts with results beyond keyword, which keeps it below 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?

States a specific verb+resource ('CV-Library (UK) jobs for a location and optional keyword') and enumerates exactly what each result contains (id, title, company, location, salary text, job type, posted time, snippet, link). The brand + UK qualifier cleanly distinguishes it from the many other job-board siblings such as jobs_reed_co_uk or jobs_indeed.

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?

Scope is implied well: location is required, keyword optional, and results are capped at pages 1-5 of 20 each. But there is no explicit when-to-use vs. when-not guidance and no named alternative (e.g. reed or indeed for UK jobs), so the agent must infer selection from the brand 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?

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing privacy ('no data is stored'), cost model ($0.002 USDC via x402 on Base/Solana/Arc), and billing fairness ('failed calls are not charged'), plus the limitation 'no AI rewriting'. These are exactly the traits an agent needs before invoking a paid tool.

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-loads the core purpose, then limitations, privacy, and pricing in a compact block. It is dense but each clause (ATS framing, no storage, pricing) earns its place; only minor tightening possible.

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 needn't be explained, and the description still covers privacy, pricing, and the non-AI behavior. Nothing an agent needs to call this paid tool correctly 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 coverage is 100% and documents all three params with ranges (job up to 4,000 chars, top 10-60, resume up to 6,000 chars), so the schema carries the load. The description references 'top terms to add' and plain-text inputs but adds no syntax beyond the schema, so baseline 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+resource: ATS-style keyword check between a resume and job ad, including the outputs (coverage/missing terms, 0-100 score, top terms). This is categorically distinct from every sibling, which are all job-listing/scraping tools, so an agent can route to it immediately.

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 clarifies the input model ('plain text analysis of the two texts you send') and rules out the AI-rewriting interpretation, giving clear context for use. It stops short of explicitly naming when-not or an alternative, but the sibling set is unambiguous so 4 fits.

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 only declare readOnlyHint and openWorldHint, so the description earns credit for disclosing the paid-call model ($0.002 USDC per successful call via x402, failed calls not charged) and the first-page-only coverage limit. It does not mention rate limits or what happens on an invalid category slug, keeping it short of 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?

Purpose is front-loaded and every clause carries information; there is no filler. Minor inefficiency: the long enumeration of returned fields duplicates what the existing output schema already defines.

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 an output schema, the description covers purpose, source, scope limit (first page), data quirks (Bulgarian date format, salary only when published) and cost model. Remaining gaps are minor: no failure behavior for unknown category slugs and no pagination guidance.

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% and the single required 'category' parameter is already documented with slug examples in the schema, so the description's list of example categories (python, java, javascript, devops, qa) merely repeats it. Baseline 3 applies since 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 and resource (fetch Bulgarian IT jobs from DEV.BG for a technology category) plus the exact fields returned, so it is instantly distinguishable from the ~60 other job-board siblings by source site and geography. No ambiguity about what the tool does.

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?

Scope is implied: DEV.BG is a Bulgarian board and only the first page of the category listing is returned, which implicitly tells the agent this is a shallow, source-specific fetch. However, there is no explicit when-to-use statement, no 'use X instead for remote/other countries' routing, and no note about how to get beyond page one.

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 annotations by disclosing the pricing model ($0.002 USDC per successful call, paid via x402 on Base, Solana or Arc) and that failed calls are not charged. It also states the page granularity (~20 per page) and that a total match count is returned, which materially affects how an agent budgets and paginates.

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?

Purpose and scope are front-loaded, and the cost sentence at the end earns its place. The middle enumeration of return fields is slightly dense and partly duplicates the output schema, but nothing is wasted or buried.

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 field-by-field enumeration is redundant, but the description supplies everything else an agent needs: filtering options, page size, total count, and cost/payment behavior. Complete for correct invocation, just mildly over-specified on the return shape.

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 four parameters are already documented with examples. The description restates their meaning (keyword, optional location, optional remote-only filter) and adds only the ~20-per-page figure, which is marginal value over the structured fields.

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: tech job listings from Dice (US) for a keyword plus optional location, and enumerates what each listing contains. The named source (Dice) and tech-only scope are enough to tell it apart from the dozens of sibling job-board tools 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?

Usage is implied by the source and scope (US tech jobs, keyword search, optional remote-only or location filter) but there is no explicit when-to-use or when-not-to-use guidance and no routing to alternatives like a multi-job-board aggregator. An agent must infer selection from the source 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?

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the per-call price ($0.002 USDC via x402 across Base, Solana, or Arc), that failed calls are free, and that only ~15 postings exist per page. Payment/authorization mechanics and pagination limits are exactly the operational context an agent needs before committing to a paid call.

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?

Purpose, scope, and page size are front-loaded in the first two sentences, and the pricing sentence earns its place for cost-aware agents. The enumerated return fields (title, company, location type, salary, link) are somewhat redundant given an output schema exists, making it slightly longer than necessary.

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 covering return values and annotations covering the safety profile, the description supplies everything else that matters: source domain, geography, data provenance, page-size ceiling, and cost/failure semantics. Nothing an agent needs to decide and call correctly 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 coverage is 100% and the single `limit` parameter is fully described in-schema (1 to 15, default 10). The description only adds the corroborating fact that the page holds about 15 postings, which explains the cap but adds nothing on syntax or behavior. 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 resource (tech job postings), an explicit source (Djinni.co's public job list), and a scope (mostly Ukraine and remote roles), plus the underlying data source (schema.org JobPosting). An agent can distinguish this from the dozens of other job-board siblings by the named domain alone.

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 domain and geography imply when this board is appropriate, but there is no explicit when-to-use/when-not or comparison to any sibling such as jobs_djinni-like regional boards or jobs_multi_job_board. Usage selection is left to inference from the source name.

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 readOnlyHint and openWorldHint, yet the description adds genuinely non-obvious behavior: pricing ($0.002 USDC per successful call via x402 on Base/Solana/Arc) and that failed calls are not charged. That is real value beyond structured fields; it stops short of explaining rate limits or result freshness.

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-loads the source and scope, then packs search modifiers and payment terms into the remainder with little waste. It is dense — one long sentence plus a pricing sentence — but every clause 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?

Covers source, coverage, return fields, query behavior, sort options, total count and payment model, which is sufficient for a read-only search tool. The field enumeration is somewhat redundant given an output schema exists, but nothing an agent needs to call it correctly 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 coverage is 100%, so all five parameters are already documented; the description's mention of 'optional country' and 'newest first or best match' merely restates the schema's country and sort fields. Baseline 3 is appropriate since the schema carries the 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?

States a specific verb+resource ('Job vacancies from EURES, the EU job mobility portal') and pins the scope to EU/EEA public employment services, which clearly separates it from the many other generic job-board siblings (indeed, arbeitnow, dice). The enumerated returned fields further clarify the resource shape.

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?

Describes the search model ('Keyword search, optional country, newest first or best match; plus total count'), which implies usage, but never states when to prefer this over sibling job boards or when it is unsuitable (e.g. non-EU roles). No alternatives or exclusions are named.

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 mark it read-only and open-world, and the description adds genuinely non-obvious context: data comes via a residential proxy, employer names are deliberately omitted because FlexJobs hides them from non-members, and billing is $0.002 per successful call with failures not charged. It stops short of rate limits or pagination behavior, but the cost and data-completeness caveats are real value 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?

Front-loaded with purpose and the returned field list, then sourcing, a data limitation, and pricing — each clause carries information. The field enumeration is long but useful for judging relevance before spending a paid call.

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 covering return shape and annotations covering safety, the description fills the remaining gaps an agent needs: cost model, charged-vs-failed behavior, proxy sourcing, and the missing company field. Only rate/throughput expectations are absent.

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%, with both limit and category fully documented including examples, so the baseline is 3. The description reinforces the category-as-slug concept and its example values but adds nothing the schema does not already state.

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 resource (FlexJobs remote/flexible jobs) keyed by job title or category, and enumerates the returned fields. Naming flexjobs.com as the source implicitly separates it from the dozens of other jobs_* board scrapers, though it never contrasts with a named sibling implicitly or explicitly.

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: the tool is for finding remote/flexible roles on FlexJobs and requires a site-specific category slug. There is no guidance on when to prefer it over jobs_we_work_remotely, jobs_nodesk_remote_jobs or other remote boards, and no exclusions or prerequisites beyond the slug format.

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 annotations: it discloses the underlying public JSON route, the exact result fields (including that salary is only present 'when the employer shows it'), the match count, and the metered payment model ($0.002 USDC per successful call via x402, failures free). Pricing and failure-billing behavior are exactly the kind of 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 source and result scope, followed by a compact billing sentence. It is dense and slightly long in the first sentence, but each clause (source, region, fields, price, failure policy) 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?

An output schema exists, yet the description still summarizes returns usefully; source, region, pricing and failure policy are all covered. Minor gaps remain around result freshness and pagination limits relative to the start cap, but nothing blocking 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 documents query, location, limit and start. The description only restates keywords and 'optional city' without adding format or constraint detail, so it earns the baseline rather than more.

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 ('job ads on foundit.in') plus the scope (keywords + optional city) and even the origin ('formerly Monster India'), which distinguishes it cleanly from the many other job-board siblings. An agent can identify the site and result shape 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 India/foundit framing implies when this tool is appropriate versus, say, jobs_naukri_com or jobs_indeed, but no alternative is named and there are no explicit exclusions or preconditions (e.g., indexing lag, coverage limits). Usage is inferable but not instructed.

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, the description discloses several behaviors an agent could not infer: access goes through a residential proxy, only the three reviews shown to logged-out visitors are returned, and the call costs $0.002 in USDC via x402 (Base, Solana or Arc) with failures not charged. These are exactly the operational facts that affect selection and planning.

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 dense paragraph that front-loads what the tool returns before moving to input requirements and pricing. Every sentence carries information, though the run-on field list is slightly heavy.

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, annotations covering safety, and a fully documented single parameter, the description fills the remaining gaps: input identifier shape, payment model, proxy routing, and the truncation of reviews. Nothing an agent needs to call it correctly 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 coverage is already 100%, so the baseline is 3. The description reinforces the single parameter's format ('Apple-E1138') and pairs it with a concrete example, adding modest but real confirmation of the URL-slug form.

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 (Glassdoor employer reviews) and enumerates exactly what comes back: overall rating, sub-ratings, CEO approval, recommend/outlook shares, star distribution and three sample reviews. That makes clear it is a reviews endpoint rather than a job-listings endpoint, though it never explicitly contrasts itself with the similarly named sibling jobs_glassdoor_jobs.

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 states the prerequisite input ('Needs the employer's Glassdoor name and id, e.g. Apple-E1138'), which is useful context. But it offers no when-to-use/when-not guidance and never routes the agent to a sibling such as jobs_glassdoor_jobs when listings rather than reviews are wanted.

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?

This is unusually strong: it discloses the 30-job cap, that a total count is returned, that calls go through a residential proxy, the exact price ($0.002 USDC per successful call), the accepted payment rails (x402 on Base, Solana, or Arc), and critically that failed calls are not charged. These are precisely the behavioral facts an agent cannot get from the readOnly/openWorld 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?

The return fields and geographic scoping are front-loaded, with cost details pushed to the end where they belong. It is dense and long for a single sentence-plus-clause, but nearly every clause carries distinct information, so almost 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, the description needn't explain return structure, and it instead covers what the schema and annotations cannot: cost model, payment mechanism, failure billing, proxy routing, and the 30-item ceiling. An agent has everything needed to decide whether to call this and what it will cost.

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 three parameters are already documented, including the cityId example that the description repeats. The description's added value is the semantic framing of q as a US-wide keyword search and the cityId-as-URL-fragment explanation, but this largely overlaps the schema rather than extending it.

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 ('Glassdoor job search') and enumerates exactly what comes back: title, employer, rating, location, pay percentiles, age, easy-apply flag and link. This is far beyond tautology. It stops short of a 5 because a sibling named jobs_glassdoor exists and the definition never states how this tool differs from it.

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 scoping modes clearly: 'US-wide by keyword, or one city when you pass Glassdoor's city id', which is useful invocation guidance. However, it gives no when-to-use/when-not guidance against the many sibling job-board tools or against jobs_glassdoor, so the agent must infer selection criteria.

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 annotations by disclosing the data source (public search results page), result page size (10 per page), and the pricing model ($0.002 USDC per successful call via x402, failures not charged). It doesn't discuss rate limits or error/empty-result behavior, but the paid-call cost disclosure is high-value context.

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 dense sentence with the resource and scope front-loaded, followed by return fields and pricing. No filler, though the field enumeration is somewhat long for something an output schema already covers.

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 needn't be spelled out, and the description still adds source provenance and the paid-call mechanic. Nothing critical to invoking it correctly (keyword required, location optional, pagination) 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% and all three params are documented in schema, so the description adds little parameter detail. It reinforces 'keyword and optional location' and '10 per page', matching but not extending the schema's page 1-20 range.

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 a specific verb+resource: US public-sector job postings from GovernmentJobs.com/NEOGOV, scoped to state, county, city and agency jobs. It also lists the returned fields, so the agent can immediately distinguish this from other job-board 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?

The scope ('US public-sector', 'state, county, city and agency') implicitly separates it from federal jobs (jobs_usajobs) or private boards, but no sibling is named and no explicit when-to-use/when-not guidance is given. Usage must be inferred from the domain framing.

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 read-only and open-world profile; the description adds genuinely non-obvious behavior: it is a paid call ($0.002 USDC via x402 on Base/Solana/Arc) and failures are not charged. It also discloses an important data limitation (no salary on Greenhouse). Lacks only pagination/rate-limit 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?

Four short sentences, each carrying information: what it returns, the input requirement, the data limitation, and the pricing. Front-loaded with purpose before cost 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?

Since an output schema exists, return values need not be explained, though the description helpfully enumerates returned fields. Covers cost, scope, and data gaps; the only omission is guidance on choosing this tool over other job-board tools in a large sibling set.

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 both parameters are already documented with examples. The description restates the board-token example and adds the 'one company per call' framing, but gives no extra detail on the limit parameter or valid token formats. Baseline 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 the specific resource and scope: 'Open roles from one company's public Greenhouse job board', requiring a board token. The mention of Greenhouse plus 'one company per call' cleanly separates it from sibling board-specific tools like jobs_lever_jobs or jobs_ashby_jobs_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?

It tells the agent how to call it (pass the board token, e.g. airbnb or stripe) and notes the one-company-per-call constraint, but never says when to prefer this over alternatives such as jobs_multi_job_board or other ATS-specific tools. Usage is implied by the source name rather than 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 cover read-only and open-world behavior, so the description adds value by disclosing the pricing model ('$0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged') and page size (~30 per page). It doesn't cover rate limits or latency, but the cost/charge semantics are a meaningful addition over 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 source and scope, then the return shape, then pricing. Dense but every clause carries information; the long field enumeration is the only slight bloat.

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 the field enumeration is partly redundant, but the pricing/payment detail and page-size hint are exactly the non-schema context an agent needs before calling a paid tool. Nothing critical to correct invocation appears 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 coverage is 100%, so all three parameters are already documented. The description restates location and keyword behavior and adds 'area, town' nuance, but the page range (1–50, default 1) is left entirely to the schema. Baseline 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+resource+geography: 'UK job ads from Gumtree for a town or city and optional keyword'. This immediately separates it from the many other job-board siblings (reed, indeed, cv_library_uk, etc.) by source and region.

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 makes clear this is Gumtree-sourced UK-only data scoped to a location, which lets an agent decide when it applies. It never explicitly names an alternative or states exclusions (e.g. non-UK or nationwide searches), so it falls 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?

Goes well beyond the readOnly/openWorld annotations by disclosing the billing model ($0.002 USDC per successful call via x402 on named chains, failed calls free) and the sort behaviors. That payment detail is decision-relevant context an agent cannot get from the annotations or 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?

Purpose is front-loaded, followed by filter scope, return shape, ordering and price. The field enumeration is long but useful for result interpretation; the only mild waste is restating output fields when an output schema already exists.

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?

Covers the source, filters, defaults, ordering, cost and payment mechanics, which is everything needed to invoke correctly and to decide whether a paid call is worth it. Return values are additionally covered by an output schema, so no gaps remain.

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 seven parameters are already documented. The description adds a little semantic color (default job type, relevance-newest ordering) but says nothing about page or limit, which the schema carries alone — the baseline 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 resource and source ('Nonprofit and social-impact listings from Idealist') plus the scope of what it can return (jobs, internships, volunteer roles). The nonprofit/social-impact framing distinguishes it from the generic job-board siblings without needing a named comparison.

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 default mode (jobs) and the parameter-driven alternatives (internships, volunteer roles, country filter, remote-only), so an agent knows how to steer the call. It stops short of naming when to prefer a different job-board tool or when this source would be a poor fit.

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 provides crucial operational details beyond schemas or annotations, specifically the cost ($0.002/call), payment method, data limitations (no full descriptions), and data reliability (rankings are as Indeed shows them). This prevents unexpected user costs.

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 definition is highly dense and efficient, front-loading critical constraints (US scope, data fields, data source, and cost) in a single, well-constructed paragraph. There is zero fluff.

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 description is very complete, covering data source, geographical limits, specific data points, and financial constraints. While it doesn't detail the exact output structure, it describes the entire business model of the 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?

Since schema coverage is 100%, the baseline is high. The description adds value by explaining the types of data derived from the inputs—listing 'title, company, location, salary range, job type'—helping the agent understand the practical utility of the search 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?

The description clearly specifies the service (Indeed job search in US), the input (keyword and location), and the output scope (title, company, salary range, etc.). It immediately defines the tool's specific function.

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?

While it specifies what data is retrieved (e.g., 'no job descriptions'), it does not explicitly provide guidance on when to choose this tool over the many specialized job boards listed in the sibling tools. The usage context is somewhat implied by the data source.

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 and openWorld annotations, the description discloses exactly which fields are returned, that salary and description are omitted, the content language, and the pay-per-success x402 pricing model with no charge for failures. These are material behavioral details 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?

It front-loads the returned fields, then adds necessary exclusions, language, and payment details in compact sentences. Every sentence contributes 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?

Given one optional parameter, an existing output schema, and readOnly/openWorld annotations, the description covers the source, returned fields, omissions, language, and cost. Nothing material is missing for correct invocation.

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 only parameter, limit, is fully documented in the schema as 1 to 22 with a default of 10. The description adds no parameter-specific meaning, so the baseline of 3 applies given 100% schema coverage.

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: newest offers on InfoJobs' public Spanish job list page, with the returned fields listed. It distinguishes itself from the many sibling job-board tools by naming the source and geographic/linguistic scope.

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 clearly identifies the context: InfoJobs' public Spanish job list, which tells an agent when this source is appropriate. It does not explicitly say when to choose it over sibling job-board tools or name exclusions beyond the source scope.

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 annotations (readOnlyHint, openWorldHint) by disclosing the exact return fields, what is omitted, and the pricing model ($0.002 USDC per successful call via x402, failed calls not charged). This gives the agent critical operational and cost awareness.

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?

Four sentences with no wasted words: purpose and source first, then limitations, then pricing. Each sentence adds distinct value and 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 read-only tool with an output schema, the description covers all necessary aspects: data source, returned fields, exclusions, and cost. Nothing critical is missing for an agent to call it correctly.

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 single limit parameter is fully explained in the schema. The description adds no further parameter-level detail, but the baseline of 3 is appropriate when the schema carries the burden.

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 resource (jobs on Internshala's public /jobs/ page) and the data extracted (job title and detail-page link in page order). The source and format distinguish it from sibling job board 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?

Provides clear context by detailing what is returned and explicitly noting exclusions (company, location, pay), which helps an agent decide if the tool meets its needs. However, it does not name alternatives or state when to avoid this tool in favor of other job board 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?

Annotations already cover read-only and open-world behavior, but the description adds material context: it runs via a residential proxy, costs $0.01 USDC per successful call via x402 (Base, Solana, Arc), and failed calls are not charged. That pricing/settlement detail is exactly the kind of thing annotations cannot convey. It stops short of describing pagination limits beyond 'about 20 results' or rate/retry behavior.

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 does and the returned fields, followed by a compact cost/access note. Dense but no filler; the long field enumeration is justified by the number of output attributes.

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, yet the description still summarizes the payload shape, and it covers cost, source, geographic scope, and result volume. For a paid, proxied scraping tool, an agent has everything needed to decide and invoke it correctly.

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 baseline is 3; the description nonetheless adds meaning by listing country codes (uk, us, it, fr, de, es, in, br, ...) and asserting the ~20-results-per-page ceiling that contextualizes the page parameter. Keyword/place semantics duplicate the schema but the extras lift it above baseline.

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 (Jobrapido job search on a country site), enumerates the returned fields (advert id, title, company, location, posted date, salary, source, sponsored flag, link), and scopes input to keyword+place with ~20 results per page. An agent can distinguish this from jobs_indeed or jobs_jooble by source and country coverage.

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 implies when the tool applies (keyword plus optional place on a given country site) and notes the country code parameter. However, it never states when to prefer this over the many sibling job-board tools, nor any exclusions or prerequisites beyond 'country site code'. Usage is implied, not guided.

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, so the bar is lower, yet the description adds real behavioral context: the exact field set returned, the fields deliberately absent, a per-call price, the accepted payment rails (x402 on Base/Solana/Arc), and that failed calls are free. It does not mention rate limits or pagination, keeping it short of 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?

Three short sentences, front-loaded with the returned payload, followed by the exclusions and the cost model. No sentence is redundant, and the cost line is essential for an agent that must decide whether to spend money on a call.

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, yet the description still summarizes the return shape and explicitly names the absent fields, which is the key decision input. Combined with pricing and payment rails, an agent has everything needed to call this correctly and understand the cost.

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% and the single 'limit' parameter already documents its 1-50 range and default of 10. The description adds nothing about the parameter, which is the correct baseline when the schema does the 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 resource and verb-equivalent: newest remote jobs from Jobspresso's public feed, and enumerates the returned fields (title, company, location, category, link, publish time). The source name embedded in the tool name is reinforced by the description, which is what separates it from the ~60 sibling job-board tools, but no explicit sibling comparison is offered.

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 explicit when-to-use or named alternative, so the agent must infer that this is the Jobspresso source among many boards. The line 'Salary and description are not returned' serves as a partial exclusion hint, telling the agent to look elsewhere if those fields are required, but it is not framed as 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 already establish read-only and open-world behavior, yet the description adds substantive context the annotations lack: it requires the operator's JOOBLE_API_KEY, costs $0.002 USDC per successful call via x402 on Base/Solana/Arc, and that failed calls are not charged. That auth-and-billing disclosure materially informs invocation; rate limits and pagination behavior are the only notable omissions.

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 compact sentences: purpose first, then coverage constraint, then auth and pricing. Every sentence carries information, though the output-field enumeration is somewhat redundant given an output schema exists.

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 five-parameter read-only search with full schema coverage and an output schema, the description supplies the non-obvious operational facts an agent needs: API key requirement, US-only coverage, and per-call cost including the failure case. Only rate limits and result-volume expectations are left unaddressed.

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 page, radius, and salary semantics are already fully documented in the input schema; the description adds no parameter-level detail. The list of fields it recites (title, company, salary text, etc.) are return values, not inputs, which risks being misread as parameter guidance.

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 ('Job search on Jooble's aggregator through its official REST API') and enumerates the returned fields, so the agent knows exactly what it gets back. It identifies the provider clearly enough to separate it from siblings like jobs_indeed or jobs_multi_job_board, though it never explicitly says how it differs from those other aggregators.

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: it is a keyword+location job search, and the note that a jooble.org key covers US listings only hints at when it is appropriate. There is no explicit 'use this instead of X' routing and no stated exclusions beyond the geographic limitation.

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 and open-world access, but the description adds material context annotations cannot convey: a metered price of $0.002 USDC per successful call via x402 with failed calls not charged, plus the provenance caveat that figures are user-reported and therefore not authoritative. What it omits is failure behavior when a company or job family slug has no data, and any caching or rate-limit expectations.

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 scope in the opening clause, then the returned measures, then constraints and pricing. Dense but almost every element carries information; the enumeration of percentile fields is somewhat redundant against the output schema and is the one place a word could be saved.

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 two-parameter read with an output schema, the definition covers what an agent needs to decide and pay correctly: scope, geography, currency, data reliability, and cost model. The remaining gap is edge behavior (unknown slug, sparse sample size) which the output schema cannot express and the description leaves unstated.

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% — both company and jobFamily already document slug format with examples and the software-engineer default. The description reinforces the compound scope ('one company and job family') and adds the US/USD constraint that affects interpretation of results, but contributes no new syntax or format guidance. 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+resource (retrieve tech compensation for one company and job family from Levels.fyi's public salary page) and enumerates the returned measures: total-comp, base, stock, bonus percentiles p10-p90, sample size, and per-level average package. This is clearly distinguishable from the surrounding job-listing siblings and the adjacent comp sources (jobs_glassdoor, jobs_payscale) because it is explicitly a salary-page lookup keyed by company + job family.

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: the example 'google + software-engineer' and the phrase 'one company and job family' signal the calling pattern, and 'United States figures' scopes the applicability. There is no explicit when-to-use/when-not statement and no pointer to jobs_payscale or jobs_glassdoor as alternatives for non-tech or non-US compensation, so the agent must infer 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 only say read-only and open-world; the description goes far beyond by disclosing the returned fields, the absence of salary data, the one-company-per-call limit, and pay-per-call pricing ($0.002 USDC via x402 on Base/Solana/Arc) with failed calls free. The cost and failure-charging policy are exactly the kind of behavioral fact an agent needs before spending 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?

Four short sentences, front-loaded with what the tool does and the required identifier, then constraints, then price. The field enumeration (title, team, location, ...) partially duplicates the output schema, which is the only mildly wasteful element.

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 two-parameter read tool with full schema coverage, annotations and an output schema, the description supplies everything extra that matters: cost model, failure charging, data gaps (no salary), and per-call scope. Nothing an agent needs to call this correctly 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 coverage is 100%, so both parameters are already documented in the schema, including the 'spotify' example and the 1-100 limit range. The description adds only the 'one company per call' constraint, which is already implied by the required single company parameter; baseline 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 and resource ('Open roles from one company on Lever') plus a scoping constraint ('one company per call'), and names the platform explicitly, which is what distinguishes it from the many other job-board siblings (Greenhouse, Ashby, Recruitee, etc.). An agent can pick this tool out of the sibling list 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?

Explains how to invoke it ('pass its Lever site name, e.g. spotify') and sets a clear boundary ('one company per call'), and the note that Lever exposes no salary helps an agent decide whether this source is adequate for the task. It stops short of naming an alternative or stating exclusions versus other boards, so it is clear context rather than 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?

The annotations only provide readOnlyHint and openWorldHint, while the description adds meaningful behavioral context: public/logged-out scope, 10 results per page, omitted fields, pricing, payment rails, and the fact that failed calls are not charged. No annotation contradiction is present.

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 two compact sentences with no wasted language. It front-loads the core scope and then adds limitations and pricing details efficiently.

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 the output schema and annotations, the description supplies enough context to call the tool correctly: source scope, returned fields, exclusions, pagination behavior, and billing behavior. Nothing essential for 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%, with keywords, location, and page fully documented in the schema. The description echoes keyword/location usage and the 10-per-page limit but does not add syntax, defaults, or constraints beyond what the schema already provides.

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 the specific source and resource: LinkedIn job postings from LinkedIn's public logged-out job search. It also enumerates the returned fields and pagination, which clearly distinguishes it from sibling job-board tools by data source and scope.

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 implies when the tool is appropriate by specifying the public logged-out LinkedIn source and listing exclusions such as job descriptions, salaries, and applicant counts. However, it does not name alternatives or explicitly state when to choose this over sibling tools like jobs_indeed or jobs_glassdoor.

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 annotations: discloses the price model ($0.002 USDC per successful call via x402 on Base/Solana/Arc), that failed calls are free, that unknown boards return a not-found result, and that each job is tagged with its source board. That is exactly the operational context an agent needs before calling a metered tool.

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-loads the core purpose, then format, then return fields, then pricing — a sensible order with no filler. The billing sentence is long but carries unique 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 an output schema and full parameter coverage, the description only needs to add the non-obvious bits — supported systems, per-board attribution, not-found handling, missing salary data, and cost — and it covers all of them.

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, but the description adds real value by enumerating the allowed system prefixes (greenhouse, lever, ashby) that the schema leaves as free-text with no enum constraint. The limit parameter is left entirely to 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?

States a specific verb and resource ('Open roles from up to 5 named company boards in one call') and names the three supported systems. It does not explicitly contrast itself with the single-board siblings (jobs_greenhouse_jobs, jobs_lever_jobs, jobs_ashby_jobs_board), which sit right next to it in the list.

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 multi-board use case is implied by 'up to 5 named company boards in one call', and the format rules are clear, but there is no explicit guidance about when to choose this over the single-board tools or which boards are valid for which systems.

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, the description discloses the acquisition path (rendering residential proxy), the billing model ($0.02 USDC per successful call via x402 on three chains) and the crucial fact that failed calls are free, which tells an agent retries are safe. It omits rate limits, latency, and blocking/failure modes that a proxy-scraped source can exhibit.

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 sentence puts purpose first, then fields, then operational terms; nothing is padded with marketing language. The long comma-separated field list is dense and partly redundant with the output schema, which slightly weakens its efficiency.

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 paid, proxy-scraped search tool the description covers what an agent needs to call it responsibly: cost, failure charging, pagination cap, and data provenance. With an output schema present, the enumerated return fields are a bonus rather than a necessity, so only minor gaps (rate limits, result freshness) remain.

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% and all three parameters are documented in the schema itself, so the baseline is 3. The description's page-range and page-size note ('20 per page (page 1 to 5)') adds a small amount of context about result volume but nothing beyond what the schema's 'page 1 to 5' already states.

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 clause names a specific verb and resource ('Naukri.com (India) job search') and the source domain itself differentiates it from the many other job-board siblings. It does not, however, explicitly contrast itself with peers such as jobs_indeed or jobs_foundit_jobs, so sibling differentiation is left implicit.

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 'use this when' statement, no prerequisites, and no mention of when a competing India or global job board tool would be preferable. The only constraints given are operational (pages 1-5, 20 per page), which govern invocation rather than selection.

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 annotations by disclosing field coverage limits (no salary, location or description fields in the feed, therefore not returned) and the exact billing model: $0.002 USDC per successful call via x402 on Base/Solana/Arc, with failed calls not charged. That cost/failure semantics is behavior an agent cannot get from readOnlyHint/openWorldHint.

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, zero waste, and front-loaded with what the tool returns before the cost/limitations sentence. Each sentence carries distinct information (content shape, then field gaps and pricing).

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 structure is covered; the description fills the remaining gaps an agent needs — what the feed cannot provide and what invocation costs, including that failures are free. Nothing material is missing for a single optional-parameter read 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 description coverage is 100%, and the single limit parameter already documents the 1–50 range and default of 10. The description adds nothing about the parameter, so this is the standard baseline rather than added 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 specific verb+resource (newest remote job postings) and pins the source to NoDesk's public RSS feed, which is what distinguishes it from the dozens of other jobs_* siblings. It also enumerates the returned fields (title, company, link, publish time) and the company-extraction rule from the title.

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 source-specific framing — an agent can infer this is the NoDesk remote-jobs source — but there is no explicit when/when-not guidance and no sibling alternative named (e.g. jobs_we_work_remotely, jobs_weworkremotely). No prerequisites or exclusions are 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 and openWorldHint, and the description adds important non-schema behavior: the $0.002 per-successful-call x402 payment model, that failed calls are not charged, and that the data comes from public search JSON. It does not cover rate limits or auth details, but the cost disclosure is substantial.

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, region, and returned fields, then ends with pricing. It is mostly efficient, though the long list of output fields is somewhat redundant given that an output schema exists.

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 read-only search tool with rich schema coverage and an output schema, the description covers source, region, notable output characteristics, salary requirement, and cost. The main missing context is usage routing among many sibling job tools and any 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 three parameters are already documented in the input schema. The description reinforces the skill concept and mentions cities, but it does not add filtering semantics or examples beyond what the schema provides, so baseline 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?

The description clearly identifies the resource as No Fluff Jobs IT job postings for Poland and Central/Eastern Europe, filtered by a technology or skill. It distinguishes this source from generic job boards, though it does not use an explicit action verb like 'search' or 'retrieve'.

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 guidance on when to use this tool versus the many sibling job-board tools, nor are any alternatives or exclusions named. The regional and source context implies its niche, but an agent must infer selection criteria.

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 readOnlyHint and openWorldHint, so the safety profile is handled. The description adds meaningful context beyond them: figures are PayScale's own estimates, results are US-only annual USD, and each successful call costs $0.002 in USDC via x402 with no charge on failure — pricing/rate context an agent cannot get from the structured fields.

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, then source, input format, and pricing; every sentence carries information. The payment clause is slightly dense but material to invocation, so it earns its place.

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 and a single fully documented parameter, the description supplies everything the remaining gaps require: data source, currency and annual basis, US scope, input format, and per-call cost. Nothing an agent needs to call it correctly 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 coverage is 100% and the single `job` parameter is already documented in the schema with the same Software_Engineer example. The description reinforces the format constraint (match PayScale's URL spelling) but adds no new semantics beyond 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?

States a specific verb and resource: median pay for a job title from PayScale's public salary research page, returning annual USD compensation plus related career-path roles. That clearly separates it from the many sibling job-listing tools, which return postings rather than salary benchmarks.

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 gives clear context for use (a US salary lookup using PayScale's published estimates) and implicitly scopes out non-salary or non-US needs, but it never explicitly names an alternative or states when NOT to call it versus listing tools like jobs_glassdoor.

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 genuinely new behavior: metered pricing ($0.002 USDC per successful call via x402, Base/Solana/Arc) and that failed calls are not charged. It does not describe pagination or rate-limit behavior, so it stops short of 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?

Three tight sentences that front-load what the tool returns, then the addressing rule, then the pricing model. No filler and nothing buried.

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-value explanation is not required, yet the description still summarizes fields and discloses the per-call cost and one-company constraint. Minor omissions like failure modes (what happens when the subdomain doesn't exist) keep it below 5.

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 both parameters are already documented, establishing a baseline of 3. The description's subdomain-to-domain example ('bunq for bunq.recruitee.com') reinforces the company parameter's expected format but adds little the schema does not already say, and it says nothing about 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?

States a specific verb and resource ('Published openings on one company's public Recruitee careers site') and enumerates the returned fields, so the agent knows exactly what it gets. It does not explicitly differentiate itself from the many other job-board siblings beyond naming Recruitee as the source, which keeps it at 4.

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?

'One company per call' plus the subdomain example implies the usage shape, and the public-careers-site framing hints at scope. However, there is no explicit guidance on when to choose this over jobs_greenhouse_jobs, jobs_lever_jobs or other boards, and no stated exclusions.

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, and the description adds genuinely new behavioral context: a per-call price of $0.002 USDC via x402, the accepted payment networks, and the fact that failed calls are free. That is exactly the kind of operational detail annotations cannot carry, though return/pagination behavior is left to the output 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 sentences: the first front-loads what the tool returns and how to filter it, the second front-loads cost and payment mechanics. 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?

With an output schema present, the field listing is sufficient and the pricing/payment disclosure covers the main non-obvious risk of calling it. It could still say more about result limits or pagination behavior on large result sets, but nothing essential for a correct call 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 defaults and ranges are already documented per parameter. The description only echoes the filter names (keywords, location, distance, minimum salary) without adding syntax, formatting, or edge-case semantics 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?

The description names the specific source (Reed Jobs API), the geographic scope (UK), and the returned fields, so an agent can tell it apart from the many other job-board siblings. It stops short of an explicit comparison with those siblings, but the source and region are unambiguous.

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: the UK scope and named filter dimensions suggest when the tool fits, but there is no explicit 'use this when' guidance, no mention of alternatives among the numerous other job boards, and no exclusions (e.g. non-UK postings).

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, the description discloses cost ($0.002 USDC per successful call), the payment rails (x402 on Base, Solana or Arc), that failed calls are not charged, and the pagination ceiling (up to 100 ads per page, page 1–50). It also identifies the upstream source as SEEK's public job-search JSON service, which tells the agent about data freshness and coverage limits.

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 resource and source, followed by a compact pricing/pagination sentence — no filler. The long enumerated field list is dense but earns its place by telling the agent what columns to expect; only slight cost to readability.

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-value explanation is optional, yet the description still summarizes returned fields. Cost, payment mechanism, pagination limits and data source are all covered; the only gap is routing guidance relative to the dozens of sibling job boards.

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 is already documented in structured data; the description only restates the page-size ceiling and the general keyword/place framing. It adds no semantics beyond the schema, such as how `where` interacts with `country` or what relevance sorting optimizes for, 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 names a specific resource (SEEK Australia/New Zealand job ads), the query inputs (keywords + place), and enumerates the returned fields and total match count. It explicitly scopes to SEEK AU/NZ, which cleanly separates it from the many other job-board siblings such as jobs_indeed, jobs_reed_co_uk, or jobs_seekinalpha-style aggregators.

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 source and country scope — an agent can infer this is the tool for SEEK AU/NZ searches — but there is no explicit when-to-use/when-not statement or pointer to a sibling board for other regions. No prerequisites or exclusions are 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?

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses the upstream source (SEEK's public job-search JSON), explicitly names exclusions (full ad text and applicant data are absent), and states the billing model — $0.002 USDC per successful call via x402 and no charge on failure. Cost and failure-charging behavior are exactly the kind of context an agent cannot infer from 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?

Front-loaded with the resource and region, then the returned payload, then source, exclusions and pricing — a sensible order with no filler. The long enumeration of return fields is slightly redundant given an output schema exists, costing a point on tightness.

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?

Covers source provenance, data exclusions, cost model and regional scope, which is more than most listings. The only shortfall is that the field-by-field return list duplicates the existing output schema, and there is no note on pagination limits or result caps beyond the schema bounds.

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 page, pageSize, where, country and keywords are already documented in the schema. The description reinforces country scope and location filtering but adds no format or constraint detail beyond what the schema states, 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?

Names a specific verb and resource (SEEK job ads) plus the region (Australia/New Zealand) and enumerates the returned fields, so the purpose is unambiguous. However, it never distinguishes itself from the sibling jobs_seek, and the tool name 'jobs_seekingalpha' misleadingly evokes the finance site rather than SEEK, which the description has to correct.

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?

Usable context is implied: supply keywords plus an optional location and country (au/nz). But there is no explicit when-to-use guidance and no mention of when to prefer jobs_seek, jobs_indeed or other AU/NZ boards among the many siblings, so the routing decision is left 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 readOnly/openWorld, but the description adds substantial context beyond them: data is scraped from the public search page via a residential proxy, full descriptions are absent, and billing is $0.002 per successful call with failures not charged. These are exactly the operational facts an agent needs before spending 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-loads what is returned and the scope before the operational/pricing sentence, with no filler. The single long first sentence is dense but every clause carries information; only minor trimming is possible.

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?

Despite an output schema existing (so return values need not be spelled out), the description still names the fields, states the 20-result cap, notes absence of full descriptions, and discloses pricing. Nothing needed to call it correctly or budget for it 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 coverage is 100%, so all three parameters (q, limit, location) are already documented with examples and bounds. The description only echoes 'keyword and optional location' and 'up to 20', adding no syntax or format detail beyond 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?

States a specific verb and resource (SimplyHired job search, US), enumerates the returned fields, and bounds the scope to the first page (up to 20) plus total count. An agent can immediately distinguish it from the many other job-board siblings by source.

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 conditions: US market, single keyword plus optional location, first page only, no full job descriptions. It doesn't explicitly name an alternative (e.g., jobs_indeed or other boards) for non-US or deep-description needs, so the agent must infer routing from the geo qualifier.

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 annotations: discloses cost ($0.002 USDC per successful call), payment rails (x402 on Base, Solana, Arc), and that failed calls are not charged. It also sets expectations on what the response contains and excludes (no 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?

Front-loaded with purpose and the required parameter, then field list, then constraints, then pricing. Dense but nearly every clause earns its place; the run-on field enumeration is the only minor slack.

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 still usefully previews returned fields and exclusions, and it covers the cost/auth model that annotations don't express. An agent has everything needed to decide and call correctly.

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 this is baseline-plus: the description reinforces the 'company' parameter with a concrete example ('canva') and clarifies the one-company-per-call constraint, though it says nothing extra about the 'limit' parameter handled by 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?

States a specific verb and resource: 'Open postings of one company on SmartRecruiters' public Posting API'. Naming the source platform is exactly what distinguishes it from the dozens of sibling job-board tools, and it explicitly lists the fields returned.

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 usage context ('pass the company identifier, e.g. canva', 'One company per call') and a scope exclusion ('Descriptions are not included') that tells the agent when to look elsewhere for full job text. No explicit named alternative, but the platform-scoped nature makes the choice clear.

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 annotations: discloses the 30-result cap, the residential-proxy source, the exact price ($0.01 USDC per successful call via x402 on Base/Solana/Arc) and that failed calls are not charged. Cost and cap disclosure is exactly the context an agent needs before calling.

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?

Purpose, geography and result cap are front-loaded, and the pricing sentence is efficient. The long mid-sentence field enumeration is partly redundant given the output schema exists, making it slightly heavier than necessary.

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?

Covers source, geographic scope, result limits, cost model and output contents, so an agent can call it correctly; the output schema handles return-value detail. The only gap is the absence of guidance on when this board is the right choice versus other job sources.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.