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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: it discloses pagination behavior and, notably, that each response includes a system_instruction telling the client how to present results — non-obvious behavioral context.

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?

Front-loaded with the purpose, then cleanly sectioned into Input and Output blocks. It is slightly redundant with the input schema (limit/offset/status repeated verbatim), but not verbose and every section is easy to scan.

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 tool is simple (3 optional params, no nesting) and an output schema exists, so return values need not be explained. The description still covers filtering, pagination and the system_instruction behavior, leaving little an agent would need to guess at.

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 description largely restates the same limit/offset/status details. It adds only a marginal clarification (status default is "all statuses" and that all three params are optional). Baseline 3 is appropriate when the schema already documents every 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?

States a concrete verb and resource ("Lists the authenticated user's job alerts") and adds meaningful scope ("across all subscription sources (regular, company page, MCP)") that goes beyond the name. It does not explicitly contrast itself with siblings like jobs_recommendations or jobs_search, so it falls short of a 5.

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 the way to enumerate the user's own alerts, but gives no explicit when-to-use guidance, no exclusions, and no pointer to alternatives such as jobs_recommendations. Usage is inferable from the name and scope 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?

Annotations already declare idempotentHint=true and destructiveHint=false, but the description goes well beyond them: it spells out the exact idempotency rule (existing alert matched on query text, location, company, filters, and at least the same radius), that the requested frequency is applied to the returned alert, and the delivery semantics (one digest, deduplicated jobs, Pro-only filters, cadence).

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?

Bold section headers (Input/Output/Delivery) front-load the purpose and required parameter, and the Input/Output blocks earn their place. The Delivery paragraph is informative but longer than needed to select and invoke this tool, describing email behavior that doesn't change the call itself.

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 an output schema present, return values need not be explained, yet the description still covers idempotency, default frequency, accepted ID formats, and downstream delivery effects. Nothing an agent needs to invoke this tool correctly is missing.

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

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

Schema description coverage is 100%, so both parameters are already documented, and the description largely restates them (UUID vs composite ID format, default 'weekly'). It adds no syntax or validation detail the schema lacks, so the baseline 3 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?

States a specific verb and resource — 'Subscribes the authenticated user to job alerts for a specific saved job search' — which cleanly separates it from job_alert_unsubscribe, job_alert_unsubscribe_all, and job_alert_list. An agent can identify the action 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 clear context for use (subscribe to a saved job search) and points to jobs_search / jobs_details as the source of the accepted composite ID format. It does not explicitly state when to prefer this over the unsubscribe siblings or what prerequisites apply, so it stops short of a full when/when-not 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 declare destructiveHint=true and readOnlyHint=false. The description adds genuinely new behavioral context: the operation is idempotent and returns success even if the user was never subscribed. That is not derivable from 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?

Front-loaded single-sentence purpose followed by tight input/output notes. Every sentence earns its place; no filler or 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?

An output schema exists, so return-format detail is unnecessary. The description covers the required input's accepted forms and the idempotency edge case, leaving little an agent needs beyond it.

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

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

Schema description coverage is 100%, so the schema already documents the job_search_id format. The description restates the same UUID/composite-ID detail without adding syntax or validation info beyond it; baseline 3 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?

States a specific verb and resource: 'Unsubscribes the authenticated user from job alerts for a specific job search.' The 'specific job search' scope implicitly separates it from the sibling job_alert_unsubscribe_all, though it never names that sibling.

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?

Usage is implied by the description's scope and the parameter explanation, but there is no explicit when-to-use vs. when-to-use-alternative statement, and the obvious alternative (job_alert_unsubscribe_all) is never referenced.

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 new context: the confirm guard's rejection behavior and the explicit idempotency claim ('returns success even when the user has no active alerts') plus the source 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?

Front-loaded purpose sentence followed by tight Input/Output sections. Every sentence carries distinct information with 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 single-parameter bulk mutation, the description covers the confirm requirement, the safety rationale, source scope, and idempotency, while the output schema carries the return value. Nothing needed 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?

Schema coverage is 100% and the single parameter is documented there, so baseline is 3. The description adds the rationale behind the guard ('guards against an unintended bulk unsubscribe'), giving the agent the meaning of the flag beyond its schema text.

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 + resource + scope: 'Unsubscribes the authenticated user from ALL of their job alerts at once, across every subscription source.' It clearly distinguishes itself from the singular sibling job_alert_unsubscribe by emphasizing the bulk/all scope.

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 'ALL ... at once' framing implicitly routes the agent away from the single-alert sibling, and it enumerates the subscription sources covered. However, it never explicitly names job_alert_unsubscribe as the alternative for single-alert cases, so exclusion guidance is inferential.

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

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

Annotations only declare readOnlyHint=false/destructiveHint=false/openWorldHint=false. The description goes well beyond that: it states what FoundRole does server-side (validates evidence, stores client extraction separately, derives missing deterministic facts, reports provided/derived/accepted/rejected/unknown), and candidly frames the analysis as a decision aid rather than a guarantee.

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 purpose is front-loaded and the routing instruction sits near the top where it matters. Three paragraphs is somewhat long and the middle paragraph is dense, but each block carries distinct information with little 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 16-parameter, output-schema-backed tool, the description covers the input contract conventions, the server-side validation semantics, the comparisonRef handoff, and the limits of the result. Nothing an agent needs to invoke 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?

Schema coverage is already 100%, so the baseline is 3, but the description adds genuine meaning: the five text identity fields are required while every structured fact is optional and simply omitted/null when the source is silent, and client_extraction labels must be evidence-backed. These rules are not obvious from the schema alone.

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 opening sentence gives a specific verb and resource ('Analyzes one job found outside FoundRole') and enumerates the exact signals computed (resume match, missing skills, H-1B history, E-Verify, ghost-job risk, compensation, market salary). It is clearly distinguishable from sibling tools like jobs_details and tracker_add_external.

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 routes the agent explicitly away from this tool in one case ('Use tracker_add_external only when the user asks to save without analysis') and forward to jobs_compare via comparisonRef. That is real when/when-not guidance, though it doesn't differentiate from jobs_details or jobs_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 this is a read-only, non-destructive, closed-world operation, so the safety profile is covered. The description adds real behavioral context beyond that: a 2-4 reference bound, the requirement to preserve exact reference strings and user order, and a no-duplicates constraint. It stops short of describing what the comparison output looks like, though an output schema exists.

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 core action and field list are front-loaded in the first sentence, with the reference-format guidance second. Two paragraphs with no filler; slightly dense but every sentence carries a constraint the agent must honor.

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

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

For a single-parameter read tool with an output schema and full annotation coverage, the description supplies everything else needed: input provenance, prerequisite analysis step, count bounds, ordering, and dedup. Nothing an agent needs to invoke 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?

Schema description coverage is 100% and the single parameter is documented with minItems/maxItems, so the baseline is 3. The description adds meaning the schema cannot: the two distinct reference types (FoundRole job IDs vs external comparisonRef URLs), the requirement to pass them exactly, and the ordering/dedup rules.

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 ('compares 2 to 4 jobs side by side') and enumerates the exact analysis dimensions returned (resume match, missing skills, H-1B/E-Verify, ghost-job risk, pay, salary estimates). This clearly separates it from jobs_details and jobs_analyze_external, which handle single 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?

Explicitly routes the agent: it names jobs_search as the source of job IDs and jobs_analyze_external as the source of external comparisonRef URLs, and states the prerequisite that an outside job must be analyzed first. It also states the failure condition — a bare unanalyzed URL cannot be compared — which is exactly the when-not guidance an agent needs.

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, yet the description describes a pure fetch — a mild tension worth noting, though not a hard contradiction since personalization/entitlement resolution can be non-read-only. The description does add real context beyond annotations (entitlement-dependent fields, the remoteCheck payload semantics), but it does not clarify auth requirements or why the tool is not read-only.

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?

Front-loaded with the core action, then cleanly separated into Input and Output blocks that are easy to scan. It is slightly long, but the Output section carries non-obvious information (entitlement gating, remoteCheck shape) 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?

With an output schema present, the description is not obligated to enumerate return fields, yet it still summarizes them usefully and clarifies the conditional remoteCheck field. Missing only auth/entitlement prerequisites for a tool whose results vary by the authenticated user.

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

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

Schema coverage is 100%, so the baseline is 3, and the description earns an increment by tying each parameter to its originating field in a jobs_search result (`id` and `resultItemId`), which the schema itself does not establish. It adds genuine cross-tool semantics rather than restating types.

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+resource ('Fetches full details for one job') and explicitly anchors it to the `id` returned from jobs_search. An agent can distinguish it from jobs_search, jobs_compare, and jobs_analyze_external 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?

Frames the tool as 'the deeper view behind a search result,' which implies the correct usage sequence (search first, then fetch details by ID). It does not state exclusions or name a competing sibling for retrieving a single job, so it stops short of the explicit when/when-not guidance a 5 requires.

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 substantial context beyond the annotations: results are fit-ranked, may include related roles, carry the same insights payload as search, and free vs Pro accounts receive different result completeness (preview plus hidden count vs the full filtered list). It also documents the asynchronous processing status and that a later call returns the completed feed, which the annotations (idempotent, non-destructive, closed-world) do not 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?

Front-loads the core purpose, then ambient behavior (ranking, insights), then tiering, then the jobs_search fallback and pagination/status semantics. Three compact paragraphs with little waste, though slightly longer than strictly needed for a read-style tool.

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 an output schema present, return values need not be described, and the description covers the remaining gaps an agent needs: what determines the feed, tier-gated completeness, async processing, pagination continuity, and the fallback search path. Nothing material for correct invocation 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% across 23 params, so the schema carries the per-parameter burden (baseline 3). The description still adds non-obvious parameter behavior: the search filters and sort apply to the personalized feed, and advanced parameters change output scope by account tier, which the schema does not state.

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 — returns the authenticated user's personalized job recommendations — and states the inputs that build them (resume, skills, target roles, preferred location). It also distinguishes itself from jobs_search by explaining the fallback path when an explicit query names a different or unrecognized profession.

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 explicit routing: an explicit query outside the profile's target roles routes to the same general search as jobs_search rather than substituting the profile. It also notes how pages retrieve more of the same feed and what a processing status means. It stops short of stating outright when to prefer this over jobs_search for a normal query.

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 carry only readOnlyHint/openWorldHint/destructiveHint, so the description does the heavy lifting: it discloses pagination via nextCursor and the cursor-only protocol, entitlements-gated result truncation for non-Pro accounts, profile-driven personalization, strict_remote vs remote semantics, and that constraints left out of the call are simply not applied. This is far beyond what the 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?

The content is valuable but the middle and later paragraphs largely restate semantics already encoded in the 100%-covered schema (work_modes vs remote independence, strict_remote/confirmed_work_from, the advanced-filter list), producing a dense wall of text with meaningful redundancy. Front-loading is good, but several sentences do not earn their place against 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?

For a 23-parameter, zero-required search tool with an output schema, the description covers the remaining unknowns an agent needs: profile/entitlement behavior, pagination protocol, the id-to-jobs_details handoff, and the fact that omitted constraints are not applied. Return-value explanation is correctly delegated to the 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 coverage is 100%, yet the description still adds mapping value by translating natural-language constraints (remote-only work, H1B sponsorship, salary floor, hiding risky postings) onto the exact parameter names remote, h1b_sponsors_only, salary_floor, hide_low_quality, min_match, and by noting sort only when ordering by salary/match and companies only for multiple employers.

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 opening sentence states a specific verb and resource — 'Searches a database for real-time job listings' — and the rest of the description makes clear how it differs from jobs_recommendations, jobs_details, and jobs_analyze_external. An agent can select it without opening any sibling 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?

Explicit routing rules: use jobs_details with a result's `id`/`resultItemId` for full posting text; an omitted or profession-matching query falls into the same personalized feed as jobs_recommendations; a different profession falls back to general search. It also states when advanced filters apply and what happens without Pro.

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 (readOnly, idempotent, openWorld=false), so the description's job is added context — and it delivers: empty groups rather than padded off-topic results, closest-match (non-exhaustive) semantics, facet behavior, and a system_instruction included in each response. It does not mention pagination or rate limits, but nothing essential is missing.

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?

Front-loaded with the core operation, then facets, then boundaries with siblings. It is on the long side and some enumeration of site-page types (Pro plan, H1B salary data, AI job search) borders on padding, but nearly every sentence carries routing or behavioral 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?

An output schema exists, and the description correctly refrains from re-explaining return values while still flagging the embedded system_instruction and the empty-group behavior. Combined with clear sibling boundaries and facet disambiguation, an agent has everything needed to select and 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?

Schema coverage is 100%, so baseline is 3, but the description adds genuine meaning beyond it: 'company' maps to employer profile pages and 'location' maps to an analytical market landing page, not job listings, plus the disambiguation rule that a company mentioned in passing does not need the facet. That goes past restating schema text.

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 precise verb+resource ('Searches FoundRole's published content by semantic similarity') and enumerates the corpora searched (blog articles, product/site pages, sector landings). It explicitly distinguishes itself from siblings jobs_search and knowledge_topics, so an agent can route 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?

Names the alternatives and the conditions that select them: 'questions about overall topic coverage are answered by knowledge_topics' and 'It does not search job listings... jobs_search covers live roles'. It also gives a when-not for the optional facets ('a company mentioned only in passing does not need the company facet'). This is explicit when/when-not/alternative 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 readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds useful behavioral context beyond that: it takes no parameters, reflects the live published corpus (a freshness guarantee, not a cached snapshot), and enumerates what the response contains (categories, tags, per-item article counts and URLs, plus a total). It stops short of stating pagination or result-size limits, so not a full 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?

Front-loaded with what is returned, then the routing rule, then the no-parameter/freshness note. Every sentence carries information, but the return-value enumeration partially duplicates the output schema, which is mild redundancy rather than 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 an output schema present, the description needn't explain return values, yet it still names the resource, the freshness behavior, the absence of parameters, and the sibling handoff. Nothing an agent needs in order to call this correctly is missing.

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

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

The tool has zero parameters, which establishes a baseline of 4; the description correctly and explicitly confirms 'It takes no parameters', removing any doubt that filtering arguments might exist.

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 (lists) and resource (blog categories, most-used tags, counts, URLs, total article count) and explicitly contrasts with the sibling that does something similar but different: 'It does not retrieve articles for a specific question; knowledge_search does that.' An agent can distinguish it from knowledge_search without opening either 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 both the when ('the factual source for questions about the blog's topics or overall coverage') and the when-not, naming the alternative tool that handles the excluded case (article retrieval for a specific question goes to knowledge_search). Nothing is left to inference.

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 readOnlyHint=false, so the safety profile is covered. The description adds the specific effect — the reminder is removed and reminderAt is cleared while the tracked job survives — which is genuinely useful context beyond the annotation. It does not mention irreversibility or auth, keeping it short of 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?

Front-loads the action in one sentence and uses labeled Input/Output blocks that scan quickly. Reasonably tight, though the bolded section scaffolding is slightly heavier than the single-parameter tool needs.

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 annotations covering destructiveness and an output schema documenting the returned tracked job, the description supplies the one thing not in structured fields — what specifically gets cleared. Complete enough for a one-parameter destructive 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?

Schema description coverage is 100% and the description's tracked_job_id text is essentially identical to the schema's, so it adds no new meaning. Baseline 3 applies when the schema does the heavy lifting; the disambiguation from trackable.id/job.id is helpful but already 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?

States a specific verb and resource ('Deletes a reminder from a tracked job'), scoping it to a job rather than reminders generally. An agent can distinguish it from reminder_set and reminder_list without opening either 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?

Usage is only implied by the sibling set (reminder_set/reminder_list) and the destructive verb; there is no explicit statement of when to use delete versus clearing via tracker_update, nor any prerequisite or caution. Minimum viable routing 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds genuine behavioral context not present elsewhere: the soonest-first ordering and the max-50 cap. It does not cover pagination beyond limit, empty-result behavior, or permission requirements, and the Input restatement duplicates the schema rather than adding to 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?

Front-loaded one-sentence purpose followed by short Input/Output blocks; nothing is bloated. Minor waste in the Input block, which restates the schema's limit description word-for-word instead of adding 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?

A simple, side-effect-free list tool with a rich output schema (return values need not be explained) and full sibling context. Ordering, scope, and the limit cap are the only things an agent materially needs, and ordering plus scope are present; only the alert-vs-reminder distinction is left 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?

There is a single parameter with 100% schema description coverage, so the schema already documents default 20 / max 50. The description merely repeats this verbatim rather than adding semantics, which is the expected baseline 3 for a fully covered 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?

States a specific verb and resource ('Lists tracked jobs that have reminders set') and adds a scope/ordering qualifier ('ordered by reminder time, soonest first'). An agent can distinguish it from tracker_list, job_alert_list, and reminder_set/delete from the description alone, though it never names those siblings 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?

Usage is implied by the purpose (call this to view existing reminders) but there is no explicit when/when-not guidance and no mention of the adjacent alternatives in the sibling list, notably job_alert_list (alerts vs reminders) and tracker_list. Nothing misleading, just under-specified 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?

With annotations already declaring readOnlyHint=false, destructiveHint=true and openWorldHint=true, the description usefully adds the email/ICS side effect and the return payload (updated tracked job with reminderAt). It does not explain what makes the operation destructive (e.g. overwriting an existing reminder), which is the one gap left against a destructiveHint=true 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?

Front-loaded with the core action in the first sentence, then clearly sectioned Input/Output blocks. Slightly padded by duplicating schema parameter text verbatim, but every line is scannable and nothing is buried.

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?

An output schema exists, so explaining return values is optional, yet the description summarizes the reminderAt field, which is helpful rather than harmful. Combines with annotation coverage to give an agent everything needed to invoke the tool correctly, minus any note on idempotency/overwrite behavior.

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

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

Schema description coverage is 100%, so both parameters are already fully documented with identical wording (ISO 8601 example, distinct-ID warning). The description restates the schema rather than adding new syntax or constraints, so the baseline of 3 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?

States a specific verb and resource ("Sets a reminder for a tracked job") and adds the concrete side effect of sending a confirmation email with an .ics attachment. This clearly separates it from reminder_list and reminder_delete in the sibling 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?

Usage is implied by the title and the note that remind_at must be in the future, but there is no explicit when-to-use/when-not guidance or routing to sibling tools such as reminder_delete or reminder_list. Adequate but leaves the agent to infer 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 readOnly/idempotent/non-destructive, but the description goes well beyond them: no file upload, no saved resume or report, no profile change, no application submission, no URL fetching, plus a candid retention caveat and a note that returned website links require separate user action. That is unusually rich behavioral disclosure for a read 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?

Four short paragraphs, front-loaded with purpose, then input behavior, then scope exclusions, then side-effect disclaimers. Every sentence carries information, though the negative-capability list is somewhat exhaustive and could be tightened slightly.

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 an output schema present, return values need not be explained, yet the description still summarizes the readability band and outputs. Combined with the input fallback semantics and full side-effect disclosure, nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100% and the single optional parameter is fully documented there, including the minimum-length constraint. The description restates the pass/omit behavior but adds no syntax, format, or constraint detail beyond the schema, so the baseline of 3 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?

States a specific verb and resource ('checks resume text for machine-readable sections, recognized skills, contact channels, a headline, and experience date ranges') and names the mechanism (FoundRole's deterministic parser). It also explicitly carves out what it is not (ATS test, hiring prediction, file-layout check), so an agent can distinguish it from analysis-adjacent siblings like jobs_analyze_external.

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 branch: pass resume_text when the text is in the conversation, omit it to use the stored primary resume. It further names exclusions ('not a test against a named ATS, a hiring prediction, or a file-layout check') and notes the layout caveat for pasted text, which routes the agent correctly for edge cases.

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, destructiveHint=false, openWorldHint=false, so safety is already covered. The description adds genuinely non-obvious behavior beyond the annotations: repeated saves are idempotent ('return the existing tracked job') and a previously removed job is restored with its earlier status and notes. It does not clarify whether a new status/sub_status passed on a repeated save overrides the stored one, which is a minor gap.

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?

Front-loaded with the purpose and the routing rule, then a scannable field list. The main inefficiency is the full sub_status enumeration, which duplicates the schema text verbatim and consumes a large share of the description without adding meaning.

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?

An output schema exists and the description still summarizes the return ('Returns the tracked job with its details'), and the mutation's idempotency/restore behavior is disclosed. What is missing is any steer toward the related mutation siblings (tracker_update, tracker_update_status) that an agent would need when the job already exists.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds the default value for status ('defaults to "saved"'), which the schema does not state. It also omits any mention of result_item_id (present in the schema) and mostly restates the status/sub_status enumerations verbatim.

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 ('Tracks a job from jobs_search results in the user's job tracker, identified by its job_id') and immediately names the sibling it is not (tracker_add_external). An agent can distinguish this from tracker_add_external without opening either 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?

Explicitly gives the routing condition: use tracker_add for jobs with a jobs_search job_id, and use tracker_add_external for jobs found elsewhere with a URL but no job_id. This is a concrete when-to-use-this-vs-alternative statement rather than implied 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 establish the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), and the description adds important behavior: repeated saves return the existing tracked job, missing facts are omitted rather than blocking, extractors derive missing structured facts, and client_extraction labels are validated and stored separately. These are non-obvious operational traits that go well beyond 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 opening usage guidance is strong and front-loaded, but the long bulleted enumeration of fields largely duplicates the schema descriptions, including enum values already present in the schema. For a 19-parameter tool some length is warranted, but the redundancy makes it less concise than it could be.

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 complex schema, existing output schema, and annotations, the description covers what an agent needs: required vs optional fields, default status, idempotent repeated saves, derivation of missing facts, and the evidence-backed client_extraction contract. Nothing critical is missing for correct 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?

Schema coverage is already 100%, so the baseline is 3, but the description adds useful semantics beyond the schema: it identifies the five required identifying fields, states that status defaults to 'saved', and explains that omitted facts are derived by extractors rather than requiring values. The field-by-field list mostly restates schema descriptions, limiting this to a 4.

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 ('Saves a job posting ... into the user's tracker') and explicitly distinguishes itself from the sibling tracker_add by source and input type. An agent can tell when this tool applies 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?

Explicitly says to use tracker_add instead for jobs that came from jobs_search results, and clarifies that jobs seen elsewhere need no prior jobs_search call. This is precise when-to-use and when-not-to-use guidance tied to a named alternative.

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, destructiveHint=false and openWorldHint=false. The description goes beyond them by disclosing that results come back grouped by status, that pagination metadata is included, and that a system_instruction governs result presentation for the current client — genuinely useful behavioral context for a read 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?

Front-loaded with the one-line purpose, then clearly sectioned Input/Output headings — easy to scan. It loses a point for duplicating the schema's parameter text verbatim, which is redundancy rather than added 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 zero-required-parameter list tool with a full output schema and strong annotations, the description covers purpose, params, and response shape adequately. Nothing critical is missing, though it could note the default ordering of the grouped results.

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

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

Schema description coverage is 100%, so the parameters are already fully documented. The Input section restates the schema word-for-word (default 20, max 50, default 0, enum-like status values) without adding syntax, validation, or interaction semantics beyond it, so the baseline 3 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 description states a specific verb and resource ("Lists the user's tracked jobs") plus scope (optional filtering and pagination), so the agent immediately knows the operation. It does not distinguish itself from tracker_remove/tracker_update/tracker_update_status, but the read-only listing intent is 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?

Usage is only implied: an agent can infer this is the tool for browsing tracked jobs with filters. There is no explicit when-to-use statement, no named alternative (e.g. jobs_search for non-tracked jobs), and no 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is covered without the description's help. The description adds only the output confirmation ('Confirms the job was removed') and the ID provenance; it says nothing about reversibility, required auth, or side effects, so it is an adequate but not rich supplement.

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?

Short and front-loaded: the purpose leads, then Input and Output are cleanly sectioned. Slight waste in restating the schema's parameter description word-for-word, but nothing is bloated or meandering.

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 destructive tool, the description covers purpose, the one input's provenance, and the confirmation result. With an output schema present it need not explain return values, and annotations carry the destructive semantics, leaving only reversibility/auth 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?

Schema description coverage is 100%, so the baseline is 3. The description's parameter text is a verbatim duplicate of the schema's property description, adding no syntax, format, or provenance information beyond what the schema already provides.

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 ('Removes a job from the user's job tracker'), which is unambiguous and cannot be confused with sibling tracker_add/tracker_update/tracker_list. It even disambiguates the identifier space, noting tracked_job_id is distinct from trackable.id and job.id, which is exactly the kind of precision that separates this from neighboring 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?

The intent to remove an existing tracked job is implied clearly enough by the name and description, but there is no explicit when-to-use, when-not-to-use, or reference to alternative tools (e.g., how this differs from job_alert_unsubscribe). Guidance is inferable 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, so the safety profile is covered. The description adds genuinely useful context (reminder_at must be future or empty to clear; tracked_job_id differs from trackable.id/job.id), but it never states whether omitted fields are preserved or whether the update is reversible/partial.

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?

Front-loads the one-sentence purpose, then organizes parameter and output notes under clear Input/Output headers. Slight redundancy with the schema, but no wasted sentences.

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 an output schema present, return values needn't be explained, and the required ID and delta semantics are covered. What is missing is the effect of a destructive/partial update on unmentioned fields, which an agent would want before calling a destructiveHint=true 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?

Schema description coverage is 100%, so the schema already documents every parameter; the description largely restates it, including the reminder_at future constraint and the ID disambiguation. Baseline 3 is correct when the structured schema does the heavy lifting.

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

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

The first sentence states a specific verb (Updates) and resource (tracked job details) and enumerates the affected fields (notes, deadline, salary, tags). It implicitly distinguishes itself from tracker_update_status by enumerating detail fields, but never names that sibling to make the boundary explicit.

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?

Usage is implied: the field enumeration makes clear this is for non-status details, which separates it from tracker_update_status. However, there is no explicit when-to-use guidance, no named alternative, and no statements about 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=false, destructiveHint=true and openWorldHint=false, so the safety profile is covered. The description adds the meaningful behavioral constraint that sub_status is only valid within its parent status, but says nothing about auth requirements, reversibility of a stage change, or side effects such as notifying the employer or altering timestamps.

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 Input/Output structure is front-loaded and easy to scan, but the entire Input block duplicates schema descriptions that are already 100% covered, and the long inline sub_status enumeration is repeated twice across description and schema. Roughly half the text does not earn additional value.

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 an output schema present and rich annotations, the description covers the inputs, the valid value space, and the return shape, which is sufficient for correct invocation. It falls short only on sibling differentiation and on what a status transition actually changes on the tracked job.

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 description's Input section reproduces the schema text nearly verbatim, including the full status/sub_status enumerations. It adds no format, defaulting, or interaction semantics beyond what the schema already documents, so the baseline 3 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 description states a specific verb and resource — updating the status of a tracked job — and the title frames it as moving a job between stages. It is clearly a mutation on a tracked job, but it never distinguishes itself from the sibling tracker_update, which an agent would plausibly consider for the same goal.

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 statement of when to use this tool versus tracker_update or the other tracker_* siblings, nor any prerequisites (e.g., that the job must already be tracked). The only routing hint is that tracked_job_id comes from tracker_list output, which is identification, not usage guidance.

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