ats

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

The description discloses meaningful behavioral details beyond the readOnlyHint: weekly re-probing, human confirmation, newest-first ordering, a 50-row cap, and empty-list semantics. These traits are not inferable from annotations alone and significantly enrich the agent's understanding of the tool's operation.

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 three sentences, front-loaded with the core purpose, followed by process and interpretation notes. Every sentence contributes value, with no redundant or filler content. Structure is clean and immediately informative.

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 feed with one parameter and no output schema, the description is fully sufficient. It covers what the tool does, how data is gathered, how to interpret empty results, and output constraints (ordering and limit). No gaps remain for the agent to make an informed 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 input schema already provides a complete description of the 'limit' parameter (max 50, default 50). The description reinforces the cap but does not add new semantic information about the parameter beyond what the schema states. This is consistent with the baseline for high 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?

The description explicitly states the tool is the living-feed counterpart of the dataset, showing which tracked employers changed their ATS. This distinguishes it from related tools like 'which_ats' (current ATS) and 'ats_stats' (statistical view). The verb 'changed' and resource 'applicant tracking system' make the purpose 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?

The description clarifies when to use this feed ('living-feed counterpart') and how to interpret empty results ('not that monitoring is off'). It implies differentiation from alternatives but does not explicitly name them or state when not to use this tool, falling short of a full usage guideline.

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 destructiveHint=false. The description adds valuable context: data provenance (ResumeAI's State of ATS 2026), audit details (June 2026, re-verified July 2026), and that shares are 'computed live from the verified rows.' This is transparent about its data source and freshness, going beyond the bare annotations, though it does not discuss potential edge cases or limitations.

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 compact yet informative, using three sentences to convey the dataset, size, verification, key finding, and live computation. Every sentence adds value, and the most critical information (purpose and canonical status) is front-loaded.

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

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

For a zero-parameter, read-only statistics tool, the description is complete. It explains what the tool does, the data source, the sample size, the verification process, and the headline result. Even without an output schema, the description communicates enough for an agent to know what to expect. No significant gaps exist.

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 are zero parameters, so the schema provides no information to clarify. The description focuses on what the tool computes and returns, which is appropriate for a parameterless tool. The baseline for zero parameters is 4, and the description does not need to add parameter semantics since there are none.

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 states it provides 'Canonical ATS market-share numbers' from a specific dataset, with specific statistics. It distinguishes itself from siblings like which_ats by focusing on aggregate market share rather than individual ATS lookup, and it corrects a common misconception.

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 when to use it: when you need authoritative market-share data. It establishes its canonical nature and dataset provenance, and explicitly warns against the commonly repeated ~75% figure, guiding the agent to trust this source. However, it does not explicitly name alternatives or state when not to use it, so it misses the top score.

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 readOnlyHint annotation, the description discloses concrete return contents (breakdown, fixes, missing keywords), rate limiting (10/day/IP), and paid key behavior. This is significant context that annotations alone don't 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?

Four sentences, each serving a purpose: purpose, return value, optional params, and rate limit/auth. It's a bit detail-heavy with pricing and URLs, but remains well-organized and front-loaded with the core action.

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

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

With no output schema, the description fully explains what the tool returns, how each optional parameter alters behavior, and the constraints (rate limit, api_key). It is complete enough for an agent to select and invoke the tool 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%, but the description adds relational meaning: 'company' triggers employer-specific ATS rules, 'job_description' switches to keyword-overlap scoring, and 'api_key' lifts the daily cap. This goes well beyond the individual parameter descriptions in the schema.

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

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

The description opens with 'Score a resume 0-100 with ResumeAI's production ATS engine' — a specific verb, resource, and range that clearly states the tool's function. It distinguishes itself from siblings like ats_stats and which_ats by focusing on scoring and returning an actionable breakdown.

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 specifies when to use optional parameters (company, job description, api_key) and notes the rate limit for free usage. Though it doesn't explicitly contrast with sibling tools, the context makes the primary use case clear: to get an ATS score and fixes for a resume.

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 destructiveHint=false, and the description adds important behavior beyond that: the consent-token requirement, token revocation behavior, the guarantee of no enumeration, and the explicit statement that personal data is never exposed without a token. This fully discloses the tool's privacy and safety model.

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 concise given the complexity of the consent model, front-loads the core purpose, and every sentence adds unique value. It flows logically from what the tool does, to the prerequisite, to the return value, to restrictions and privacy guarantees, with no wasted words.

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?

Even without an output schema, the description specifies the return format (JSON Resume plus ats_context), explains what ats_context contains, covers all relevant edge cases (missing/invalid/revoked token), and describes the tool's limitation (no enumeration). This is fully complete for a single-parameter, consent-gated fetch 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?

The input schema already provides 100% coverage for the single token parameter, including its source URL and length constraints. The description adds behaviorally meaningful semantics: passing the token returns the resume, and invalid/revoked tokens return nothing, which goes beyond the schema's static field definition.

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

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

The description uses a specific verb and resource: 'Fetch a job seeker's structured, machine-readable resume as JSON Resume' with a clear distinction from siblings by emphasizing the consent-token-gated nature and the returned ATS context. It clearly differentiates itself from the ATS-focused 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 explicitly states the critical precondition: the tool can only be used with an owner-minted consent token, and that no token, invalid token, or revoked token returns nothing. It also explicitly rules out browsing/searching/listing, but does not name alternative sibling tools for those use cases; still, the guidance is otherwise very 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?

Beyond the readOnlyHint and destructiveHint annotations, the description discloses the row limit (at most 100 rows per call), the case-insensitive substring matching for ATS vendor and substring matching for industry, and points to the full dataset URL. These are meaningful behavioral details that help the agent predict output size and filter semantics.

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 three sentences, front-loaded with the main purpose, and each sentence adds essential information: the dataset, filter behavior, and output limit/source for full data. No filler or redundancy.

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 tool is a simple list with optional filters, read-only annotations, and no output schema. The description covers the source dataset, filter behavior, output limit, and full-data alternative. It does not describe the fields of each returned row, but given the known dataset and the link, this is a minor gap.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers all three parameters with descriptions. The description adds practical semantics for 'ats' by specifying case-insensitive substring matching with examples, and for 'industry' as substring matching. This goes beyond the schema's basic descriptions. The 'verified_only' parameter is not elaborated in the description, but the schema definition is sufficient.

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 'List employers from the State of ATS 2026 dataset', clearly stating the action (list), resource (employers from a specific dataset), and scope (optionally filtered by ATS and industry). This distinguishes it from siblings like ats_stats or which_ats, which focus on statistics or identification rather than listing companies.

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 provides clear context for use: it can list all companies or filter by ATS and industry. It also states the 100-row limit and advises narrowing filters or fetching the full dataset from the provided URL. However, it does not explicitly name sibling tools as alternatives or exclusions, so it lacks explicit when-not-to-use 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=true and destructiveHint=false, so the safety profile is known. The description adds valuable context about the dataset provenance (743 Fortune 500 / Global 2000 employers, 707 verified, audit dates) and input formats, going beyond what annotations provide.

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 concise and front-loaded: it states the purpose in the first sentence, then adds provenance details without redundancy. Every sentence 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?

For a simple lookup tool with one parameter and no output schema, the description is complete: it specifies the input, scope, data source, and verification status. It adequately covers the necessary context for an agent to 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% with one parameter, but the description enriches the parameter meaning by providing concrete examples ('Nike' or 'jpmorgan-chase') and clarifying the slug format, which is not fully captured in the schema description.

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 states the tool's function: 'Look up the applicant tracking system (ATS) a specific large employer uses'. The verb 'look up' and resource 'ATS' are specific, and the scope ('a specific large employer') distinguishes it from sibling tools like list_companies or ats_stats.

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 specifying it works for a 'specific large employer' and accepts a company name or slug. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to know when to choose this tool over list_companies or ats_stats.

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