AI Dev Jobs

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

With no annotations provided, the description carries the full transparency burden. It discloses transient processing, non-persistence of candidate evidence, absence of acceptance probability, rejection of hidden screening instructions, and lack of identity requirement. These are meaningful behavioral traits that go far beyond a simple read/write hint.

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 sentences, front-loaded with the core purpose, and packs in essential caveats (cost, identity, transient response, no persistence, no submission, security rejection) with zero 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?

No output schema exists, so the description must clarify the response nature. It does so by stating the response 'reports covered and unsupported public job signals without an acceptance probability.' Combined with full parameter schema coverage and no-annotation transparency, this is a complete picture for an analysis 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%, so parameters are already well-documented. The description adds some conceptual framing (e.g., 'candidate-verified evidence' links to evidence_bullets) but does not add new syntax or format details beyond 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?

The description opens with a specific verb and resource: 'Analyze candidate-verified evidence against one active job.' It clearly distinguishes this from sibling tools by noting it 'does not submit an application' and 'rejects hidden screening-model instructions,' making its purpose unmistakable versus apply_to_job or compile_job_specific_resume.

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: an identity-free, pre-application readiness check. It explicitly states what it does not do ('does not submit an application'), which serves as a when-not-to-use signal. However, it does not name alternative tools like apply_to_job directly, so it falls just short of explicit 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?

With no annotations provided, the description carries the full burden of disclosure. It reveals important guardrails: the artifact must be exact and visible, the hash requires human principal approval, the authorization is single-use, and 'candidates and agents are never charged'. It does not, however, mention side effects like irreversibility or what happens on failure, but it discloses the key behavioral constraints for a submission action.

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 concise sentences, front-loaded with the primary action and followed by essential requirements. Every clause adds meaningful information without redundancy, making it highly efficient.

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 tool with 5 parameters, no output schema, and no annotations, the description provides enough workflow context (phase after approval, required authorizations, no charge) to guide an agent. It could mention error handling or return behavior, but the absence of an output schema lowers the need. The key contextual information is present, making it fairly 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 baseline is 3. The description adds some context like 'email-verified' and 'single-use' but these are already partially captured in the schema (e.g., compiled_authorization_id already says 'Short-lived single-use authorization'). The description does not significantly alter or expand the understanding of any parameter 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?

The description clearly states the tool's function: 'Submit only the exact, visible compiled artifact' for a job application, with a specific verb ('submit') and resource ('compiled artifact'). It also distinguishes itself from sibling tools like compile_job_specific_resume and approve_compiled_application by emphasizing the final submission step after approval.

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 when to use the tool: after the 'email-verified human principal approves its hash', and it lists required prerequisites (single-use authorization, API key, principal_authorized=true). It implies the tool is not for initial compilation or approval, though it does not explicitly name alternatives or state when not to use it.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It reveals key side effects and constraints: the authorization is short-lived, single-use, requires principal_authorized=true, costs nothing, and does not submit an application. This gives the agent a clear safety profile and operational boundaries beyond 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?

The description is two sentences with no fluff. It front-loads the main verb and resource, then packs key constraints into the first sentence, with additional conditions in the second. Every clause adds value.

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 tool with 3 parameters and no output schema, the description covers purpose, prerequisites, side effects, and a key exclusion (no application submission). It omits an explicit pointer to the next step (e.g., 'use apply_to_job after approval'), which would make the workflow fully clear, but the sibling list and general context make this implicit.

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% description coverage for all three parameters. The description adds context about the artifact hash being exact and the principal authorization condition, but this largely reinforces existing schema descriptions rather than introducing new parameter-level meaning. 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 states the action ('Create a short-lived, single-use authorization') and specifies the exact scope (one email-verified candidate, one artifact hash, one unchanged active job). It also distinguishes itself from sibling tools by explicitly noting it 'does not submit an application', making it clear this is not apply_to_job.

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 on when to use this tool: as an authorization step requiring principal_authorized=true, before submission. It implies a workflow (after compile_job_specific_resume, before apply_to_job) and explicitly states it does not submit an application, which contrasts with the sibling apply_to_job. However, it does not name alternative tools explicitly or state 'when not to use' in the most direct terms.

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

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

With no annotations provided, the description fully discloses behavior: it explains the transient preview without identity, the persistent draft hash with a verified key, the requirement to pause for human review, and the prohibition on submission. This is exceptionally transparent about side effects and conditions.

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 primary purpose, then covering conditional behavior and limitations. Every sentence adds essential information without redundancy. It is concise given the tool's complexity.

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?

No output schema exists, but the description explains the return behavior: transient preview without identity, immutable draft hash plus candidate_review handoff with a verified key. It also mentions the pause for human review. For a tool with authentication-dependent behavior, the description is 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 explains the parameters. The description adds some semantic context (e.g., 'candidate-verified evidence' maps to the verified flag), but it does not provide per-parameter syntax or format details. It meets the baseline for covered schemas.

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 ('Compile') and identifies the resource ('job-specific resume') with clear constraints: candidate-controlled, ATS-oriented, plain-text Markdown, one active job, candidate-verified evidence only. It effectively distinguishes itself from siblings like apply_to_job and approve_compiled_application by stating it only compiles a draft and never submits.

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: it's for compiling a draft from verified evidence, not for submission. It explicitly states 'Never submits or authorizes an application,' which is a when-not. However, it does not name specific alternative tools or explicit exclusions, 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?

With no annotations, the description carries the burden of disclosing behavior. It enumerates the output fields, which is helpful, but it does not mention error conditions, authentication, rate limits, or any side effects. For a read-only tool, the description is adequate but not richly transparent.

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 sentences long, front-loads the tool's purpose and return contents, and immediately follows with usage guidance. Every word earns its place with zero 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?

Given the tool is simple (one parameter, no output schema), the description covers the main return fields and provides usage context. It lacks mention of possible empty results or errors, but overall it is sufficiently complete for an AI agent to invoke 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% and the parameter 'slug' already includes an example and instruction to use the slug from search_jobs or list_companies results. The description reinforces this usage but adds no new semantic detail beyond the schema, so it meets the baseline without elevating.

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 gets a detailed company profile and enumerates specific contents (open roles, salary range, top tags/skills, workplace distribution, apply URL). This distinguishes it from sibling tools like get_job or get_salary_data, which focus on other entities.

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 advises using this tool after list_companies or search_jobs to learn more about an employer, providing clear context. However, it does not mention when not to use it or alternative tools, so it stops short of full exclusion 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?

No annotations are provided, so the description must convey behavioral context. It describes the content delivered but does not explicitly state whether the operation is read-only, requires authentication, or how errors are handled, leaving some transparency gaps.

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 concise sentences with no redundancy: the first lists the returned data, the second gives usage guidance. Every word adds value.

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 single-parameter fetch tool without an output schema, the description sufficiently covers what data will be returned and the recommended usage context. No critical information is missing.

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

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

The input schema already fully documents the single parameter 'id' as a UUID or slug (100% coverage). The description adds no new parameter semantics beyond restating that it accepts an ID or slug, so it meets the 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?

The description explicitly states 'Fetch full job posting by ID or slug' and enumerates the fields returned, clearly distinguishing it from sibling tools like search_jobs (which searches) and get_company (which fetches company info).

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 instruction 'Use after search_jobs to read a specific listing' explicitly tells the agent when to invoke this tool relative to its primary sibling, establishing a clear workflow.

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

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

With no annotations provided, the description carries the full burden. It discloses the output shape (average, median, p25, p75, min, max, and sample count) and implies a read-only operation via the 'get' verb. It could mention data recency or limitations, but for a simple lookup tool, this is adequate.

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 four short sentences, front-loaded with the core purpose. Each sentence adds value: scope, filters, output, and typical use case. There is no fluff or repetition.

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 covers the tool's purpose, input filters, output metrics, and intended use case. With no output schema, it appropriately describes return values. Minor missing details like filter combinability or default behavior are not critical for tool selection.

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 100% of parameters with descriptions, and the tool description merely echoes the same filter concepts (tag, level, workplace, company) without adding new meaning. This aligns with the baseline of 3 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 clearly states the resource ('salary benchmarks for AI/ML roles') and the action (get/filter). It specifies available filters and the returned metrics, making it distinct from sibling tools like search_jobs or get_company.

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 mentions its usefulness for 'compensation research and negotiation', providing clear context for when to use it. However, it does not mention any alternatives or exclusions, so it lacks the explicit 'when not to use' guidance required for 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the matching criteria (tag overlap, workplace, level, job type), ranking mechanism (similarity score, tag overlap weighted 3x), and the 'active jobs' filter. It does not detail response format or edge cases, but for a read-only tool, this is substantial transparency.

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 sentences, front-loaded with the core function, and every phrase conveys meaning. It efficiently includes the matching criteria, ranking weighting, usage context, and endpoint mapping without redundancy or 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 the tool's simplicity (2 params, no output schema, no annotations), the description adequately covers purpose, usage, behavior, and parameters. It could mention pagination or empty results, but the provided details are sufficient for an agent to select and invoke the tool correctly in most scenarios.

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. The description adds value by noting that the id parameter is 'the same identifier get_job accepts,' which clarifies cross-tool compatibility, and it mentions the default limit of 5, which the schema does not specify. This enriches the parameter semantics beyond the schema alone.

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: 'Given a job ID or slug, return active jobs that match on tag overlap, same workplace, level, and job type.' It specifies the verb 'return' and the resource, distinguishing it from siblings like search_jobs (which searches broadly) and get_job (which returns a single job). The mention of the REST endpoint further clarifies its role.

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 explicit context: 'Use after search_jobs to surface nearby roles.' This tells the agent when to invoke the tool relative to a common workflow. It does not explicitly list exclusions or alternative tools, but the usage guidance is clear and actionable, which places it above a generic description.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that there is no payment handoff, which is a relevant side-effect disclosure for a stats tool. However, it does not mention whether the operation is read-only, return format, freshness, or rate limits. The single safety statement adds some value but leaves room for more transparency.

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 extremely concise: two sentences, front-loaded with the main content, and no wasted words. The second sentence adds a crucial behavioral note about payment handoff, making every sentence earn 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?

Given no parameters and no output schema, the description stands as the primary source of information about what the tool returns. It lists specific data points, making the tool's functionality clear. It could be improved by explicitly stating the tool's aggregate/read-only nature, but for a zero-param tool, the description is sufficiently 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?

The tool has zero parameters, so there is no parameter burden. The description adds no parameter-specific semantics, but none are needed. Per the rubric, a zero-parameter tool receives a baseline of 4, and the description's enumeration of output fields is sufficient given no parameters exist.

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 what the tool returns: aggregate index statistics such as total active jobs, companies hiring, median salary, new jobs, and trending tags. While it lacks an explicit verb like 'retrieves' or 'returns', the resource and scope are specific enough to distinguish it from sibling tools like get_salary_data or get_trending_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 implies usage by listing the available content, but it does not explicitly state when to use this tool versus siblings like get_salary_data or get_trending_companies. The note about being 'free index data' and not creating a payment handoff gives a useful context signal but does not provide clear alternative selection 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns company name/slug/logo plus the count of new jobs, and that it counts jobs within the specified look-back window. This provides useful behavioral context beyond the name, though it doesn't explicitly state it's read-only (implied by 'get') or mention any side effects.

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, then differentiation, then return value details. Every sentence contributes meaningful information with no fluff or repetition.

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 has only two optional parameters, no output schema, and no annotations. The description mentions the key output fields (company name/slug/logo and job count), the selection criterion (most AI/ML jobs), and the time window concept. It is sufficiently complete for an agent to understand what the tool does and what it returns.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds some context by explaining that 'days' controls the look-back window for job counts, but it doesn't add meaning for 'limit' beyond what the schema already specifies. Minimal additional semantic value over 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 clearly states the tool's purpose: to list companies posting the most AI/ML jobs in a given time window. It uses a specific verb+resource structure and explicitly contrasts with the sibling tool get_stats trending_tags_7d, distinguishing what this tool answers versus that one.

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 explicit when-to-use guidance by comparing to get_stats trending_tags_7d: 'while that answers what skills are trending, this answers who's hiring most aggressively'. This gives clear context for choosing this tool over the alternative.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It explains the primary behavior (top companies by active role count) but introduces ambiguity by saying 'optionally with average salary' without a corresponding parameter in the schema, suggesting an unsupported option. It lacks details on authentication, rate limits, sorting order, or response format.

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: two sentences with no redundant wording. The first sentence states the core functionality, and the second adds a practical use case, making it easy to scan.

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 tool with one optional parameter and no output schema, the description is adequate but has gaps. It doesn't clarify the output structure, whether results are sorted descending, or how the optional average salary is requested or represented. The ambiguity about salary reduces completeness.

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 for the sole parameter 'limit' is 100%, with explicit default and max values. The description adds no extra meaning for this parameter. However, the mention of 'average salary' as optional is misleading and may confuse the agent about whether additional parameters exist.

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 'Returns top AI/ML companies by active role count', using a specific verb and resource. It distinguishes from siblings like get_company (single company) and get_trending_companies (trending) by emphasizing hiring activity in AI.

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 phrase 'Useful for discovering who is hiring in AI' implies a usage scenario but does not explicitly compare with alternatives or state when not to use it. There is no mention of alternative tools like get_company or get_trending_companies, leaving the guidance implicit.

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

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

With no annotations, the description carries the full burden. It adds a behavioral detail ('No candidate fee is ever created') and identifies the data source ('employer-reported'). However, it does not clarify whether the operation is strictly read-only, describe authentication nuances, or explain potential side effects beyond the fee statement.

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 concise sentences with no fluff. The first sentence immediately states the action and scope, while the second adds a relevant behavioral assurance. Every word 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?

The description is adequate for a simple list operation but leaves out what the response contains (e.g., fields of outcomes, pagination, or filtering). The title says 'Confirmations' while the description says 'outcomes,' which may confuse users. Without an output schema, more detail would be helpful.

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 has no parameters, so there is nothing for the description to explain. Baseline 4 is appropriate since the description correctly implies no parameters are needed.

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 'List employer-reported interview outcomes' with a specific verb and resource, and scopes it to 'applications submitted with the authenticated developer API key.' This distinguishes it from sibling tools like 'respond_to_interview_outcome' and other list 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?

It provides clear context on when to use the tool (for applications submitted with the developer API key) and implies it is for reading outcomes. However, it does not explicitly mention alternatives or exclusions, so it stops 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?

With no annotations, the description carries full transparency burden. It clearly states the tool is read-only regarding ranking ('It never changes organic ranking'), discloses the zero-cost nature for candidates/agents, and gives specific conditions under which billing occurs. This is substantial behavioral disclosure, going beyond a simple 'returns the product' statement.

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 long, front-loaded with the core function, and every sentence adds distinct value: purpose, pricing/free access, and side-effect/ranking guarantee. It is dense but not bloated, 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?

Given there is no output schema and no parameters, the description fully covers what an agent needs to know: what the product is, who pays, when billing applies, and that no side effects (ranking changes) occur. This is complete for a tool that simply returns a single product listing.

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 has zero parameters, so the baseline is 4. The description adds meaning about the return value (the Verified Interview Pilot) and its terms, which is appropriate for a no-parameter tool. No param-level explanation is needed 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 opens with a clear verb and resource: 'Returns AI Dev Board's only agent-readable commercial offer.' It names the specific product (the employer-funded Verified Interview Pilot) and distinguishes this tool from siblings like list_companies and list_tags by highlighting its unique role as the only agent-readable offer. This leaves 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?

The description implies use when an agent needs to retrieve AI Dev Board's commercial offer, but it does not explicitly contrast with alternatives like quote_product or start_checkout. While it explains when the product becomes billable, there is no direct 'use this instead of X' guidance. The uniqueness statement ('only... commercial offer') hints at sole purpose, but leave selection criteria implicit.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It implies a read-only operation by saying 'Returns' and adds the specific behavior of returning active job counts per tag. However, it does not disclose details like sorting, whether tags with zero active jobs are included, or any access restrictions, which leaves some ambiguity.

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 sentences with no filler. The first sentence front-loads the core behavior (returns tags with counts), and the second provides a direct usage instruction. Every word 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 tool with no parameters and no output schema, the description fully covers the return value (tags and counts) and the reason to use it (as a precursor to search_jobs filtering). The context signal of sibling tools is reinforced by naming search_jobs, making this complete for a simple lookup 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 tool has zero parameters, so the baseline is 4. There is nothing to explain; the description correctly focuses on the return value instead of inventing parameter details.

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 'Returns' and a clear resource 'all available job tags/skills' with an additional detail (count of active jobs). This distinguishes it from sibling tools like search_jobs, which filter jobs, while this tool lists the tags themselves.

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 says 'Use to discover what tags are available for search_jobs filtering,' naming the exact downstream use case and the target tool. It doesn't mention when not to use, but for a simple list tool this provides clear context without needing 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?

With no annotations, the description carries the full burden of behavioral disclosure. It delivers thoroughly: explains the scoring formula (+2 tag overlap, +3 salary overlap, etc.), states the tool is free, reveals identity requirements ('without identity', 'verified key required only to save an approval-bound artifact'), and clarifies that the employer outcome pilot never affects matches. This goes far beyond a typical description.

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 long and front-loaded with the primary purpose. Each subsequent sentence adds relevant detail (scoring, costs, identity, follow-up tool). It wastes no words, though it is slightly longer than necessary and could be more succinct by trimming the secondary caveats.

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 8 parameters, no output schema, and no annotations, the description is quite complete: it covers purpose, scoring logic, cost, identity requirements, and a related follow-up action. The main gap is that it does not describe the return format or expected output structure, which would be useful for a ranking tool. Still, the behavioral and parameter context is unusually rich.

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 63%, leaving 37% of parameters without schema descriptions. The description compensates by mapping scoring components to parameter groups: 'tag overlap' refers to skills, 'salary overlap' to salary_min/max, and 'workplace/level/type/location matches' to those respective parameters. This adds meaningful context beyond the schema, though it does not explain individual parameter formats or limits 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 clearly states the tool's function: 'Rank active AI/ML jobs against a candidate profile for free.' This is a specific verb ('rank'), resource ('AI/ML jobs'), and target ('candidate profile'), and it distinguishes match_jobs from sibling tools like search_jobs and get_similar_jobs by emphasizing profile-based scoring.

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 some usage context by mentioning compile_job_specific_resume as a follow-up after selecting a role, but it does not explicitly state when to use match_jobs versus alternatives like search_jobs or analyze_application_readiness. The intended use is implied rather than explicit, so exclusions and alternatives are missing.

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

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

With no annotations, the description must carry the full burden. It discloses that no candidate or agent is charged and that the result is deterministic and outcome-only, but it does not clarify whether this is a read-only operation, what authentication is required, or what happens on invalid input. The 'outcome-only' phrasing is vague and does not fully guarantee absence of side effects.

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 concise sentences, with the primary purpose stated first. No redundant words, and every sentence adds relevant information. Well-structured and easy to parse.

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 one-parameter tool, the description covers the purpose, active product, and retired IDs. However, it lacks a description of the return format or structure of the 'terms,' and there is no output schema to clarify this. It also does not explain how this tool relates to the broader commerce flow, making it somewhat incomplete.

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 description already provides 100% coverage by stating the only active value for product_id. The description adds valuable context by mentioning that legacy package, sponsorship, and Dossier product IDs are retired, reinforcing the schema's restriction and giving extra meaning 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?

The description clearly states the tool 'Returns the deterministic, outcome-only terms' for a specific product (AI Dev Board's Verified Interview Pilot). It distinguishes from siblings by focusing on the pilot and noting legacy product IDs are retired, though it could be more explicit about how it differs from list_products or start_checkout.

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: use this to obtain terms for the Verified Interview Pilot. The description notes that legacy package, sponsorship, and Dossier product IDs are retired, which discourages using this tool for those. However, it does not explicitly state when to prefer this over sibling tools like list_products or when not to use it.

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?

Since there are no annotations, the description carries the full burden and does well: it discloses that the record is candidate-reported (not employer-verified), creates no acceptance-rate claim, and never changes organic ranking. It also mentions the $0 cost and explicit authorization requirement. This goes beyond simple 'record' and gives meaningful behavioral caveats, though it doesn't detail mutation semantics (e.g., idempotency, overwriting).

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 the core purpose, and every phrase adds value (email-verified, explicitly authorized, fixed-taxonomy, $0, receipt caveats). No filler or repetition of schema 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?

For a simple recording tool with 3 required parameters and no output schema, the description is fairly complete: it covers what is recorded, under what conditions (authorization), and the non-effects (no ranking change). It could mention the return value or how to obtain the application_id, but the schema already references apply_to_job. Overall, it's sufficient for an agent to invoke 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 67% (application_id and principal_authorized have descriptions, outcome only has enum). The description adds context like 'fixed-taxonomy' (aligning with the enum) and 'explicitly authorized' (matching principal_authorized), but does not explain the outcome values or additional parameter syntax. It adds some value but does not fully compensate for the missing outcome 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 a specific action ('Record'), a specific resource ('application outcome'), and scope ('one email-verified candidate's explicitly authorized, fixed-taxonomy application outcome'). It distinguishes from sibling tools like apply_to_job (which creates applications) and respond_to_interview_outcome (which handles interview responses), making it clear this is for recording a final/ongoing outcome.

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 (record an outcome after a candidate authorizes it, at no cost, without affecting ranking) but does not explicitly mention when to use this tool versus alternatives. It lacks explicit exclusions or guidance like 'use this instead of respond_to_interview_outcome for application-level outcomes.' The context is clear but not formally differentiated.

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

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

With no annotations, the description carries the behavioral disclosure burden. It reveals that explicit principal authorization is required, the response must be independent, and confirmation can trigger a billable employer fee while candidates/agents pay $0. It does not mention dispute side effects or return format, but the fee implication is a strong, non-obvious 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?

The description is three short sentences with no filler; every sentence adds substantive information about purpose, authorization, and financial impact.

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 3-parameter tool with no annotations, the description covers purpose, authorization, and fee consequences. However, it omits the provenance of outcome_id, behavior for a dispute, and whether a response can be changed, which are relevant contextual gaps.

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 only 33%, so the description must compensate. It clarifies candidate_confirms_interview via 'Confirm or Dispute' and principal_authorized via 'explicit principal authorization,' but outcome_id is left to naming convention and its source is not mentioned.

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 the tool records the candidate's independent response to an employer-reported interview, with a specific verb and resource. The title clarifies the two possible actions (confirm or dispute), and the fee consequence distinguishes it from list-only 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 implies it is used when a candidate needs to respond to an interview outcome, but it does not explicitly state when to use it versus alternatives like list_my_interview_outcomes. The authorization requirement provides context but no exclusion or alternative 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?

With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool is free, results are curated, and the employer outcome pilot never affects organic results. It also explains identity and key requirements for saving approval-bound artifacts, offering important context about privacy and authorization.

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: purpose and cost, filter list, and downstream behavior. Every sentence carries meaningful information and the main action is front-loaded. No redundant or vague wording.

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 tool with 11 optional parameters and no output schema, the description is impressively complete. It covers purpose, filter scope, cost, privacy/identity, and result integrity (pilot). While it lacks an explicit return format, the extensive behavioral disclosures make it sufficient for an agent to decide and invoke 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?

The schema covers 100% of parameters with detailed descriptions (e.g., salary_min range overlap, posted_within_days polling suggestion). The description adds high-level filter categories like tags, workplace, and keyword, but does not add per-parameter details beyond the schema, so the baseline of 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 states 'Search curated AI/ML engineering roles for free' with a specific verb and resource. It distinguishes from sibling tools like match_jobs and get_similar_jobs by focusing on search and filtering rather than matching or similarity.

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 on when to use the tool—to search and filter job listings across multiple dimensions (tags, workplace, level, salary). It references compile_job_specific_resume as a downstream step, but does not explicitly state when not to use it or name alternatives like match_jobs for matching use cases.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly describes the tool as non-charging, states that it creates no request/program/candidate action/invoice/charge, and clarifies that fields like work_email and employer_name are only included in the returned template, not submitted. This is excellent transparency beyond 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?

The description is two sentences and front-loaded with the primary action ('Returns a non-charging owner-review request template') followed by a concise list of exclusions and prerequisites. Every clause earns its place with no 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?

For a 7-parameter tool with no output schema and no annotations, this description is remarkably complete. It tells the agent what is returned, what is not created, and the required preconditions before a subsequent review request can be submitted. Combined with the detailed schema, there are no significant contextual gaps.

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?

Input schema coverage is 100%, so the schema already provides complete parameter semantics. The description's mention of required identity, authority, and terms acknowledgment loosely maps to parameters but adds little new information beyond emphasizing prerequisites. 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 states a specific action: it returns a non-charging owner-review request template for the Verified Interview Pilot only. It also clarifies what it does not do (creates no request, program, candidate action, invoice, or charge), which sharply distinguishes it from sibling tools like apply_to_job or quote_product.

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: the tool is for the Verified Interview Pilot only and is a prerequisite step before a separate review request can be submitted. It states required conditions (employer identity, exact-role authority, acknowledgment of capped terms) but does not explicitly name alternative tools or state when not to use it, so it stops 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.