HuntBoard

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

The annotations already declare readOnlyHint true, idempotentHint true, and destructiveHint false, so the safety profile is covered. The description adds value by enumerating exactly what data is returned (title, company, location, workplace type, employment type, posted date, source, apply link, open status, description excerpt).

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 carry a high density of information: the resource scope, the full field list, and the expected input source. Everything earns its place and the critical guidance about passing the search_jobs link appears early.

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, read-only retrieval tool, this description is complete. It names the full return contents (obviating the need for an output schema), explains how to supply the URL, and connects the tool to the search_jobs workflow.

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

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

Schema description coverage is 100% and the schema's parameter description already states "The job link as returned by search_jobs." The tool description repeats this guidance but adds no new format, pattern, or validation details, so it stays at the baseline for fully documented parameters.

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

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

The description states a specific action and resource: it returns "full details of one posting" indexed by HuntBoard. It also differentiates from its sibling search_jobs by instructing the agent to pass a link returned by search_jobs, making the tool's role unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use this tool: after getting a link from search_jobs. It does not, however, spell out when not to use it or compare against alternatives like list_coverage, so it falls just short of a full 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the useful detail that the output includes public page URLs, but it does not disclose behavior beyond that, such as pagination or volume of results, though this is mitigated by annotations and the zero-parameter interface.

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 short sentences with no filler: the first defines the resource and output, the second states the intended usage. Every word earns its place and the key content is front-loaded.

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

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

For a no-argument, read-only listing tool, the description fully covers what is returned, with what metadata, and why it is useful. Annotations supply the safety and idempotence guarantees, and sibling contexts show this is the 'coverage lookup' tool distinct from job retrieval and subscriptions.

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 does not need to explain parameter semantics because there are none, and it appropriately describes the tool's output instead.

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

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

The description names the specific resource—countries, cities, remote-in-country pages, and job roles HuntBoard covers—and states each entry includes its public page URL. This clearly distinguishes it from sibling tools like search_jobs and get_job, which focus on job lookup rather than coverage metadata.

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 says the tool is 'useful to pick locations and titles before searching,' giving clear timing and intent relative to searching. It does not explicitly name alternatives or exclusions, but the 'before searching' context effectively signals when this tool should be selected over search_jobs.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context beyond those hints: it reveals the internal pipeline ('SQL narrowing over its index of company career pages and ATS boards, then an AI fit score'), the scoring threshold for returned results (7-10), and the return fields. This lets the agent predict that results are pre-vetted, non-deterministic, and sourced externally—useful information not present in the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with zero fluff. The main action is front-loaded, followed by a compact explanation of the internal method and the return shape. Every clause contributes either purpose, behavioral transparency, or output details, making it appropriately sized and scannable.

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?

Without an output schema, the description compensates by listing the return fields explicitly (title, company, location, link, source, one-line reason) and the cap via max_results. The main gaps are undefined 'recent' time window and no mention of empty-result or error behavior. For a read-only search tool with rich annotations, these are minor omissions, so the definition is strong but not fully exhaustive.

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 fully documents all six parameters, including defaults, limits, and examples. The description adds no parameter-specific semantics beyond what is already in the schema; it merely echoes the title/location/remote concept. A baseline 3 is appropriate when the schema carries the heavy lifting.

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

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

The description opens with a precise verb-resource statement: 'Find recent job postings that match target job titles in given locations (or remote)'. It specifies the filters (titles, locations, remote) and the result set, so an agent immediately knows what this tool does and what it does not do. No sibling tools exist to confuse it, and the purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There are no sibling tools, so no alternative-routing guidance is needed. The description gives clear contextual usage signals: it runs an AI-scored hunt over company career pages and ATS boards and returns only jobs scored 7-10, which tells the agent this is the tool for high-quality, pre-filtered job matches. It stops short of explicit 'use when / do not use when' guidance, so it earns a 4 rather than 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?

Annotations only convey non-read-only and non-idempotent. The description adds critical beyond-annotation behavior: the double opt-in flow (nothing starts until the confirmation link is clicked), the morning delivery cadence, and free one-click unsubscribe. These are exactly the behavioral traits an agent must know before invoking a subscription tool and are not derivable from the hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the core action first, then the opt-in mechanism, unsubscribe, and invocation condition. Every sentence earns its place with no redundancy or padding; the most safety-critical guidance (consent) is positioned at the end as a guardrail.

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

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

Despite six parameters and no output schema, the description covers the essential agent-facing aspects: the action, the delivery cadence, the opt-in gate, the unsubscribe path, and when to call it. The subscription flow is fully disclosed, and with no output schema and clear sibling differentiation, nothing an agent needs to invoke this correctly is missing.

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

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

Schema description coverage is 67%, and the schema already documents email, titles, locations, and remote_ok. The description adds mild reinforcement — 'for the given titles and locations' clarifies those act as match filters, and 'email the person' confirms email is the recipient — but adds no new meaning for the two uncovered parameters exclude_titles and exclude_locations, which have no schema descriptions either. Adequate but not strongly compensating for the coverage gap.

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 ('email the person new job matches every morning') on a clear resource (daily job subscriptions), with a stated mechanism (double opt-in) and scope (given titles and locations). It clearly distinguishes from siblings get_job, search_jobs, and list_coverage, which are all read-oriented; this is the only write/subscription action among them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The final sentence gives explicit invocation conditions: 'Only call this when the person explicitly asked for daily emails and gave their own address.' This tells the agent when to trigger the tool and implicitly when not to (unsolicited, or using someone else's address), which is exactly the consent boundary this subscription action needs to respect.

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