Offpeak

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is structured. The description contributes the non-obvious side effect (email suppression) but says nothing about permanence, whether the record is recoverable, or behavior when the ID doesn't exist.

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 sentence, front-loaded with verb+resource, with the side effect appended rather than buried. Nothing wasted.

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 destructive tool the essentials are present, and annotations plus the uuid pattern carry much of the rest. Still missing for a delete: whether it is permanent, and whether a non-existent ID errors or silently succeeds (relevant given idempotentHint=true).

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% for the single parameter; only structural hints (uuid format, strict pattern) convey its nature. The description adds no meaning about saved_search_id — e.g., where to obtain it or whether it must reference a search the caller owns.

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 (delete) and resource (one of your saved searches), plus the consequential side effect that its email stops. An agent can distinguish this from get_saved_searches, save_search, and set_search_email without opening any schema.

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?

No when-to-use or when-not guidance. The sibling set_search_email exists precisely so an agent can stop email without deleting, yet the description never names that alternative or the condition that selects it.

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, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond that: drive times reflect typical weekday rush-hour traffic, and auth requirements differ by caller type with a filters:read scope — both useful behavioral disclosures not in structured fields.

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

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

Four compact sentences, front-loaded with the core purpose before the caller-type and indexing details. Each sentence carries distinct information; slight density but no waste.

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

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

With no output schema, the description should indicate what is returned (e.g., duration in traffic, distance, route info) but only says 'routed driving commute.' For a calculation tool where the return shape matters to an agent, this leaves a clear gap despite otherwise strong coverage.

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 67% with nested origin object. The description reinforces that origin is required for anonymous callers and explains location_index ties to search results, adding practical semantics beyond the schema. It doesn't clarify origin handling for connected callers (optional?), a minor 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 (get) and resource (routed driving commute) scoped to a job site, with no ambiguity about what the tool produces. No sibling tool overlaps this function, so an agent can identify it immediately.

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?

Clearly distinguishes anonymous callers (origin required as {lat,lng}) from connected callers (saved origin, filters:read scope), which is explicit conditional guidance. It doesn't explicitly exclude use cases or name alternatives, but the caller-type split provides strong routing 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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety behavior is covered. The description adds useful context beyond annotations by enumerating the categories of option data returned, though it does not discuss response format or limits.

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, front-loaded sentence that lists the returned option categories without filler. Every phrase contributes to telling the agent what the tool provides.

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, no-parameter, read-only options-discovery tool with rich safety annotations and no output schema, the description is largely complete. It enumerates the main option categories but does not explain the response shape or how these options relate to get_filters/set_filters.

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 parameter semantics are not a concern. The baseline for a zero-parameter tool is 4, and there is no misleading parameter information.

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, "Get," and enumerates the resource precisely: search fields, defaults, seniority levels, function/industry codes, sorting, and pay rules. It is clear what the tool returns, though it does not explicitly distinguish itself from the sibling get_filters.

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 this is a discovery/metadata tool by listing supported fields and rules, but it gives no explicit guidance on when to call it instead of get_filters, set_filters, or search_jobs. The agent must infer the intended usage from the content alone.

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, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds two pieces of context not in structured fields: the required scope 'filters:read' and the interpretation rule 'A missing origin means no home has been saved'. What is missing is any note on response shape or size for a tool with 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?

Two short sentences with no filler, and the permission requirement is placed last where it is easy to scan. The middle clause 'including home and filters' is slightly ambiguous about whether it enumerates returned items or categories, which keeps it from a 5.

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

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

With no parameters and no output schema, the description carries the full burden of explaining the return value, yet it names only one field ('origin') and never says what a 'search' or 'filters' object contains. It is adequate to call the tool safely but leaves the agent guessing at the payload.

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 takes zero parameters with additionalProperties:false, so there is nothing to disambiguate and the baseline of 4 applies. 'origin' appears only as a response-field interpretation hint, not a parameter, and is not misleading.

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 verb is 'Read' and the object is nominally 'the connected account's search, including home and filters', but the phrasing is muddled relative to the tool name get_filters and its title 'Read saved search filters'. It never clarifies how this differs from close siblings like get_saved_searches or get_filter_options, so an agent cannot confidently pick it on purpose alone.

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 only actionable guidance is the permission prerequisite 'Requires filters:read'. There is no statement of when to use this versus set_filters, get_filter_options, or get_saved_searches, and no exclusion conditions — the agent must infer the selection rule from sibling names.

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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds value annotations cannot: the distinction between apply_url and source_url, the reassurance that 'Offpeak never submits applications', and the prompt-injection warning that listing content is untrusted. It stops short of covering not-found or invalid-ID behavior.

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 compact sentences with the core action front-loaded, followed by field semantics and a safety caveat. There is minimal waste, though the apply_url/source_url sentence leans toward documenting return values that could arguably live elsewhere.

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-ID read tool with no output schema, the description supplies the important return-field semantics and a security caveat, which is close to sufficient. Gaps remain around error behavior for stale or deleted IDs and whether the listing can change between searches, but nothing blocking 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?

With a single parameter and 0% schema description coverage, the description must carry the semantics, and it partially does by stating job_id must originate from search results. It does not restate type or validation, though the schema already constrains it to a positive integer. The remaining sentences describe return fields rather than 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?

Names a specific verb and resource ('get current details for a job ID'), and scopes the ID source as coming 'from search results'. It also clarifies two return fields (apply_url vs source_url), which sharpens what the tool actually delivers. It never explicitly contrasts with siblings like get_jobs or search_jobs, so the singular-vs-plural distinction is left to inference.

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 'from search results' implies the intended workflow (search first, then fetch details by ID), which is genuinely useful routing context. However, there is no explicit when-to-use/when-not, and no named alternative such as get_jobs for bulk retrieval or get_saved_jobs for previously saved listings.

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?

Adds real value beyond the annotations: confirms a hard 100-ID cap, promises caller-order preservation, and warns that missing_ids/closed_ids may come back, plus flags posting content as untrusted (prompt-injection relevant). Annotations already cover read-only/idempotent safety, so this is a solid addition rather than a full behavioral spec.

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 sentence front-loads the core batching behavior and never repeats the name or title. The tail clause about summary mode is slightly compressed, but no words are wasted.

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

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

With no output schema, the description does the work of indicating return shape: ordering, missing_ids/closed_ids, and the key detail fields. It stops short of stating response structure (e.g., whether unresolved IDs appear as nulls in position) or any rate/size caveats.

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

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

With 0% schema coverage the description must carry the parameters, and it does: job_ids is bounded at 100 with order preserved, and details is explained as full (apply_url, source_url, untrusted content) vs summary (compact saved-list fields). The default of 'full' and the concrete summary field set remain unspecified.

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 with batch scope: 'Read up to 100 job IDs in caller order'. An agent can distinguish it from single-item get_job by the batching and ID-list framing, though no sibling is named explicitly.

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 summary-vs-full distinction gives intra-tool usage guidance, but the description never says when to choose this over get_job or search_jobs. The caller must infer that this is the batch-hydration step after a search.

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 establish that this is a read-only, idempotent, non-destructive operation, so the description is not carrying the safety burden. It adds useful behavioral context by naming returned categories such as missing_ids, closed_ids, and applied_ids, and by stating that cursors expire after 15 minutes. It does not discuss authorization or rate limits, but those are minor gaps given the annotation coverage.

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 efficient sentences with no wasted text. It front-loads the return-shape information and follows with pagination constraints in a logical order.

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

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

With no output schema, the description is responsible for explaining return values, and it does list the main fields and ID categories. It covers pagination and cursor expiry, though it does not fully explain what missing_ids represents or the exact structure of compact saved_jobs summaries.

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 description adds some meaning for both parameters, saying cursor is the next_cursor and limit is optional for pagination. However, schema coverage is only 50%, and the description does not explain the limit bounds or default, nor does it add much beyond the cursor description already present in 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 gives a specific verb and resource: it lists saved job IDs and returns compact saved_jobs summaries plus categorized ID sets. It is clearly not a search or mutation tool, though it does not explicitly distinguish itself from siblings such as get_jobs or get_saved_searches.

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 explains pagination mechanics but does not say when an agent should use get_saved_jobs instead of alternatives like get_jobs or get_saved_searches. There are no explicit use cases, prerequisites, or exclusions.

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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real value on top by describing what each saved search carries (filters, email on/off), though it says nothing about ordering, pagination, or result-set size.

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: the first states what is returned, the second rules out the most likely misread. Nothing is redundant with the title or annotations, and the key information leads.

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 list tool with no output schema, the description covers what is returned and what is not. The remaining gap is the absence of any hint about ordering or result volume, which an agent might want before calling.

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 takes zero parameters, so the schema baseline is 4 and there is no parameter semantics for the description to supply. The description correctly implies no inputs are needed by framing this as an unfiltered personal listing.

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?

Specific verb (list) plus resource (saved searches), and it names the returned fields: filters and email-enabled status. It also pre-emptively separates itself from search_jobs by stating it does not run searches or return matching 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 exclusion sentence ('does not run the searches or return matching jobs') implicitly routes the agent to search_jobs when job results are wanted, and the sibling set contains search_jobs and save_search to make that inference easy. It stops short of naming an explicit alternative or stating prerequisites, so it is clear context rather than full when/when-not 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 declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the bar is lower; the description still adds real context by disclosing the side effect on the saved state and the confirmation gate. It could go further by saying exactly what clearing destroys (the applied mark only, not the saved job) in explicit terms, but 'clearing keeps it saved' largely covers this.

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

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

Four short sentences, front-loaded with the core action, then side effects, then the safety precondition. Every sentence carries distinct information with no repetition of the title or annotations.

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 two-parameter mutation with no output schema and rich annotations, the description covers the confirmation gate, the save-state side effect, and the service's non-submitting nature. The remaining gap is the mapping of the applied flag to mark vs. clear, which leaves the parameter behavior underspecified.

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 full burden for two parameters — yet it never names job_id or applied, never states that applied=false is the clearing operation, and never mentions the default of true. 'Or clear that mark' only implicitly gestures at the boolean; an agent must read the schema to map intent to argument.

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 ('Record that the user applied to a job') and covers both directions of the toggle ('or clear that mark'). It also explains the relationship to the adjacent save_job behavior ('Marking also saves the job; clearing keeps it saved'), so an agent can distinguish it from save_job without opening the schema.

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 precondition: 'Only call after the user confirms they submitted the application themselves,' plus a scope exclusion ('Offpeak never submits applications'). It does not name save_job or other siblings as alternatives, but the side-effect sentence makes the division of labor 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, idempotentHint, and destructiveHint=false, so safety is covered. The description adds substantial behavioral context beyond annotations: it explains fuzzy matching (typos, accents, flexible spacing), abbreviation handling (st/saint, ft/fort, mt/mount), ranking logic (exact and prefix matches first), and that ambiguous addresses can return multiple candidates.

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 three sentences, front-loaded with the purpose, and every sentence adds value: the first states what it does, the second clarifies input handling and ranking, and the third warns about multiple 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?

For a geocoding tool with no output schema, the description adequately explains the return shape ('candidate coordinates') and input behavior for the required parameter. The only gap is the unexplained optional `near` parameter, which prevents a perfect score.

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

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

With 0% schema description coverage, the description must explain both parameters. It thoroughly covers the `query` parameter's syntax and acceptable variations, but the optional `near` parameter (a nested object with lat/lng) is never mentioned, leaving one of two parameters undocumented.

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 ('resolve') and resource ('US address or place to candidate coordinates'), making it immediately clear what the tool does. It is easily distinguishable from all sibling tools, which are job-search-related.

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: it resolves US addresses/places, accepts typos and abbreviations, and may return multiple candidates for ambiguous inputs. It does not explicitly state when not to use the tool or name alternatives, but no comparable sibling exists, so this is adequate.

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 destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds only the vague phrase 'on your connected account'; it does not explain that setting saved=false removes an existing bookmark, what happens for nonexistent jobs, or any return behavior.

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 front-loaded sentence with no filler; the structure is efficient. It is arguably too terse for the behavioral burden, but the sentence itself 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 two-parameter destructive mutation with no output schema and zero schema descriptions, the definition is under-specified. Annotations cover idempotency and destructiveness, but an agent still lacks guidance on auth requirements, invalid job_id handling, and the exact effect of saved=false.

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, but it only loosely maps 'save or unsave' to the saved boolean and 'job' to job_id. It omits the integer/positive constraint on job_id and does not clarify the toggle semantics of the saved flag.

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 gives a verb (save/unsave) and resource (job) plus a weak scope note ('on your connected account'), but it essentially restates the tool name and title. It does not distinguish this mutation tool from the sibling read tool get_saved_jobs, leaving an agent to infer the difference from names alone.

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

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

There is no explicit guidance on when to call this versus get_saved_jobs or save_search, and no mention of prerequisites such as needing an authenticated connected account. The only usage cue is the implicit 'save/unsave' toggle.

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?

Adds genuinely useful behavior beyond annotations: a hard quota of 50, that saved preferences are left untouched, that email notifications default to off, and that re-saving returns the existing entry rather than creating a duplicate (reinforcing idempotentHint). It stops short of saying what happens when the 50 limit is reached or what errors/permissions apply.

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

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

Four tight sentences, front-loaded with purpose and capped by dedupe semantics; no filler. The sentences are slightly telegraphic but every one carries a distinct fact.

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?

Adequate for a two-parameter tool with a richly annotated nested schema, but for a mutation that creates persistent account records it omits what the call returns (a saved-search id?), what occurs at the 50-search cap, and how it relates to update_search/delete_saved_search.

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

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

With 0% top-level schema description coverage, the description carries the burden and only partially does so: 'uses saved filters with optional overrides' clarifies that the filters object is a sparse override of existing saved filters, which is real added meaning. The 'name' parameter and the return value are never mentioned, leaving a clear 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 and resource ('Save a search to your account') plus a concrete constraint (up to 50), which is more than a restatement of the title. It does not explicitly distinguish itself from update_search, set_filters, or set_search_email, so an agent must infer the boundary from wording alone.

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?

Implied routing is present: 'does not change saved preferences' and 'Email is initially off and can be enabled separately' nudge the agent toward set_filters/set_search_email for those concerns. However, no sibling is named and there is no explicit 'use this when... instead of update_search' 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?

Beyond readOnly/idempotent annotations, it discloses that drive times use typical weekday rush-hour traffic, results are a stable snapshot with one fastest site per job, keyword matching expands to related titles and corrects unknown words, and cursors expire after 15 minutes. These are substantive behavior facts an agent cannot get from the annotations or 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?

Dense but economical – each sentence carries a distinct operational fact (origin requirement, keyword behavior, auth, pagination). It is somewhat telegraphic and parallel, but no sentence is 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 nested-filter search tool with no output schema and no sample coverage, member coverage of return shape (one fastest site per job), freshness/pagination, and auth (filters:read, jobs:read for saved_only implied) is strong. Minor gaps remain on default sort/mode behavior and intersection semantics of multiple filters.

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 low (33%), and the description compensates: it clarifies origin is mandatory for anonymous searches while home is only a display label, explains keyword expansion behavior, and states the cursor/filters exclusivity for pagination. It leaves many nested filters (mode, sort, level, min_pay, include_near_misses) to the schema, so it adds value but not complete 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?

States a concrete verb and resource ('Search jobs') scoped to driving commute, and adds a distinctive output fact ('one fastest site per job, stable result snapshot') that separates it from generic listing siblings like get_jobs. It does not explicitly name a sibling alternative, but the scope is unambiguous.

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

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

Specifies the origin-required condition for anonymous searches versus the filters:read saved-filter path, and states 'Overrides never save preferences,' which implicitly routes persistence to set_filters/save_search siblings without naming them. Pagination rules are given (cursor + optional limit, omit filters), so when-conditions are clear, though alternatives are only 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 usefully explains the merge semantics behind destructiveHint=true (omitted fields unchanged, empty strings clear), which annotations alone cannot convey. However it leaves the biggest behavioral question open: whether the change persists to a saved search record or only affects transient search state, and whether it is scoped to the caller's account.

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, front-loaded with the core action and free of padding. It could have spent one of those sentences on scope instead of repeating the origin/home distinction from the schema.

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 nested schema is rich and annotations cover the safety profile, so the description does not need to enumerate fields. What it still omits is the target of the mutation and its relationship to search_jobs/update_search — a material gap for a destructive, non-read-only tool with 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?

Reported coverage is 0% because the single top-level "filters" property is undocumented, but every nested field carries a detailed description, so the schema does most of the work. The description's only parameter detail ("Origin is a coordinate pair; home is its display label") restates what the nested schema already says verbatim; the genuinely additive piece is the global merge/clear rule.

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?

"Save a partial filter change" gives a verb and resource, but never says what the filters belong to — the current session, a named saved search, or global state. With siblings like get_filters, save_search, update_search and search_jobs, an agent cannot tell from the description which filter surface this mutates.

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?

No when-to-use or when-not-to-use guidance is given, and no sibling is named. The partial-merge rule hints at PATCH-style usage but does not say when to call set_filters instead of search_jobs, save_search or update_search.

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 destructiveHint=true, idempotentHint=true, and openWorldHint=true; the description adds real value on top by disclosing the quota cap (20), the verification prerequisite, and critically that turning off preserves the saved search. It does not say what happens if the 20-cap is already hit, which keeps it off a 5.

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

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

Four short sentences, front-loaded with the action, followed by quota, the verification gate, and the disable semantics. Nothing is repeated and every sentence adds a distinct fact.

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 two-parameter toggle with no output schema, the description covers the important unknowns: quota limit, verification dependency, and non-destructive disable behavior. Only the failure mode at the 20-search cap is left unstated.

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 carry the load: 'for one saved search' implies a single saved_search_id and 'or stop' implies the boolean enabled toggle. That's adequate but implicit — it never states that the toggle is the enabled flag or that the ID is a UUID.

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?

Names a specific verb (email new matching jobs / stop) and a specific resource scope (one saved search, to your account email). An agent can immediately distinguish this from save_search, set_filters, and delete_saved_search without opening any schema.

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 clear operating context: up to 20 saved searches may have email on, and email only flows after account email verification. It doesn't name a sibling alternative (e.g. delete_saved_search for removing the search itself), but the on/off framing makes the when-to-use condition obvious.

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 destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuinely non-obvious behavior: omitted filters are preserved (merge semantics), the ID/name/email setting survive, account preferences are untouched, and an email-enabled search gets a fresh baseline. It stops short of saying what happens on an invalid ID or whether the change is reversible.

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

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

Four short sentences, front-loaded with the core action, then the merge rule, then preserved state, then the email-baseline consequence. Every sentence adds a distinct fact; nothing is redundant with the title or schema.

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 mutating tool with a nested filter object, no output schema, and annotations that already flag destructiveness, the description covers the behaviors an agent most needs: partial update semantics, identity preservation, and the email consequence. Only error/validation behavior and how to obtain a valid saved_search_id are left unaddressed.

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?

Top-level schema description coverage is 0%, so the description carries the burden, and it delivers the single most important semantic: "Omitted filters stay unchanged," which is a merge-patch contract not stated anywhere in the schema. The nested filter properties are well documented in the schema itself. The gap is saved_search_id, which is undocumented in both places beyond its UUID format.

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?

"Change criteria on an existing saved search in place" gives a specific verb (change), resource (saved search), and scope qualifier (in place) that separates it from save_search (create) and set_filters (active filter state). The follow-on clause enumerating what is preserved further pins down the operation.

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 "on an existing saved search" implies this is the edit path rather than the create path, and "omitted filters stay unchanged" tells the agent a partial payload is valid. But no sibling is named explicitly, so the agent must infer that save_search creates and delete_saved_search removes, and there is no statement of prerequisites such as needing a valid saved_search_id.

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