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

With no annotations provided, the description carries the entire behavioral burden, and it excels. It reveals that the endpoint is deterministic, that partial bodies are silently merged over a template, that unrecognized keys are dropped silently, and that filter behavior can be counterintuitive (some expand rather than restrict). It even provides measured examples showing how to detect silent failures via the noEffect flag. This is exemplary 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 long, but every sentence carries critical, non-redundant information. It front-loads the core purpose and safety properties, then layers in warnings and measured data. No filler or repetition exists; each paragraph adds actionable knowledge an agent needs to use the tool correctly.

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 complexity (nested objects, no output schema) and the absence of annotations, this description is remarkably complete. It covers expected behavior, failure modes (silent drops, noEffect), practical examples, and even guidance on filter semantics that only become apparent through experimentation. An agent has everything it needs to call this tool correctly and interpret results.

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?

Although the schema already describes each parameter, the description adds value by clarifying that queryInput is a PATCH over a template, enumerating the verified key shapes (e.g., 'skills[{title,tag}]'), and explicitly flagging coSizes as ignored in every tested shape. It also explains how searchId selects the template and the meaning of the echoed 'baseline.' This goes well beyond the schema definitions.

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 object: 'Size a filter set WITHOUT running a search — the tuning primitive.' This immediately distinguishes it from running a search and states its role as a sizing/measurement tool. It also explicitly contrasts with the sibling jb_run_search by saying 'before committing to a run,' leaving 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 gives explicit when-to-use guidance ('permute filters and compare before committing to a run') and explains the side-effect-free nature that makes this safe for experimentation. It also instructs on selecting the saved search template via searchId and warns about the partial-body PATCH semantics. This is far more than typical usage 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 the free/costless nature, the exact return data, the significance of verdictFound=false ('not a negative'), and the error condition for unexecuted searches. It also notes that matchRate is 'banded' and that criteria-met count doesn't discriminate at the top of a ranked list. This is rich behavioral detail well beyond structured fields, giving the agent a clear understanding of what happens when calling the tool.

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 long but every sentence earns its place: the first line states the action and output, the cost note is critical, the 'READING THE RESULTS' section is indispensable for correct interpretation, and the final error note is essential. It's well-structured with clear sections (purpose, cost, interpretation, error condition). 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?

There is no output schema, but the description enumerates the return fields and explains the semantic meaning of matchRate and verdicts (including the crucial 'unknown ≠ negative' nuance). It covers error behavior, limits, and the relationship to search execution. With four parameters fully documented in the schema and the description adding inter-tool references, an agent has everything necessary to correctly invoke and interpret results.

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 covers all parameters with descriptions at 100% coverage, so the baseline is 3. The description adds meaningful context: it tells the agent that searchId comes from jb_list_searches, that projectId is a specific format and can be omitted to use a default project, and that limit has a default of 50 and max of 500. These references connect the tool to its ecosystem and clarify usage, exceeding the schema's raw field meanings.

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 begins with a specific verb ('Pull') and a specific resource ('a saved search's ranked candidates'), and details the exact fields returned (name, LinkedIn URL, title, company, location, matchRate, per-criterion verdicts). This clearly distinguishes it from siblings like jb_list_searches (which lists searches) and jb_count (counts). The scope is precise and non-tautological.

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 that this costs no export credits and is the same surface as the results page, giving context on when it's appropriate. It also provides a prerequisite: 'If the search has never been executed, this errors — open it in the app and press Run search once.' It doesn't explicitly name sibling alternatives, but the distinct purposes of siblings (list, count, run) make the usage boundary clear. The 'READING THE RESULTS' section adds interpretive guidance, though it's more about reading the output than choosing when to use the 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?

With no annotations provided, the description carries the full burden. It discloses that saved searches are stable and re-runnable (reassuring the agent that reuse is safe), and that it defaults to the configured project. This adds useful behavioral context beyond the raw schema. It doesn't mention pagination or error behavior, but for a simple list operation 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?

Two sentences: the first states the purpose and output, the second adds context and default behavior. No wasted words, and the most important information 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 one-parameter list tool with no output schema, the description is nearly complete: it explains what is returned, the stability, and the default. It could mention whether an empty list is returned when none exist, but that is minor. It doesn't need to explain return values since it already says 'searchId + name'. Missing details are negligible.

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 describes projectId as optional and as a URL or ID (100% coverage). The description adds value by stating it defaults to the configured project, which is not in the schema. That's meaningful extra guidance for when an agent can omit the parameter.

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 (list), the resource (saved searches on a Juicebox project), and the output (searchId + name). It also situates the tool as an entry point for pulling existing sourcing work, distinguishing it from siblings like jb_run_search or jb_get_results without needing to inspect 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?

It says this is the entry point for pulling existing sourcing work, implying you should use this before running or fetching results. It also notes the default-project behavior, which helps an agent decide when explicitly passing projectId is unnecessary. It doesn't explicitly say 'don't use this if you want results' or name alternatives, but the use case is implied clearly enough.

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 — and it delivers. It discloses the mutation side effect, persistence ('leaves a real saved search in the workspace, visible to the whole seat'), hidden costs (DOM page walks per 15 candidates), and the matchRate cross-search non-comparability caveat. This is exactly the kind of behavioral context an agent needs and that annotations would normally supply.

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?

Well front-loaded — purpose, write-warning, and confirmation instruction all land in the opening. But it runs several dense paragraphs and includes persuasive detail (the 42/44 versus 22/30 head-to-head benchmark) that, while informative, goes beyond what a call-time decision strictly needs. Mostly earns its sentences but is longer than ideal.

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 output schema and no annotations, coverage is unusually extensive: side effects, confirmation requirement, prompt construction strategy, and result-comparability caveat are all addressed. The one gap is that the description never says whether the created search's ID/reference is returned, which matters for chaining calls to the sibling ID-based tools afterward.

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 baseline is 3. The description adds real semantic depth to the prompt parameter beyond the schema: it explains that Juicebox extracts filters from prose, states what to include (seniority, geography, metric, etc.), and dictates explicit exclusions. This materially changes how the agent would construct the prompt, going beyond the schema's field list.

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?

Leads with a specific verb+resource+outcome: 'CREATE and RUN a new Juicebox search from a natural-language prompt, then return its ranked candidates.' It explicitly distinguishes itself from the read-only siblings with 'This is the ONLY tool here that WRITES,' so an agent can immediately separate it from jb_list_searches, jb_get_results, and jb_count without opening their schemas.

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 strong when-not guidance: confirm with the user before calling, do not call speculatively in a loop, do not tune for a small pool. It signals the write nature versus siblings ('ONLY tool here that WRITES'), making the read-vs-write split clear. However, it never names the sibling alternatives explicitly with conditions (e.g., 'use jb_get_results for an existing search'), leaving that substitution implicit rather than explicit.

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