JobSpidey

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds value beyond that by disclosing cost behavior ('No credit charge') and by defining the two key counters — generation.mcp_bonus vs available_preparations_now and the UTC reset — which is real semantic context not present in any structured field.

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

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

Three sentences, front-loaded with the resource being read before the field-level clarifications. Every sentence carries information, though the phrase 'MCP promotional document allowance' is opaque enough to be near-dead weight for a model unfamiliar with the product vocabulary.

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 must carry the return shape, and it only partially does: it explains generation.mcp_bonus and available_preparations_now but leaves 'readiness', 'sources' and 'templates' as unelaborated labels whose structures are unknown. Adequate to decide whether to call it, but not sufficient to predict the response 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, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description instead spends its words on return-value semantics, which is the right allocation for a no-arg tool.

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?

Opens with a specific verb+resource: 'Read account readiness, ... credit limits, sources and templates.' That clearly separates it from the job/application-centric siblings, which all deal with postings and applications rather than account state. The only drag is that 'MCP promotional document allowance' and the dotted field names are jargon an agent must infer.

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: the description tells you what the returned fields mean ('free preparations remaining') and that there is 'No credit charge,' which nudges an agent to call it before spending credits on prepare_application. It never explicitly says when to call this versus another sibling, nor states any preconditions or when-not conditions.

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

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

Annotations already cover read-only/idempotent safety, and the description adds substantial context beyond them: required scopes (applications:read, documents:read), a five-minute link expiry that also triggers on disconnect or permission change, presence of candidate data, and no credit charge. That is exactly the extra behavior an agent needs.

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 what is returned, followed by prerequisites and operational caveats. No filler or repetition.

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

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

With no output schema, the description correctly describes the return payload (validated PDFs and extracted text/manifest), and it covers auth scopes, link lifetime, and cost. Nothing material for correct invocation is missing for a single-parameter read 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 0% for the single integer application_id, so the description carries the burden, but it adds no meaning about the parameter's format or source. The parameter is self-evident by name, so this is not a severe gap, but nothing beyond the schema is contributed.

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 (Retrieve) and a precise resource (validated PDFs plus extracted text/manifest) scoped to an application package. Unlike siblings such as get_candidate_context or prepare_application, it is clear this returns the assembled document bundle rather than context or a mutation.

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 name and the required application_id, but the description never states when to call this versus get_candidate_context or prepare_application, nor any preconditions beyond the required scopes. It gives operational constraints (expiry, credit cost) but no routing guidance between alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real value beyond them: the required profile:read scope, the additional resume:read scope for raw resume text, and the caution that unknown skills or eligibility are not established by saved facts.

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 dense sentences with no filler; the core action is front-loaded, followed by the attribution caveat and then the auth requirements. Every sentence carries distinct 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?

With no output schema, the description must convey return semantics, and it does so (saved facts with provenance, unknown fields). Auth scopes and the resume caveat round it out; only the single boolean parameter's behavior/default 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?

There is one parameter (include_resume_text) with 0% schema description coverage, so the description must compensate. It partially does by noting the raw resume requires resume:read, which implies what the flag exposes, but it never names the parameter or states the default (false).

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: reading saved candidate facts with provenance and unknown fields. It is distinguishable from most siblings (get_job, list_applications) but does not explicitly differentiate itself from the closely related get_account_context, so it stops 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?

Usage is implied by the stated content (read saved candidate facts) and the scope prerequisites, but there is no explicit when-to-use or when-not-to-use guidance, nor a named alternative such as get_account_context for account-level data. Adequate but with clear gaps.

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, so the safety profile is covered. The description adds two things beyond annotations: the required 'jobs:read' scope (auth requirement) and a prompt-injection warning that job text is untrusted source data, never instructions - genuinely valuable 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?

Four short sentences, front-loaded with the core action and return values, then retrieval mapping, then auth and safety. Each sentence adds a distinct piece of information with no padding.

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 full annotation coverage and no output schema, the description covers return contents, parameter provenance, auth scope, and a safety caveat. Little an agent needs 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 description coverage is 0%, so the schema only provides type/pattern/length for job_id. The description compensates partially by explaining that the job_id is the one mapped to the customer's earlier shortlist selection, adding provenance meaning but no format or validation detail.

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 (Read) and resource (a saved job's details, original posting link, result_position), so the agent knows exactly what comes back. It doesn't explicitly name sibling tools like search_jobs or load_more_jobs to differentiate scope, but the 'saved job' framing is distinctive enough.

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

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

Usage is implied via 'Retrieve the job_id mapped to the customer's earlier shortlist selection', which tells the agent the sourcing context. However, there is no explicit when-to-use versus alternatives such as search_jobs or load_more_jobs, nor any 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?

With annotations present, this adds real context beyond them: required auth scopes (jobs:read or documents:generate), the cost guarantee ('no new request or duplicate charge'), and the side-effect disclosure ('may resume that accepted work') that explains why readOnlyHint is false despite idempotentHint being true. It stops short of describing completion or error statuses returned by the poll.

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 clauses, front-loaded with the core action, and each one carries distinct information (what to poll, cadence, auth/cost, side effect). No filler, though the clauses are telegraphic enough to require a second read.

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 polling tool with no output schema, the description supplies retry_after_seconds and the cost/auth profile, which is meaningful. It omits what a completed or failed operation returns and how the agent should interpret terminal states, leaving the polling loop only partially specified.

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 one parameter, operation_id, with 0% schema description coverage and no mention in the description, so the agent gets no help on where the value comes from, its 32-hex-char format, or its lifecycle. The phrase 'an accepted search or preparation' only loosely hints at the source of the id.

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 ('poll') and the resource it operates on ('an accepted search or preparation'), which maps to the search_jobs and prepare_application siblings without naming them. An agent can tell this is the follower for previously-accepted async work, though the naming is indirect rather than an explicit sibling callout.

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 implies the trigger condition ('an accepted search or preparation') and the polling cadence ('follow retry_after_seconds'), so usage is reasonably inferable. However, it never states when to stop polling versus retry, nor contrasts the tool against any named alternative, so guidelines remain implicit.

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 read-only, idempotent, non-destructive, closed-world behavior. The description adds two things annotations cannot convey: the required scope (applications:read) and that the call carries 'No credit charge', plus the hint that the list is 'bounded' (i.e., capped). That is genuine value beyond structured fields, though pagination mechanics remain unstated.

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, front-loaded sentences with no filler or repetition. It is efficient, though arguably clipped to the point of omitting needed detail rather than being exemplary.

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 four undocumented parameters, no output schema, and no explanation of return shape, pagination, or how the enum status values behave, the definition is under-specified for the tool's complexity. The auth and cost notes are helpful but leave the operational contract largely unexplained.

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% across four parameters (limit, query, cursor, status), and the description supplies no parameter meaning at all. An agent must infer from bare property names that cursor drives pagination and status filters the list, which is exactly the gap the description should have filled.

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 ('Read') and the notion of a bounded list are present, but the resource is described as a 'Track Jobs list' rather than applications, which is jargon the agent must map back to the tool name. Sibling tools like list_search_results and get_job are not distinguished, so an agent gets only a vague sense of what this returns.

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 statement of when to use this tool versus search_jobs, list_search_results, or get_job. The only contextual cue is an authorization requirement ('Requires applications:read'), which is a prerequisite, not usage guidance.

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

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

Goes well beyond the annotations (which only cover read-only/idempotent/no-destructive safety): it discloses ordering stability semantics (result_position is stable saved-search order, display_rank may change), warns that relevance_score is an automated hint and not verified candidate fit, states the required auth scope (jobs:read), and notes there is no credit charge.

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 dense telegraphic clauses with no filler; every sentence carries distinct information (stability, ranking caveat, ID preservation, scope, cost). The clipped style is efficient but borders on terse, with several facts packed into adjective-less fragments.

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 usefully describes the return shape's semantics (result_position, display_rank, relevance_score, job_id/search_id) and covers auth, cost, and paging stability. Remaining gaps are cursor mechanics and any explicit page_size guidance, so it falls short of fully complete rather than being deficient.

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% and the description only partially compensates: it implies search_id's role via 'explicit search' and 'preserve ... search_id', and 'bounded page' loosely gestures at page_size. The critical cursor parameter — how to obtain and pass it to advance pages — is entirely undocumented anywhere, which is the single most important mechanic for a paginated list tool.

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 — reading a bounded page of results from an explicit search — and pins the scope with 'even after another search', which distinguishes it from re-running a search. It does not name sibling tools like search_jobs or load_more_jobs, so the differentiation is implied by behavior rather than 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?

Gives clear usage context: this is the tool for re-reading a page of an existing search without reissuing it, and it instructs the agent to preserve job_id/search_id for follow-ups. However, it never states when NOT to use it or names the alternative (search_jobs, load_more_jobs) for those 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, idempotentHint=true and destructiveHint=false, so safety is largely covered structurally. The description adds real context beyond that: the required scopes (jobs:search + jobs:read) and the idempotent retry contract via request_id, which explains why the operation is marked idempotent despite not being 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?

Two short sentences, zero filler, and the core purpose is front-loaded before the permissions and retry caveat. Nothing could be removed without losing 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 cursor-pagination tool with no output schema, the description should say what comes back (next page of jobs, updated cursors, whether exhaustion is signaled). It covers permissions and retry but leaves the return behavior and pagination termination 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% and both parameters are required, so the description must compensate. It does explain request_id's retry semantics and implies search_id comes from the prior 'explicit search', but it never states that search_id is the ID returned by the initial search call or what format it takes (32-hex).

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 ('Extend') and resource ('an explicit search using its provider cursors'), which distinguishes it from search_jobs (initiating a search) and list_search_results (reading results). It does not name a sibling directly, but the phrase 'explicit search' makes the pagination role clear.

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?

Implies the tool is used to continue a previously initiated search, and gives a retry rule ('retry with the same request_id'), which is useful operational guidance. However, it never states when to prefer this over search_jobs or list_search_results, nor any precondition that a prior search_id must exist.

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

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

Discloses behavior annotations cannot convey: the billing order (promotional allowance first, then one normal credit), budget limits, and that it never submits to an employer. It also explains the idempotency contract behind idempotentHint in operational terms ('retry identical input with the same request_id; completed packs are reused without another charge').

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?

Five short sentences, purpose front-loaded, then prerequisites, cost, retry semantics, and the safety boundary in descending priority. No sentence is redundant and none repeats structured data.

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 5 parameters, nested option objects, no output schema and no field descriptions, the description covers cost, idempotency, prerequisites, and side-effect boundaries well. It leaves a gap on how a target is selected (job_id vs custom_job) and what the agent receives back, which matters for a charging operation.

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

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

Schema description coverage is 0%, so the description carries the burden and only partly does: it explains request_id's retry role and hints at single-target selection via 'exactly one target'. The job_id vs custom_job exclusivity, the options object (resume_template, base_resume_text, resume_targeting_mode), and application_id are left entirely to the bare 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 ('Prepare one resume and cover letter') with a hard scope qualifier ('for exactly one target'). It does not name which sibling to prefer, but the resource is concrete enough that no sibling tool could be confused with it.

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 real preconditions and routing: 'Requires documents:generate' and 'Read get_account_context for the current bonus and limits' name a sibling to consult first. It also draws a clear boundary ('Never submits to an employer'), though it never explicitly contrasts with get_application_package for retrieving an already-built pack.

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?

Goes well beyond the annotations: states the required scope (applications:write), that the report is unverified, that only the 'applied' outcome advances the tracker, and that request_id must be reused to make retries idempotent. The annotations already cover side-effect safety, and the description adds the auth and idempotency mechanics an agent needs.

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, each doing distinct work: purpose, permission, outcome semantics, idempotency, and negative scope. The most decision-relevant content (what it records and what it does not) is front-loaded.

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

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

For a 5-param mutation with no output schema and no annotation-supplied behavior, the description covers auth, idempotency, outcome effect, and negative scope well. The remaining gap is the meaning of reference and submitted_at and what happens on a rejected or duplicate report.

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 and it only partially compensates: it explains the semantics of request_id (retry key) and outcome (only 'applied' moves the tracker). It says nothing about application_id, reference, or submitted_at, leaving three of five 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?

States a specific verb and resource ('Record an ... external outcome') and immediately scopes it as an *agent-reported* record. It also draws a sharp boundary against the sibling prepare_application by declaring 'Does not submit an application or verify evidence,' so an agent can distinguish it 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 (this is for reporting an outcome that happened externally, not for submitting) and an explicit retry rule ('Reuse the same request_id for retries'). It never names the alternative tool to use for actually submitting an application, so routing guidance is implied rather than explicit.

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

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

Goes beyond the annotations by disclosing the retry contract ('Reuse request_id for identical retries'), which explains the mechanism behind idempotentHint=true, the cost profile ('No generation credit charge'), and the required permission scopes. It does not explain what readOnlyHint=false actually mutates (the created search operation), leaving that inference open.

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 clauses, each front-loading the operationally important facts (initiation, permissions, retry, cost). Zero filler, though the terseness edges toward omission rather than optimal conciseness.

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?

Covers the key operational concerns an agent needs to invoke it correctly (permissions, idempotent retry, no credit charge). With no output schema and 0% parameter coverage, it leaves the criteria contract and the expected return/handle entirely 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 coverage is 0% and only request_id gets any semantic treatment (retry reuse). The nested criteria object — job_title, country, salary range, remote_preference, posted_within_days — carries no descriptions in the schema and none in the description, so the bulk of the search surface is 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?

States a specific verb and resource: 'Start an owned job search.' The word 'owned' and 'Start' distinguish it from siblings like load_more_jobs and list_search_results, which read as follow-up/read tools. It stops short of naming those siblings explicitly, so it is clear but not fully differentiated.

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: 'Start' positions it as the initiation step, and 'jobs:search + jobs:read required' supplies a prerequisite scope. There is no explicit when-to-use-this-vs-alternatives statement or exclusion guidance referencing load_more_jobs / list_search_results.

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