AI Dev Jobs

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 implies a read-only operation ('Get') but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or response format. The description adds some context about the data returned but lacks operational details.

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 efficiently structured in two sentences: the first states the purpose and details, and the second provides usage guidance. Every sentence adds value without redundancy, making it appropriately sized and 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?

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is reasonably complete. It covers purpose, usage context, and data returned, though it could benefit from more behavioral transparency (e.g., response format or error cases) to fully compensate for the lack of annotations and output schema.

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 the single required parameter 'slug' with its type and usage example. The description doesn't add any parameter-specific information beyond what the schema provides, maintaining the baseline score 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 specific action ('Get detailed profile') and resource ('an AI company'), listing concrete data points like total open roles, salary range, top tags/skills, workplace distribution, and apply URL. It distinguishes from siblings by focusing on company profiles rather than jobs, salaries, or listings.

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 when to use this tool ('Use after list_companies or search_jobs to learn more about a specific employer'), providing clear context and naming specific alternative tools for different purposes, which helps the agent select the right tool.

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 describes what the tool does (fetch details) and the input (ID or slug), but lacks behavioral details like error handling, permissions needed, or rate limits. It adds some context (e.g., fields returned) but doesn't fully compensate for the missing annotations, resulting in an average score.

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 the core purpose, followed by a usage guideline, all in two efficient sentences. Every sentence adds value without redundancy, making it appropriately sized and well-structured.

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 low complexity (1 parameter, no output schema, no annotations), the description is mostly complete: it states the purpose, usage, and fields returned. However, it lacks details on output format or error cases, which could be helpful. Since no output schema exists, some explanation of return values might be expected, but the description is sufficient for basic use.

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 100% description coverage, with the 'id' parameter documented as 'Job ID (UUID) or slug'. The description adds marginal value by reiterating 'by ID or slug' and implying it's used after search_jobs, but doesn't provide additional syntax or format details beyond the schema. Baseline 3 is appropriate when schema coverage is high.

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 ('fetch full job posting') and resource ('by ID or slug'), listing specific fields returned (title, description, etc.). It distinguishes from sibling tools by mentioning 'use after search_jobs' to get a specific listing, differentiating from the broader search 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?

The description explicitly states when to use this tool ('use after search_jobs to read a specific listing'), providing clear context for its application. It implies an alternative (search_jobs) for initial discovery, though it doesn't explicitly state when not to use it, but the guidance is sufficient for a high 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully describes what the tool returns (statistical metrics) and its use cases, but doesn't mention important behavioral aspects like whether this is a read-only operation, potential rate limits, data freshness, or authentication requirements. The description adds value but leaves significant behavioral questions unanswered.

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 perfectly structured and concise - three sentences that each earn their place. The first establishes purpose, the second explains filtering and returns, the third provides use cases. No wasted words, front-loaded with core functionality, and appropriately sized for 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?

For a read operation with no output schema and no annotations, the description provides adequate but incomplete context. It explains what data is returned but not the format or structure. Given the statistical nature of the returns (average, median, percentiles), more detail about the output format would be helpful. The description covers basics but leaves gaps for a tool that returns complex statistical data.

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 100% description coverage, so the schema already documents all four parameters thoroughly. The description mentions filtering by the same parameters but doesn't add meaningful semantic context beyond what's in the schema descriptions. It provides a high-level overview but no additional syntax, format, or constraint 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 clearly states the tool's purpose with specific verbs ('Get', 'Filter', 'Returns') and resources ('Salary benchmarks for AI/ML roles'). It distinguishes itself from sibling tools like 'get_job' or 'search_jobs' by focusing specifically on compensation data rather than job listings or company information.

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 implied usage context ('Useful for compensation research and negotiation') but doesn't explicitly state when to use this tool versus alternatives like 'get_stats' or 'list_companies'. No guidance is given about when NOT to use this tool or what specific scenarios warrant its selection over sibling tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it returns 'active jobs' (implying a filter), ranks by 'similarity score' with specific weighting, and matches a REST endpoint (suggesting consistency with API behavior). However, it lacks details on error handling, rate limits, or authentication needs, which are minor gaps given the 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?

The description is front-loaded with core functionality and efficiently structured in two sentences. Every sentence adds value: the first explains what the tool does and how it works, and the second provides usage guidance and endpoint reference. There is no wasted text, making it highly concise and well-organized.

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 moderate complexity (2 parameters, no output schema, no annotations), the description is largely complete. It covers purpose, usage, and behavioral aspects well. However, without an output schema, it doesn't detail the return format (e.g., structure of similar jobs), which is a minor gap. Overall, it provides sufficient context for effective use.

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 both parameters ('id' and 'limit') thoroughly. The description adds minimal value beyond the schema by implying the 'id' parameter can be a 'job ID or slug' and referencing 'get_job' for context, but it doesn't provide additional syntax or format details. This meets 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 clearly states the tool's purpose with specific verbs ('return active jobs') and resources ('similar jobs'), and distinguishes it from siblings by mentioning it matches a specific REST endpoint. It explains the matching criteria (tag overlap, workplace, level, job type) and ranking method (similarity score with tag overlap weighted 3x), making the purpose highly specific and differentiated.

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 usage guidance by stating 'Use after search_jobs to surface nearby roles,' which gives clear context for when to invoke this tool versus alternatives. It also references the sibling tool 'search_jobs' directly, offering a specific alternative for initial job discovery, making the guidelines comprehensive.

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 full responsibility. It describes the tool as returning statistics, which is a read operation with no side effects mentioned. However, it does not disclose any behavioral details such as caching, rate limits, or authorization requirements. The description is adequate but not rich in behavioral 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?

The description is a single well-structured sentence that is front-loaded with the tool's purpose. It lists the specific statistics returned without any fluff or redundant information, making it highly concise and 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?

Given the tool's simplicity (no parameters, no output schema), the description fully explains what the tool returns: a set of key statistics. It mentions the time frame for trending tags (last 7 days) and covers all essential data points. No additional context seems necessary 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 tool has zero parameters and the input schema coverage is complete (100%). According to guidelines, zero parameters baseline is 4. The description adds no parameter information, but none is needed as there are no parameters to explain.

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 aggregated index statistics for AI Dev Jobs, listing specific data points like total active jobs and trending tags. This is a specific verb-resource combination that distinguishes itself from sibling tools which focus on individual entities or search.

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 for getting an overview of job market statistics, but it does not provide explicit guidance on when to use this tool versus siblings, nor does it mention prerequisites or conditions. The context is clear from the tool name, but the description lacks direct comparative advice.

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 describes what the tool returns (company name/slug/logo plus job count) and the time-based filtering logic, but doesn't mention rate limits, authentication requirements, or error conditions. For a read operation with no annotations, this provides basic but incomplete behavioral 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?

The description is extremely concise with just two sentences that each serve distinct purposes: the first defines the tool's function and differentiates it from siblings, the second specifies the return format. Every word earns its place with zero waste.

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 tool with 2 parameters and 100% schema coverage but no output schema, the description provides good context about purpose, differentiation, and return format. However, without annotations or output schema, it could benefit from more detail about response structure or behavioral constraints to be fully complete.

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

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

The schema description coverage is 100%, so the schema already fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema, though it does provide context about the 'last N days' window which relates to the days parameter. This meets 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 clearly states the tool's purpose with specific verbs ('posting the most AI/ML jobs') and resources ('companies'), and explicitly distinguishes it from sibling tool get_stats by contrasting 'what skills are trending' vs 'who's hiring most aggressively'. This provides excellent differentiation.

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 guidance on when to use this tool versus alternatives by naming the complementary sibling tool get_stats and explaining the different questions each answers. This gives clear context for tool 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool returns data 'by active role count' and 'optionally with average salary,' which gives some context about output behavior. However, it doesn't disclose critical traits like whether this is a read-only operation (implied but not stated), potential rate limits, data freshness, or authentication needs. For a tool with no annotations, this leaves significant gaps in understanding its operational characteristics.

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 highly concise and well-structured in two sentences. The first sentence clearly states the core functionality, and the second sentence adds practical context without redundancy. Every word earns its place, making it easy to parse and front-loaded with essential 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?

Given the tool's moderate complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the purpose and basic usage but lacks details on behavioral traits, output format, or differentiation from siblings. Without annotations or an output schema, the description should do more to explain what the return data looks like (e.g., list structure, fields included) and any limitations, but it provides a functional overview that meets basic needs.

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 1 parameter with 100% description coverage, providing details on 'limit' (type, range, default). The description doesn't add any parameter-specific information beyond what's in the schema, such as explaining how 'limit' affects ranking or output. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't need to heavily supplement the well-documented 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: 'Returns top AI/ML companies by active role count, optionally with average salary.' It specifies the verb ('returns'), resource ('top AI/ML companies'), and key criteria ('by active role count'). However, it doesn't explicitly differentiate from sibling tools like 'get_stats' or 'search_jobs', which might also provide company-related data.

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 implied usage guidance: 'Useful for discovering who is hiring in AI.' This suggests the tool is for exploration and hiring insights. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_stats' (which might provide broader statistics) or 'search_jobs' (which might focus on specific job listings). No exclusions or prerequisites are mentioned.

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 exist, so the description carries full burden. It clearly indicates a read operation ('Returns...') but could explicitly state no side effects. Still, it's adequately transparent for a simple listing function.

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, efficiently delivering purpose and usage guidance.

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 a straightforward purpose, the description is largely complete. Lacks details on return format or implicit behavior, but sufficient for intelligent agent 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?

Input schema has no parameters, so schema description coverage is 100%. Baseline is 3, and the description does not add parameter information (none 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?

Clearly states it returns 'agent-readable sellable products for AI Dev Board plus unavailable waitlist products', which is specific and distinguishes from sibling tools like quote_product and 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?

Explicitly says 'Use before quote_product or start_checkout', providing direct guidance on when to invoke this tool versus alternatives.

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 full burden. It describes the return data (tags with counts) but lacks details on behavioral traits like pagination, rate limits, or authentication needs. The description is accurate but minimal for behavioral 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?

Two sentences with zero waste: the first states purpose and output, the second provides usage guidance. It is front-loaded and appropriately sized for a simple 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?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is nearly complete. It covers purpose, usage, and output semantics, though it could add more behavioral details like response format or limitations.

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?

With 0 parameters and 100% schema coverage, the baseline is 4. The description adds no parameter info, but this is acceptable since there are no parameters to document.

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 verb ('Returns') and resource ('all available job tags/skills'), plus the specific data returned ('with the count of active jobs for each'). It distinguishes from siblings like 'search_jobs' by focusing on tag discovery rather than job filtering.

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?

Explicitly states when to use this tool ('Use to discover what tags are available for search_jobs filtering'), providing clear context and an alternative ('search_jobs') for actual filtering operations.

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 burden and does well by disclosing key behavioral traits: it ranks jobs, uses a specific scoring algorithm (tag overlap +2, salary overlap +3, workplace/level/type/location matches, description keyword hits), and returns pre-ranked matches with scoring explanations. However, it doesn't mention rate limits, authentication needs, or whether this is a read-only 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?

Two sentences that are front-loaded with purpose and usage context. Every element earns its place: first sentence explains what the tool does and scoring details, second sentence provides usage guidance and output format. 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?

For a complex ranking tool with 8 parameters, no annotations, and no output schema, the description does well by explaining the scoring algorithm and output format. However, it could better address parameter interactions (e.g., how multiple criteria combine) and doesn't mention error conditions or what happens when no matches are found.

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 63% (5 of 8 parameters have descriptions), so the description needs to compensate. It adds meaningful context by explaining how parameters are used in the scoring algorithm (skills for tag overlap, salary range for salary overlap, workplace/level for matching). However, it doesn't clarify the semantics for 'job_type' or 'location' parameters beyond mentioning they're part of matching.

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 with specific verb ('Rank') and resource ('active AI/ML jobs against a candidate profile'), listing the specific criteria used (skills, salary range, workplace, level). It distinguishes itself from sibling tools like 'get_job' or 'search_jobs' by emphasizing ranking/scoring rather than basic retrieval.

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?

Explicitly states when to use this tool: 'when an agent is choosing which role to surface to its user.' This provides clear context for application. It differentiates from siblings by focusing on ranking/scoring rather than simple retrieval or listing.

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 states the tool is 'deterministic', which hints at consistency and no side effects, but does not explicitly disclose read-only nature, authentication needs, or potential errors. The explanation of output fields adds some 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?

Two concise sentences. First sentence describes what the tool returns, second lists inputs. No redundant words; every sentence adds value. Front-loaded effectively.

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 adequately covers return fields. It explains input options, including the legacy tier parameter (covered in schema). However, it omits error handling and input conflict resolution (e.g., when both sku and product_id provided). Overall sufficient for a simple quote 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 baseline is 3. The description adds 'Accepts product_id or dossier sku', clarifying alternative identifiers, but the schema already describes each parameter adequately. Marginal value added.

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 a deterministic quote for a product, including specific output fields (amount, currency, payment mode, checkout requirements). It accepts product_id or sku, differentiating it from siblings like list_products and 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?

The description implies usage when a quote is needed, but does not explicitly state when to use or avoid this tool, or compare to alternatives like list_products or start_checkout. No 'when-not-to-use' guidance is provided.

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

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

No annotations are provided, so the description carries full burden. It discloses that results are ranked by quality score and recency, which is a behavioral trait. However, it does not explicitly state that the tool is read-only or discuss any side effects, leaving 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 long: the first states purpose, the second lists filters and mentions ranking. It is front-loaded and every sentence is essential.

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

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

There is no output schema, and the description does not detail the fields returned in search results (e.g., title, company, location, salary, etc.). Additionally, it does not clarify how multiple filters combine (AND vs OR) except for tags. This leaves important ambiguity for an agent.

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 100% coverage, so the baseline is 3. The description adds the ranking behavior and the fact that jobs are curated, which is not in the schema. However, it does not add further detail to parameter descriptions already present.

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 verb 'search' and the resource 'curated AI/ML engineering roles', and lists specific filtering capabilities. It effectively distinguishes from siblings like get_job (single job) and match_jobs (different matching behavior).

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 (when searching and filtering jobs) but does not explicitly mention alternatives or when not to use. For example, there is no guidance that get_job should be used for retrieving a single job by ID.

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 bears full responsibility. It discloses that no automatic charge occurs and that the response format depends on product type. It does not cover auth needs, rate limits, or other side effects, but the core behavior is 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?

Two sentences, front-loaded with the key verb 'returns', no wasted words. The description is concise and well-structured.

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 5 parameters (none required) and no output schema, the description adequately explains the tool's behavior and outcomes. It lacks details on error handling or prerequisites, but overall it is complete enough for this 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 schema provides 100% coverage for all 5 parameters, so the description adds no new semantic meaning 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 clearly states the tool returns the correct checkout handoff without charging, and distinguishes between two scenarios: for promoted listings it returns a POST body, for Dossier it returns a URL. This is specific and differentiates it from sibling tools which are about jobs, companies, etc.

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: to get a checkout handoff without charging. However, it does not explicitly state when not to use this tool or provide alternatives. The guidance is clear but not comprehensive.

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