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

Annotations already signal readOnlyHint, idempotentHint, and openWorldHint=false, so the bar is lower. The description adds non-obvious behavioral details: resume text is clipped to maxChars, email/phone appear only when shared, and the source is a local database only. No contradiction 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?

Two compact sentences front-load the core purpose and then enumerate the delivered data. Every phrase earns its place, and the qualifiers 'local,' 'one applicant,' 'when shared,' and 'clipped to maxChars' are meaningful rather than 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?

For a read-only, idempotent tool with rich annotations, the description covers the return contents, data source, and clipping behavior. However, with no output schema and low parameter coverage, the includeProfile/includeResumeText switches and the exact response shape are left somewhat to inference.

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 25%, and the description compensates only for maxChars via 'clipped to maxChars.' It leaves applicationId's role implicit and does not explain the effect of includeProfile or includeResumeText, relying on parameter names alone. This is insufficient for a required string ID and two behavior-controlling booleans.

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?

States a specific verb and resource: returns one applicant's full local record, enumerating the exact content categories (list fields, application details, resume text, LinkedIn profile). The added 'Local database only' scoping distinguishes it from fetch/sync siblings such as applicants_fetch_profiles and applicants_fetch_details.

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: it is the local, single-applicant, full-record read. The 'Local database only' qualifier alerts the agent not to expect remote data and implies fetch/sync tools for non-local sources, but the description does not explicitly name alternatives or give when-not-to-use conditions.

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?

The annotations indicate a non-read-only, non-idempotent operation, and the description adds meaningful behavioral detail: it writes to disk, returns the path, streams large result sets, uses an Excel-friendly UTF-8 BOM for CSV, and guards against formula injection. These are useful traits beyond what the structured annotations provide.

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?

Three tightly written sentences, each adding a distinct useful fact: core behavior, scalability/streaming, and CSV safety. The most important information is front-loaded and there is no filler or repetition of schema content.

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 definition covers the essential invocation contract: what is exported, optional job filtering, supported formats, destination, and the return value. The main gap is parameter-level detail for includeResumeText and path behavior, but the schema partially covers outPath and includeProfile, so an agent can still call the tool correctly with reasonable inference.

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 40%, and the description only loosely covers jobId ('optionally one job') and format ('CSV, JSON or JSONL'). It does not explain includeResumeText, clarify includeProfile beyond its schema note, or describe outPath behavior. With low schema coverage, the description should compensate but leaves several parameters under-documented.

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 a specific action ('Write all stored applicants ... to a file on disk and return the path'), a clear resource (applicants), and supported formats (CSV, JSON, JSONL). This clearly distinguishes it from siblings like applicants_list or applicants_fetch_details, which retrieve data rather than export to a file.

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 the main use case: creating a full or job-filtered export file, and notes that streaming makes it suitable for thousands of rows. However, it does not explicitly explain when to prefer this over applicants_fetch_details, applicants_list, or other retrieval tools, nor does it state any exclusions or prerequisites.

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?

Discloses the asynchronous queueing nature, the side-effect of interacting with external sites (openWorldHint), the idempotent behavior via onlyMissing, the savePdf Chrome crash warning, and the pacing constraints. This goes well beyond the annotations (readOnlyHint false, idempotentHint true) and provides essential expectations for a tool that takes days to complete.

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?

A single dense paragraph that front-loads the purpose, then covers pacing, defaults, and return value. Every sentence adds information, but it is a bit long and could benefit from bullet points for scannability. Still, it is well-organized 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?

For a tool with 10 parameters and no output schema, it covers the essential context: what it does, how it behaves (async, paced), what it returns (count and estimate), how to track progress, and how to read results. It also notes important caveats (savePdf, profileDepth, onlyMissing). Nothing critical for an agent to call it 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?

The schema already covers 90% of parameters with descriptions, so the description doesn't need to repeat them. It adds global context (pacing, defaults, interaction between includeProfile and profileMinMustHave) that enriches parameter interpretation. However, it doesn't explicitly explain the profileMinMustHave logic in the description, relying on the schema, so it's a slight 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?

States a specific verb ('Queue the deep fetch') and resource ('applicants'), enumerates the exact actions (open application page, download resume, visit LinkedIn profile), and explicitly names the sibling tool applicants_fetch_profiles as the alternative for later profile-only fetches. This unambiguously distinguishes it from related 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?

Provides explicit guidance: it describes the pacing (one at a time, working hours, daily caps), the default behavior (only missing), and when to defer profile fetching via profileMinMustHave and applicants_fetch_profiles. It also directs users to queue_status for tracking and applicants_list/applicant_get/export for reading results, covering both usage and 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?

Beyond the annotations, the description adds meaningful behavioral context: it is paced like a human, profile views are the most rate-sensitive action, and it queues rather than performing synchronous opening. The idempotentHint is consistent with queuing, and openWorldHint fits the known-URL precondition. It does not detail queue mechanics or failure behavior, but the rate-limiting disclosure is valuable.

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?

Three sentences, all purposeful and front-loaded with the core action. The usage condition and pacing warning are stated without filler, making it easy for an agent to parse and act on.

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 six parameters, no output schema, and required fields entirely absent, the description provides a good usage trigger and rate-sensitivity warning but omits how applicants are selected via parameters. It also does not clarify what the caller should expect after queueing, which is more pressing given there is no 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 only 33%, so the description carries heavy responsibility, but it fails to explain key parameters like applicationIds, jobId, limit, and depth. It mentions the profile URL is known 'from the list or application page' without mapping that to the actual parameters. savePdf and onlyMissing are documented in the schema, but the remaining parameters are left ambiguous.

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?

States a specific verb and resource—'Queue full-profile fetches for applicants'—and clarifies scope by requiring a known profile URL and explicitly noting it does not re-open the application. This clearly distinguishes it from applicants_fetch_details, especially with the title 'Fetch full LinkedIn profiles only.'

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?

Gives an explicit trigger condition: 'Use when details were fetched with includeProfile=false.' It also implies the alternative is not needed when profiles are already at full depth. However, it does not name a sibling tool or state a when-not-to-use condition as explicitly as it could.

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 and idempotentHint, so the description's added value is the local-only read (no LinkedIn traffic) and the omission of resume/profile bodies. This enriches the agent's understanding beyond annotations without contradicting them.

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, no fluff, with the core purpose front-loaded and the caveat about applicant_get placed right after. Every clause earns its place, making it efficient 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 read-only list/search tool with 10 parameters and no output schema, the description covers the essential context: local data, paging, filters, search fields, and the alternative for full details. It doesn't enumerate every filter, but the schema provides enums and some descriptions. The description is sufficient for an agent to decide when to use it and how to structure a basic query.

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 only 20%, so the description must compensate. It explains the search parameter in detail (prefix matching, example) and mentions filters generally, but does not clarify the semantics of other parameters like rating, hasDetail, or orderBy. It partially compensates but leaves many parameters to be inferred from 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 states a specific verb (page through) and resource (applicants) with clear scope: filters and full-text search over defined fields. It also distinguishes itself from the sibling applicant_get by noting rows omit resume/profile bodies. This makes the tool's purpose 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 explicitly directs the agent to applicant_get for a single applicant's full details and clarifies that it reads only the local database (no LinkedIn traffic), implying sync/fetch tools are for live data. This gives clear when-to-use and when-not-to-use 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?

Annotations already indicate readOnlyHint=false (mutation), openWorldHint=true, idempotentHint=true. The description adds significant context: it's a queued crawl that persists progress, resumes automatically, and includes hidden 'Not a fit' applicants by default. It also mentions that it does not open individual applications. This enriches the annotation-provided idempotence and open-world nature.

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 dense paragraph but well-organized, starting with the core action, then data fields, then behavior nuances, then exclusions, then progress tracking. While it is somewhat long, it is front-loaded with the purpose and each sentence adds necessary detail (pages, progress, alternatives). 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?

Given the tool's complexity (queued crawl, pagination, persistence) and lack of output schema, the description explains key behaviors: chunking, progress persistence, resume, inclusion of not-a-fit, and where to check progress (queue_status/jobs_list). It also clarifies the scope (list vs details). Minor omissions might include response behavior when crawling completes, but the description is sufficient for an agent to safely invoke and monitor.

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 each parameter is described in the schema. The description adds conceptual meaning by explaining that jobId can be omitted with allJobs=true, and that pagesPerRun controls chunks of pages per worker turn. This goes beyond simple definitions and helps an agent understand relationship between parameters. However, since schema is already detailed, the added value is moderate.

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 queues a crawl of applicant lists for one or all jobs, enumerating the exact data fields (names, headlines, locations, applied dates, application ids, profile links). It distinguishes itself from applicants_fetch_details for individual applications. It doesn't explicitly name the alternative for fetching details within the main description, but does in the usage section, so it's clear enough.

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 applicants_fetch_details for contact info, resumes and profiles' for opening individual applications, and notes that to sync every job you use allJobs=true. It also explains the pagination behavior (chunks of pagesPerRun, progress persistence, resume across restarts) guiding when to be patient. This gives clear when-to-use and when-not-to-use 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?

Explains side effects beyond annotations: stops the worker, closes the Chrome window (or only disconnects in cdp), and confirms queued tasks persist. The description gives concrete behavioral context that annotations (readOnlyHint=false, destructiveHint=false) do not fully convey.

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, information-dense, with the primary action front-loaded and the cdp caveat and persistence detail following. No filler or redundant phrasing.

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-parameter tool with no output schema, the description fully covers what it does, its side effects, and follow-up behavior (queue persistence and relaunch). Nothing essential 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 tool has zero parameters, so schema coverage is trivially 100% with an empty object. The description doesn't need to explain parameters; the baseline of 4 applies. It correctly adds no param-related noise.

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: 'Stops the background worker and closes the Chrome window this server launched', with a specific resource (browser session) and a distinction for cdp mode. This differentiates it from siblings like browser_status or debug_navigate.

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 context on behavior in cdp mode and notes that queued tasks remain, implying it's safe to close. It mentions queue_start as the relaunch mechanism, but doesn't explicitly list when not to use this tool or compare with siblings. Still clear enough for an agent to decide.

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?

The description discloses key behavioral traits: it launches or connects to the user's own Chrome, opens LinkedIn, does not type anything on the user's behalf, waits up to timeoutSeconds for login to complete, and returns the status. This goes beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=true) by explaining the interactive nature and the wait behavior. It doesn't detail what the returned status looks like, but the core behavior is well covered.

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 and well-structured. It front-loads the core action (launch Chrome, open LinkedIn, manual sign-in), then explains the wait behavior, and finally provides usage guidance. Every sentence 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 complete for an interactive login tool. It explains the purpose, the manual nature, the timeout behavior, and when to use it. It doesn't describe the exact return status format, but since there is no output schema, a bit more detail on the returned status could be helpful. However, the description covers the essential context an agent needs to invoke it 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 description coverage is 100%, so the schema already documents the timeoutSeconds parameter. The description mentions 'waits up to timeoutSeconds' which reinforces the parameter's meaning but doesn't add significant new detail 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's purpose: it launches or connects to the user's own Chrome with a dedicated profile and opens LinkedIn for manual sign-in. It distinguishes itself from siblings by emphasizing that nothing is typed on the user's behalf and that the user signs in manually in a visible window.

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 when to use this tool: before the first sync and whenever browser_status shows loggedIn=false or a checkpoint. It also names the next step after solving a checkpoint: call queue_resume. This provides clear usage context and 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?

Annotations already declare readOnlyHint and idempotentHint; the description meaningfully adds that it never launches a browser and enumerates exactly what status information is reported. No contradiction 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?

Two sentences with no filler. The core purpose is front-loaded, and the rare critical usage instruction ('Call this first') is placed at the end of the second sentence without drifting into unrelated detail.

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 zero-input, idempotent status tool, the description fully defines what the agent should expect: connectivity, login state, current URL, and checkpoint presence. The absence of an output schema is compensated by this explicit enumerated report contract.

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 schema coverage is 100%, so the baseline is 4. The description adds no parameter-specific detail, but none is 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?

States a specific verb ('Report') and resource (Chrome session, LinkedIn login, URL, checkpoint), making it distinct from sibling tools like browser_open_login or debug_navigate. The 'Never launches a browser' clause sharpens the boundary.

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 instructs to call this first and whenever the queue reports needsHuman, giving clear context for use. It does not name alternatives or exclusions, so it stops short of a full when-not/alternative comparison.

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, and the description adds useful behavioral context beyond that: payloads are captured 'while we browsed' and bodies are clipped to 2000 characters. This tells the agent what to expect and prevents surprise from truncated output.

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?

Three short sentences, no filler, with the main action and resource front-loaded. The body truncation note is placed early and earns its place because it materially affects how the agent interprets results.

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 gives a clear purpose, a usage cue, and one important output trait (truncation), but it leaves parameter semantics and return structure unexplained. For a no-output-schema tool with 0% parameter coverage, this is usable but not 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?

Schema description coverage is 0%, so the description needed to compensate by explaining kind, limit, and urlContains, but it does not name or define any of them. The enum values are partially self-explanatory and the phrase 'Bodies clipped to 2000 chars' relates to output, not 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 uses a specific verb ('List') with a concrete resource ('JSON / RSC responses LinkedIn's own web app fetched') and names the relevant endpoint families (Voyager REST, GraphQL, flagship-web). This clearly distinguishes it from sibling tools like debug_page_text or debug_find, which operate on page text rather than captured network payloads.

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 'This is how you discover the endpoints and shapes behind the hiring dashboard' gives a clear, actionable use case. It does not explicitly state when not to use it or name alternative tools, but the intended discovery workflow is strongly implied.

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?

The description adds meaningful behavioral context beyond the annotations: it explains the human-like pacing, that only the first visible match is clicked, and exactly what will be reported after the click. It also adds a caution about not using it for rating or messaging. The 'Read-only actions only' phrasing is a usage constraint rather than a direct contradiction of readOnlyHint=false, since clicking can still navigate or alter page state.

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 deliver the core behavior, the output report, the intended use case, and an exclusion guard. Every phrase earns its place, and the most important behavioral details are 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 2-parameter tool with no output schema, the description provides enough to call it correctly: the required selector, optional waitMs, and the expected results. It could be even more complete by describing what happens if no element matches or if the selector is invalid, but those are not critical 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?

The selector parameter lacks its own schema description, but the tool description partially compensates by explaining that selector selects the first visible matching element and that the match count is reported. waitMs is well described in the schema. The description does not clarify selector syntax (CSS, XPath, etc.), so compensation is only partial.

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 a specific action ('click'), a specific resource ('first visible element matching a selector on the current tab'), and adds concrete behavioral details (paced mouse movement, reported URL/title/checkpoint state/match count). This clearly distinguishes it from siblings like debug_navigate or debug_find.

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 when to use it ('For exploring pagination / menus while adapting selectors') and gives a 'never use' exclusion for applicant-changing actions. It does not name alternative sibling tools explicitly, so it is slightly below a perfect when/when-not/alternatives statement.

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 mark the tool as read-only, so no contradiction exists. The description adds useful behavioral context beyond annotations by specifying the operation is scoped to the current tab and by disclosing which element properties are inspected. It does not describe error behavior or match limits, but the read-only annotation lowers the burden.

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 tight sentences. The first front-loads the action, scope, and output fields; the second gives a concrete repair use case. There is no filler or repetition of schema/annotation 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?

For a simple read-only debugging tool with just two parameters and no output schema, the description covers what it does, what it returns, and when to use it. It could mention whether it waits for elements or what happens on zero matches, but those are minor gaps given the tool's debugging purpose.

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 0%, so the description must compensate. It clarifies that 'selector' is a CSS/Playwright selector used to find matching elements on the current tab. The 'limit' parameter is not explained in the description, though its name, default, minimum, and maximum in the schema make its meaning reasonably inferable.

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-resource pair: 'Count and describe elements matching a selector on the current tab' and enumerates the exact fields returned. The title 'Try a CSS/Playwright selector' further clarifies the selector type, making it clearly distinct from siblings like debug_click and debug_page_text.

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 an explicit use case: 'Use to repair src/linkedin/selectors.ts when LinkedIn changes markup.' This tells the agent when the tool is appropriate. It does not explicitly name alternative tools or exclusions, but the targeted repair scenario is strong contextual 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?

Annotations declare readOnlyHint=false (mutation) and openWorldHint=true. The description adds meaningful behavioral context: it navigates 'the human way (paced)', pauses the queue, and reports final URL, title, and checkpoint state. This goes beyond the annotations by explaining the pacing behavior and the queue interaction, which is valuable for an agent deciding whether to invoke this 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?

Two sentences with zero waste. The core action is front-loaded, the LinkedIn-only constraint is stated immediately, and the queue-pausing instruction is a critical operational detail that earns its place. Every word contributes to correct invocation.

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 tool with no output schema, the description covers the essential context: what it does, the scope constraint, the pacing behavior, the queue interaction, and what it reports back. The only minor gap is not explaining what 'checkpoint state' means or what the output format looks like, but with no output schema and a simple parameter, this is reasonably 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 0%, so the description must compensate. The description mentions the URL must be a linkedin.com URL, which adds meaning beyond the schema's 'uri' format. However, it doesn't explain details like whether the URL must be absolute, whether redirects are followed, or what happens with non-LinkedIn URLs. The single parameter is simple enough that the description's LinkedIn-only constraint provides adequate but not complete semantics.

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 ('navigate'), a specific resource ('the working tab'), and a specific scope ('LinkedIn only'). It also distinguishes itself from generic navigation by noting the 'human way (paced)' approach and the reporting of final URL, title, and checkpoint state. This clearly separates it from siblings like debug_page_text or debug_find.

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 to pause the queue first to avoid fighting the worker for the tab, which is a clear usage guideline. It also implies this is for LinkedIn URLs only. However, it doesn't explicitly state when NOT to use this tool versus alternatives like debug_page_text or debug_find, though the LinkedIn-only scope provides some implicit exclusion.

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, so the read-only nature is known. The description adds that the result is 'clipped' and comes from 'innerText', which is useful. It does not disclose performance implications or edge cases, but given the simple read-only nature, the bar is lower. 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?

Two sentences with no fluff. The action is front-loaded, and the contextual note ('Cheap way...') is brief. 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 simple read-only tool with one optional parameter and no output schema, the description covers the core behavior. However, it does not explicitly state that maxChars limits the returned text length, nor does it describe the return type (string implied by 'innerText'). It also lacks mention of what happens when the limit is exceeded. These gaps are minor but present.

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 has a single parameter maxChars with no description (coverage 0%). The description mentions 'clipped' but does not explicitly link this to maxChars. An agent cannot tell from the description that maxChars controls the clipping limit, its default, or its bounds. The description fails to compensate for the lack of schema documentation.

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 ('Return the innerText of <main> (or body)') and scope ('current tab, clipped'). It distinguishes this from other debug tools by focusing on visible text extraction. However, it does not explicitly name any sibling alternative, so it lacks strong differentiation against debug_snapshot or debug_find.

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 'Cheap way to see what LinkedIn is showing' implies a quick inspection use case, but it does not provide explicit guidance on when to use this instead of other tools like debug_snapshot or debug_navigate. No alternatives are mentioned, and no exclusions are given.

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 and openWorldHint=false, so the agent knows this is safe. The description adds useful detail about what exactly gets saved, going beyond the annotations. It does not contradict them.

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 no filler. The action and scope are front-loaded, and the usage hint follows immediately. 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 simple, read-only snapshot tool with one optional parameter and no output schema, the description provides all essential information: what is saved, where (debug directory), and when to use it. No critical details are 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 schema covers the single parameter 'name' with a description ('Label for the snapshot folder'), and schema coverage is 100%. The tool description does not add any extra meaning to the parameter beyond what the schema provides, so a 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 states a specific verb (Save) with a precise resource (current tab) and enumerates exactly what is captured (full-page screenshot, HTML, visible text, network payloads). This clearly distinguishes it from siblings like debug_page_text or debug_captures, which capture subsets.

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 a concrete trigger scenario: 'Use when a task fails with "Could not find …"' and explains the purpose (so selectors can be updated). It does not explicitly name alternatives or state when not to use it, but the context is clear 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful context by specifying that data is local and that per-job progress counters are included, but it does not disclose other behavioral details like result ordering, pagination, or the shape of the returned list.

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?

A single sentence that front-loads the core action and resource, then adds the important detail about progress counters. No wasted words and no redundant restatement of the title.

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 read-only list tool with one optional parameter and no output schema, the description gives enough context about what is listed and what counters are included. It would be slightly stronger with a note about how the status filter affects the result, but the schema already documents that parameter.

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 only parameter (status) is fully documented with an enum and default in the schema. The description itself does not mention filtering, so it adds no extra parameter meaning, but the baseline of 3 is appropriate because the schema carries the full burden.

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 ('List') and resource ('jobs stored locally from jobs_sync'), and names the exact per-job progress counters included in the result. This clearly distinguishes the tool from the sibling jobs_sync, which is presumably the operation that fetches/syncs the jobs.

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 'stored locally (from jobs_sync)' implies this tool is for inspecting the local synced snapshot rather than triggering a sync, but it never explicitly says when to prefer this tool over jobs_sync or any other sibling. There is no when/if guidance or exclusion of 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?

Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=true. The description adds behavioral context beyond annotations: it runs 'in the background paced like a person (roughly 1–3 minutes)' and that wait=true blocks. It also notes the side effect of storing locally. This is valuable context that isn't in the annotations. It doesn't contradict any annotation.

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 no wasted words. The first sentence states the core action and location, the second explains behavior and options. It front-loads the primary purpose and keeps the alternative usage compact. Perfectly structured for quick comprehension.

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 two optional parameters and no output schema, the description covers everything an agent needs: what it does, how it behaves (background, paced), how to get results (wait=true or use jobs_list), and the specific path. The annotations already cover open-world and idempotency. 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?

Schema coverage is 100%, so the schema already documents both parameters. The description adds interpretative value: it explains the effect of wait=true ('blocks up to 2 minutes and returns the jobs found') and mentions 'open and optionally closed' which maps to includeClosed. This goes beyond the schema's brief descriptions, so it earns above the baseline of 3.

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 ('Queue a crawl'), the resource ('your posted jobs'), and the storage effect ('store them locally'). It also mentions the specific path '/my-items/posted-jobs/' and distinguishes itself from the sibling 'jobs_list' by saying 'Afterwards use jobs_list'. This makes the tool's purpose unambiguous and distinct.

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 explicitly explains the two modes of use: background crawl (non-blocking) and with wait=true (blocks up to 2 minutes and returns jobs). It also directs the agent to the next appropriate tool (jobs_list) after the sync. This gives clear when-to-use and follow-up guidance, though it doesn't explicitly state when not to use it, the context is sufficient.

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 cover the safety profile with readOnlyHint=true and idempotentHint=true. The description adds value by listing what is returned, including the nuance of daily caps with a warm-up ramp, which is useful given there is no output 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?

One front-loaded sentence with no filler. The scope appears first, and every listed item communicates a distinct aspect of the returned settings.

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 zero-parameter read-only tool, the description is largely sufficient: annotations cover safety and the field enumeration compensates for the missing output schema. It could add exact response formatting or freshness semantics, but an agent can invoke it correctly without those.

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?

This tool has zero parameters and schema coverage is 100%, so the schema fully resolves parameter questions. The description does not need to add parameter semantics, and the baseline of 4 applies.

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 phrase 'Current human-pacing settings' names the resource and scope, and the verb 'Get' communicates the action precisely. The enumerated components distinguish it from siblings like pacing_set.

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 word 'Current' implies this is for reading existing settings, and the sibling pacing_set implies the write counterpart. However, there is no explicit when-to-use guidance or direct mention of alternatives, so usage is inferred rather than stated.

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?

The description discloses that changes are persisted ('Persisted'), which is valuable behavioral context beyond the idempotentHint annotation. It also warns about risk of account restriction, which is critical behavioral information. The annotation idempotentHint=true is consistent with the description's implication that setting the same values again is safe. No contradiction found.

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 and front-loaded with the core purpose. The risk warning is placed after the main purpose, and every sentence adds value. It's appropriately sized for a tool with 12 parameters, focusing on the most critical behavioral guidance without unnecessary detail.

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 has 12 parameters, no output schema, and only 25% schema description coverage, the description provides essential context about persistence and risk. It explains the two most safety-critical parameters. However, it doesn't cover the meaning of several other parameters (ramp, workDays, warmupProbability), which an agent might need to set correctly. The risk warning is a strong addition that improves 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 is only 25%, so the description must compensate for undocumented parameters. The description explains the meaning of dailyProfileCap and hourlyActionCap with specific thresholds, adding value beyond the schema. However, it doesn't explain other parameters like rampStart, rampPerDay, workDays, or warmupProbability, leaving gaps. The description partially compensates but not fully.

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 adjusts pacing settings for the worker, with a specific verb ('Adjust') and resource ('pacing settings'). It distinguishes itself from siblings like pacing_get by implying this is the setter counterpart, though it doesn't explicitly name the sibling. The title 'Change pacing settings' reinforces the purpose.

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: when adjusting how fast/when the worker acts. It also gives practical guidance on safe values (e.g., raising caps above certain thresholds increases risk), which helps an agent decide appropriate parameter values. However, it doesn't explicitly state when NOT to use it or name alternatives like pacing_get for reading current settings.

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?

The description goes beyond the destructiveHint annotation by specifying exactly what is affected: only PENDING tasks, with running tasks allowed to finish and completed work untouched. It also discloses the default behavior when no filters are provided (cancels all pending). This is rich behavioral context that an agent needs to anticipate 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 concise and well-structured, with two sentences. The main action is front-loaded, followed by essential clarifications about scope and side effects. Every sentence adds value, and there is no 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?

For a cancellation tool with no required parameters and no output schema, the description covers the critical aspects: what it does, the filters, the default behavior, and what it does not affect. It could optionally mention error handling or return values, but these are not essential for correct invocation given the annotations and the clear scope. Minor gaps remain, but overall it 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 schema has 0% description coverage, so the description must compensate. It lists the three filter fields (type, jobId, applicationId) but does not explain their semantics, combination logic, or constraints (e.g., how multiple filters interact, whether they are OR/AND). The description essentially repeats the parameter names without adding meaning beyond what the schema already shows.

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 (cancel), the target (pending tasks), and the filtering mechanism (type/jobId/applicationId). It also distinguishes the scope: without filters it cancels every pending task, and explicitly notes that running tasks finish and done work is untouched. This differentiates it from sibling tools like queue_pause or queue_retry_failed.

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 no explicit guidance on when to use this tool versus alternatives. It does not mention queue_pause, queue_retry_failed, or any other sibling, nor does it state conditions for choosing this over them. The intended use is implied by the name and description, but there is no direct comparison or exclusion criteria.

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?

The description adds behavioral detail beyond the annotations: processing halts only after the current task finishes, and tasks remain queued. It also references the resume path. The idempotentHint annotation covers repeat-invocation behavior, so the description does not need to restate it.

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?

Three short sentences deliver the core behavior, the state preservation guarantee, and the resume counterpart with no filler. The most important fact, when the pause takes effect, 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 zero-argument state-change tool, the description is complete: it states what happens, when it happens, and how to undo it. The output schema is absent but not needed for such a simple operation.

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 parametersasi, so parameter semantics are trivially complete. The baseline for zero-parameter tools is 4, and the description appropriately focuses on behavior rather than 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 clearly states the tool pauses queue processing, with the precise timing detail 'after the current task finishes.' It also clarifies 'Tasks stay queued,' which distinguishes it from a cancel operation. This is specific and immediately understandable.

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 clear context for when to use the tool: to pause processing temporarily while retaining queued tasks. It mentions queue_resume as the natural counterpart. However, it does not explicitly contrast with queue_cancel, leaving the main alternative usage boundary implicit rather than fully explicit.

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 it is not read-only and is idempotent. The description adds that it clears the paused flag and, by default, the needsHuman flag, and then starts the worker, disclosing the side effects. It also explains the reason for the flags (checkpoint/login wall), providing useful context beyond 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 a single sentence that packs the action, condition, and parameter default. It is slightly long but still efficient. The key information is front-loaded, with the action stated first.

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 boolean parameter and no output schema, the description covers the purpose, the trigger condition, and the default behavior. It is sufficient for an agent to know when and how to call it. It does not describe error handling or worker behavior, but that is beyond the scope for this simple 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 has one boolean parameter with no description. The description mentions 'by default' clearing the needsHuman flag, which implies the parameter controls that behavior. This adds meaning beyond the schema, but it does not explicitly state what happens when clearNeedsHuman is false. Given 0% schema coverage, the description partially compensates but could be more explicit.

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 clears the paused flag and, by default, the needsHuman flag, then starts the worker. It specifies the exact context (LinkedIn checkpoint/login wall) and distinguishes it from sibling tools like queue_start, which likely only starts the queue without clearing flags.

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 explicitly provides a trigger condition: 'call after you solved it in the Chrome window.' This gives clear guidance on when to use it. However, it does not explicitly contrast it with alternatives like queue_start, so it lacks a full 'when-not-to-use' statement.

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 signal a mutating, idempotent operation, and the description adds meaningful behavioral context: tasks are put back 'with a fresh attempt budget' and can be filtered by type/jobId. This goes beyond the annotations without contradicting them.

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 core action and key qualifier front-loaded. The optional filter and usage context are stated without any 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?

For a low-complexity tool with two optional parameters and no output schema, the description covers the main behavior and gives a clear situational trigger. It does not detail defaults for the attempt budget or what happens to existing queue entries, but this is a minor gap given the tool's simplicity.

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 0%, and the description only says the operation is 'optionally filtered by type / jobId'. This names both parameters and hints at their role, but does not explain the enum values or what jobId refers to, leaving the description to carry more weight than it actually does.

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 ('Put failed tasks back into the queue') and a specific resource, clearly identifying the tool as a retry operation for failed tasks. It also distinguishes itself from queue_status/queue_start/queue_cancel by focusing on re-enqueueing failed tasks with a fresh attempt budget.

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 after fixing a login problem or when LinkedIn had a bad day' provides clear situational context for when the tool is appropriate. It does not explicitly name alternatives or state when not to use it, so it falls just short of the highest tier.

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 indicate mutating (readOnlyHint=false), external side effects (openWorldHint=true), and idempotency (idempotentHint=true). The description adds meaningful nuance beyond these: it discloses the conditional behavior (only acts when tasks pending and scheduler allows) and the no-op scenario when another process owns the queue. This enriches the agent's understanding of when side effects actually occur.

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, directly front-loaded with the primary action. Each clause earns its place: the action, the conditional triggers, and the ownership caveat. No filler, 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 tool with no parameters and no output schema, the description is nearly complete. It covers what it does, when it acts, and when it is a no-op. Subtle points like asynchronous execution or post-condition state are not mentioned, but these are minor given the annotations and context.

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 an empty schema (100% coverage). Per the rubric, a baseline of 4 is appropriate when there are no parameters to document. The description doesn't need to add parameter details, and it doesn't.

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: 'Start (or resume) the background worker in this process.' It identifies the resource (background worker) and the scope (this process), and adds a distinguishing condition (no-op if another process owns the queue). While it doesn't explicitly name sibling tools like queue_resume, the 'in this process' qualifier effectively differentiates it from process-wide queue operations.

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 context on when the tool actually acts: 'It only acts when tasks are pending and the scheduler allows it. No-op if another process owns the queue.' This tells the agent the conditions under which it should expect an effect. It does not explicitly compare with queue_resume or queue_pause, but it gives enough guidance for the current process context.

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 and idempotentHint=true, so the safe, repeatable nature is known. The description adds behavioral value by saying this tool is meant for polling during long exports and by naming live status dimensions such as running/paused/needsHuman and working-hours windows. There is no contradiction with 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 dense but compact, using a single list to cover many distinct status dimensions and ending with a concrete usage directive. Every listed item adds a different aspect of the status. It is not overly verbose, though the opening phrase 'Everything about the background work' is slightly broad and could be more specific.

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 zero-parameter, read-only, idempotent tool, the description supplies the key context an agent needs: what data is available, what state categories exist, and when to poll. Since there is no output schema, the description carries the burden of describing return semantics at a category level, which it does adequately. It could be more explicit about response structure or event formatting, but nothing essential is missing for correct selection and 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 schema coverage is trivially 100%, so there is no per-parameter meaning to add. For a zero-parameter tool, a baseline of 4 is appropriate; the description instead compensates by telling the agent what status categories to expect, which is useful given the absence of an output 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 identifies a read-only status resource by enumerating the exact categories it covers: worker state, task counts, daily caps, working-hours window, sync progress, browser status, and events. The directive 'Poll this to follow long exports' gives a specific verb and use, and the read-only nature distinguishes it from sibling control tools like queue_start, queue_pause, and queue_retry_failed.

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 provides an explicit trigger condition: poll this to follow long exports. This makes the primary use case clear and separates it from queue-control siblings. However, it does not explicitly mention when to prefer queue_tasks for detailed task-level information or browser_status for browser-only status, so it lacks formal exclusions or alternative routing.

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 and idempotentHint=true, so the safety profile is covered. The description adds that results include status, attempts, and last error, which is useful behavioral context beyond the schema. However, it doesn't disclose default ordering, time window, or whether 'recent' is a fixed window, which would be relevant for interpreting results.

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 core purpose and the primary use case are front-loaded, and 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 read-only list tool with no output schema, the description covers the main purpose and filter dimensions. However, it lacks details on result ordering, pagination behavior beyond the limit parameter, and what 'recent' means. Given the tool's diagnostic purpose, an agent might need to know whether results are sorted by recency or whether failed tasks are highlighted.

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 0%, so the description carries the burden of explaining parameters. It mentions filtering by type/status/jobId, which maps to three of the four parameters, but it doesn't explain the 'limit' parameter or provide any format/semantics beyond what the schema enum names already convey. The description adds some meaning but doesn't fully compensate for the 0% 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 states a specific verb ('List') and resource ('tasks'), and adds the key attributes shown (status, attempts, last error) plus filter dimensions. It distinguishes itself from siblings like queue_status and queue_retry_failed by focusing on listing tasks with failure diagnostics, though it doesn't explicitly name a sibling alternative.

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 'Use to see why something failed' gives clear context for when to call this tool, implying it is the diagnostic entry point for failed tasks. It doesn't explicitly state when not to use it or name alternatives like queue_status, but the intended use case is clear enough for an agent to select it appropriately.

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?

The annotations already mark the tool as readOnly and idempotent, and the description adds meaningful behavior beyond that: text is clipped to maxChars and will be empty for scanned images or missing downloads. This is useful context that the annotations do not provide.

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?

One tight sentence that front-loads the core behavior and adds the important empty-case caveat. Every word earns its place, with no redundant phrasing.

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 two-parameter read-only tool, the description covers the core behavior, the clip behavior, and the empty-case scenario. Without an output schema, a bit more detail on the exact return shape (e.g., whether empty is an empty string or null) would be useful, but the description is largely sufficient.

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 0%, so the description must compensate. It maps applicationId to 'one applicant' and mentions maxChars as the clip limit, but it does not fully define either parameter's semantics or format. The schema provides the required/default values, so the description provides only partial added meaning.

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 exactly what the tool returns: plain text extracted from one applicant's downloaded resume (PDF/DOCX), clipped to maxChars. This clearly distinguishes it from broader tools like applicant_get or debug_page_text by scoping it to resume text for a single application.

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 the tool is for retrieving resume text for one applicant, but it does not explicitly say when to prefer it over sibling tools such as applicant_get or applicants_fetch_details. The empty-when-scanned/no-download note helps an agent interpret results, but no explicit when-to-use or alternative guidance is provided.

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