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

Annotations already indicate a safe, read-only, idempotent call. The description goes beyond them with concrete constraints: maximum 10 results, no pagination, no employer apply URLs, semantics of theyond_verified_at and salary, and the fact that applications happen on the theyond page. No contradictions with 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?

Although longer than average, every sentence contributes a distinct fact: scope, URL exclusion, required filter combination, new semantics, result cap, absence of pagination/apply URLs, field meanings, and apply flow. It is front-loaded with the core purpose and routing rule.

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 6-parameter search tool with no output schema, the description is unusually complete: it covers result limits, omitted features (pagination, employer apply URLs), field semantics for potentially confusing values, and the application path. An agent has enough context to invoke the tool and interpret results correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds the critical at-least-one-filter requirement that the schema's all-optional fields do not convey. It also clarifies that new=true is not posted_at and explains what remote=true means, adding real value beyond parameter names and schema descriptions.

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 'Find live jobs' and enumerates the specific filter dimensions (keyword, place, company, remote, seniority). It explicitly distinguishes from get_job by excluding theyond job URLs and references hiring_now for the new-set, making the tool's scope unmistakable.

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

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

It states an explicit precondition ('Need q, location, company, remote=true, seniority, or new=true') and gives a direct routing rule for the URL case ('use get_job for that'). Hiring_now is mentioned only as an equivalent result set for new=true rather than a fully spelled-out when-to-use alternative, so the guidance is strong but slightly incomplete.

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