Autojob

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

Annotations already declare this is a non-readOnly, open-world, non-idempotent write, so the mutation profile is covered. The description does add one genuinely new fact beyond annotations — that saving an answer also applies existing profile credit rewards — but it omits whether re-answering overwrites a prior answer and what the credit application actually changes.

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

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

A single tight sentence with the action front-loaded and the side effect trailing. Nothing is wasted, though the brevity comes at the cost of the detail noted elsewhere.

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

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

An output schema exists, so return values need not be described, and the schema fully describes the payload. But for a state-changing onboarding write with a credit-granting side effect, the description gives no guidance on section coverage, ordering, or re-submission behavior, leaving the agent to infer workflow from the schema alone.

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 oneOf branches with const sections make the accepted shapes fully self-documenting, so the baseline is high. The description adds nothing about the section/value pairs, but with zero top-level parameters and a complete schema, the schema carries the semantics adequately.

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 'Save' and resource 'eligibility answer' are identifiable, but the description never says which onboarding sections exist (authorization, salary, location, employment, clearance) even though the schema is a discriminated union on them. It also doesn't distinguish itself from the sibling get_onboarding, which reads as the natural counterpart.

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 call this versus get_onboarding (read the current state first?) or update_preferences (a different kind of saved setting). The only hint is the word 'onboarding' in the name, which the agent must infer from.

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 non-idempotency; the description adds genuinely new behavior — that in-flight applications can return a conflict. It does not mention reversibility or side effects on related records, keeping it below 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?

Two short sentences, zero filler, with the precondition and the conflict behavior front-loaded in the order an agent needs them.

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 values need no explanation, and the destructive profile is covered by annotations. The remaining gap is the undocumented id parameter format and any note on related data (attachments, messages) affected by removal.

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%: the single 'id' parameter has only a regex pattern and no prose. The description never states that it takes the application identifier or what format is expected, so it fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('Remove an application') plus a precondition ('that has not started submission'), which clearly separates it from read siblings like get_application/list_applications and from submit_applications. It stops short of explicitly naming an alternative, but the intent is unambiguous.

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

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

Gives a clear use condition (application not yet in submission) and an implicit exclusion (processing applications may return a conflict), which tells the agent when the call will fail. No sibling alternatives are named, so it is not a full 5.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral fact — "Existing limits and credits apply" — implying that configuring the mode consumes credits and is bounded by plan limits, but it never explains what stopping Auto Mode does to in-flight applications or already-queued attempts.

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

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

Two short sentences, the action and its settings front-loaded, with the constraint note trailing. No wasted words and nothing an agent must read past to find the core behavior.

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 values need no explanation, and annotations cover the safety/idempotency profile. What remains missing — the side effects of disabling Auto Mode and whether credit consumption is immediate — is a modest gap for a destructive mutation.

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%, so the description must carry parameter meaning, and it does: "start or stop" maps to the enabled boolean, "daily attempts" maps to per_day, and "IANA timezone" tells the agent the required string format that the bare string/maxLength 100 schema does not. It omits that per_day is bounded at minimum 1, but that is documented in the schema itself.

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

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

The description names a specific verb pair and resource ("Start or stop Auto Mode") plus the two configurable settings, so an agent knows this writes configuration rather than reads it. It never names get_auto_mode, its obvious read counterpart, so differentiation is only implied by the mutation verbs.

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

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

It says what the tool does but never states when to use it instead of get_auto_mode, nor any prerequisites (e.g. whether a subscription/credits must exist first). The closing note about existing limits is a constraint, not usage routing.

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

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

Annotations already declare that this is a non-read-only, open-world, non-idempotent, non-destructive operation, so the safety profile is covered. The description adds nothing beyond that: it does not say a fresh link is generated per call, that the link is short-lived/session-scoped, or that it points to an externally hosted page the customer uses until expiry.

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

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

A single well-formed sentence, front-loaded with the verb and the outcome. It is efficient, but its brevity is at the edge of under-specification given what is left unsaid.

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 output schema covers the return value and annotations cover safety, so the main remaining obligation was to explain whose billing this touches and any prerequisites. It only hints at 'the customer' without clarifying that it targets the authenticated account, and says nothing about requiring an existing billing relationship.

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, which is the baseline-4 case; there is nothing to document. The description correctly implies no inputs are required.

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 (create) and resource (a billing-management link for the customer), which is enough to distinguish it from create_checkout. It never names the closest sibling, however, so an agent must infer that 'billing portal' is different from 'checkout'.

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

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

No when-to-use, when-not-to-use, or alternative is mentioned. The nearest sibling, create_checkout, is a plausible confusion point and goes unaddressed, and no prerequisites (e.g., an existing customer/subscription) are given.

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

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

Annotations already declare this is a non-readonly, non-idempotent, open-world, non-destructive mutation, so the safety profile is covered. The description adds only that the customer completes checkout, which implies an external handoff (consistent with openWorldHint) but says nothing about side effects like creating subscriptions, expiry of links, or repeat invocations generating duplicate links.

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

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

Two short sentences, with the core action front-loaded and no filler. The second sentence adds a little flow context but is close to redundant given the tool name.

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 (one param) and has an output schema, so return values need not be explained. However, an agent still lacks where valid plan IDs come from, what the returned link's lifecycle is, and how this differs from create_billing_portal — gaps that matter 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?

The single 'plan' parameter has 0% schema description coverage, so the description carries the burden; 'current plan ID' does clarify that the string must be an existing plan identifier, but gives no format, source, or validity rules. That is marginal help over an undocumented string.

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 ('Create a checkout link') and ties it to a plan ID, which is enough to separate it from read-only siblings like get_plans. It stops short of distinguishing it from the closely related create_billing_portal, 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?

'The customer completes checkout' hints at the flow (you hand the link off), but there is no explicit when-to-use guidance, no prerequisites (e.g. obtain the plan ID via get_plans), and no mention of when to prefer create_billing_portal instead. Usage is only implied.

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

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

Annotations already declare the safe read-only, non-destructive, open-world profile. The description usefully adds that no Autojob account/upload is required, the profile is not persisted, and results include match_reasons. It still says nothing about pagination via cursor, result ordering beyond the 'sort' enum, or rate/limits.

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

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

Front-loads the core action and resume-extraction instruction, with the no-login caveat and match_reasons note earning their place. But it spends most of its length on candidate_profile handling while ignoring the majority of the tool's parameters, so the sizing is misaligned with the tool's actual surface.

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 values needn't be explained. Yet for a 10-parameter, nested-object tool with zero schema descriptions, the definition leaves the filtering, sorting, and pagination behavior almost entirely undocumented, which is inadequate to invoke it fully.

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% across 10 parameters, and the description only addresses candidate_profile (with sub-fields employment, skills, preferences). The nine query/filter parameters (q, sort, limit, cursor, remote, salary, company, location, profession) are completely undocumented in both schema and description, so the description fails to compensate for the coverage gap.

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

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

States a specific verb ('Find') and resource ('matching Autojob jobs'), plus a concrete mechanism (extract titles/skills from the attached resume into candidate_profile). It never names the sibling search_jobs, so the agent can't tell how this differs from a plain job search 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 one clear conditional: omit candidate_profile only to use a signed-in account's saved resume, and notes no login/upload is needed. However, there is no guidance on when to prefer this over search_jobs or how the 8 filter parameters (q, sort, remote, salary, etc.) should be used, leaving the primary invocation strategy 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered, but the description adds nothing beyond those hints. It does not explain what 'resume presence' actually means (a boolean? metadata?), nor that openWorldHint=true implies the account/credit data is fetched from an external service.

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

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

A single short sentence with no filler and the key resources front-loaded. The list-style construction is efficient, though 'resume presence' and 'application credits' are compressed enough to be slightly cryptic.

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 values need not be explained, and the tool is parameterless, which keeps the surface small. However, given seven-plus overlapping read siblings, the description should have clarified scope relative to them and what 'presence' and 'credits' mean here.

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

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

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to clarify beyond the schema. No parameter-level gaps 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?

The verb 'Read' plus three resources (account, resume presence, application credits) gives a rough idea, but the phrasing is terse and the three bundled concerns are not distinguished from siblings like get_credits, get_resume_status, and get_profile. An agent cannot confidently predict whether this is a superset call or something narrower.

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 guidance on when to use this bundled read versus the dedicated get_credits, get_resume_status, or get_profile siblings. There is also no stated prerequisite or exclusion, leaving the routing decision entirely 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?

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds that the result includes application events, but does not mention permissions, error behavior, pagination, or other operational 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?

The description is a single front-loaded sentence with no filler. It is appropriately concise, even if other dimensions need more detail.

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

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

The tool is simple, annotations cover its safety profile, and an output schema exists, so return values need not be described. However, usage guidance against siblings and explicit meaning of the id parameter are missing, leaving it only minimally complete.

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

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

Schema description coverage is 0%, and the only parameter is not explained in the description. While 'id' plus the regex pattern imply an application identifier, the description does not confirm that meaning or provide format guidance to compensate for the missing schema descriptions.

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 clear verb and resource: read one application, including its events. The word 'one' helps distinguish it from list_applications, though it does not explicitly name that sibling or other alternatives.

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

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

There is no explicit guidance on when to use this tool versus list_applications, find_matches, or other application-related siblings. The single-application scope is implied, but no alternatives or exclusions are 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 readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context — the MCP transport returns base64 and there is a 5 MB ceiling — but it never says what happens above 5 MB (error, truncation, fallback) or anything about auth/access constraints.

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, both front-loaded with the operation first and the transport caveat second. No filler and nothing repeated from the schema or annotations.

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

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

An output schema exists, so return shape need not be described, and annotations cover the safety profile. However, the undefined parameters and the unresolved boundary behavior at 5 MB leave gaps an agent would hit in practice.

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 says nothing about either parameter. The agent gets no explanation of `id` (a 64-hex identifier — presumably the message or attachment container) or `index` (0–1000, presumably which attachment within that container), which is a real ambiguity for a two-required-param 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 ("Download an attachment") so an agent knows exactly what it retrieves. There is no competing attachment-downloading sibling, so no differentiation is required, but the description stops short of stating scope (e.g., which object the attachment belongs to).

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 explains transport behavior (REST binary vs MCP base64) but gives no guidance on when to call this tool versus siblings like get_message, nor any prerequisite such as needing a valid attachment id from a message. Usage must be inferred entirely.

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 and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds only the scoping detail that 'today's' attempt count is included; it says nothing about freshness, whether the count resets, or any auth context, though an output schema exists to carry return shape.

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

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

A single front-loaded sentence with no filler; the resource comes first and the extra data point second. Nothing is redundant with the title or name.

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 a rich annotation set, zero parameters and an output schema, the definition covers what an agent needs to select and invoke it. The only residual gap is that it does not characterize what the configuration contains (enabled flag, limits) beyond the attempt count.

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

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

The tool takes zero parameters, so the schema baseline of 4 applies and there is nothing further the description could reasonably add.

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

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

The description names a specific verb ('Read') and resource ('Auto Mode configuration'), and adds the secondary payload ('today's attempt count'), which makes it distinct from the sibling configure_auto_mode. It stops short of explicitly naming that setter sibling, but the read/configure split is inferable.

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: 'Read' signals a non-mutating lookup, which points an agent away from configure_auto_mode. There is no explicit statement of when to call this versus the configuration sibling, nor any prerequisite or exclusion.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds only that the values are 'available' credits and 'usage', without noting that results come from a live external source (openWorldHint) or how they are scoped.

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

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

A single short sentence with the verb and resource front-loaded and no wasted wording. Nothing could be removed without losing 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?

With an output schema present, return values need no explanation, and a parameterless read tool has little else to disclose. The only gap is the absence of any note about freshness or scoping of the credit data.

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; the baseline for a parameterless tool is 4. The description correctly implies no input is needed.

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

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

States a specific verb ('Read') and two concrete resources ('available credits and usage'), which is beyond a tautology of the name. It does not differentiate from nearby read tools like get_account or get_plans, 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 gives no indication of when to call this versus get_account or get_plans, nor any prerequisites or exclusions. An agent must infer usage purely from the name and resource wording.

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, and open-world, so the safety profile is covered. The description adds the useful auth fact (no login needed) and that an employer application URL is included, but says nothing about what happens for expired/closed/unknown jobs.

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, front-loaded with the verb and resource, and the access note follows. No 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?

An output schema exists, so return values need no explanation, and annotations cover safety. Missing pieces are the id's meaning/provenance and the behavior for stale or missing jobs, which matter for a lookup tool on an open-world resource.

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 required 'id' parameter; the description never says the id identifies a job, that it is a 32-char hex string, or where to obtain one (e.g., from search_jobs). With zero schema documentation, the description should have compensated and does not.

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 current job') plus what it returns (employer application URL). It is distinguishable from search_jobs by being a single-record read, though it never names the sibling explicitly.

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

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

The 'No login or account required' line communicates access conditions, and use is implied by having a job id. But there is no explicit statement of when to prefer this over search_jobs or get_application, nor what to do if the id is unknown.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds only the data scope ('hidden employers and seniority filters') and no context on where these values originate or whether they affect matching; with annotations this is adequate but thin.

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

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

A single seven-word sentence fragment with no filler, and the resource is front-loaded. It is terse to the point of being a fragment, but nothing in it is wasted.

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

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

With annotations covering safety and an output schema covering return values, the main remaining gap is routing: the description does not say how this differs from get_preferences or that update_job_preferences is the write counterpart. For a zero-parameter read, the definition is usable but leaves that inference to the agent.

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; baseline 4 applies. The schema is closed (additionalProperties: false) and fully self-documenting.

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 the specific resources returned: hidden employers and seniority filters. However, it never distinguishes this from the sibling get_preferences, which an agent could easily confuse with get_job_preferences.

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 guidance on when to use this versus get_preferences or update_job_preferences. An agent must infer that this is the job-search-specific preference subset, and the description offers no alternatives or exclusion 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 declare readOnly, idempotent, non-destructive, open-world access, so the safety profile is covered. The description adds only that attachment *metadata* (not the file) comes back, and says nothing about permission requirements or not-found behavior for an open-world employer-data read.

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

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

A single front-loaded sentence with no waste, but the terseness is under-specification rather than efficiency; nothing about the identifier or the read context is stated.

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 values needn't be explained, but a one-parameter fetch tool with 0% schema coverage still needs the identifier's origin and the relationship to get_attachment/list_messages. Neither is provided.

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

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

Schema coverage is 0% and the sole parameter `id` (a 64-hex-char string) is not explained in the description at all — an agent cannot tell whether it is a message id, an encoded key, or how it relates to the ids returned by list_messages. The description fails to compensate for the coverage gap.

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

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

States a specific verb+resource ("Read an employer message") and adds a scoping detail (attachment metadata included). It is distinguishable from list_messages by the singular 'message' read, but it never names a sibling or states the contrast 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as list_messages for enumeration or get_attachment for downloading the actual file. The agent must infer the retrieval pattern entirely.

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, and openWorld, so the safety profile is fully covered. The description adds the data scope it exposes but says nothing about auth requirements, freshness/caching, or whether the 'available sections' are computed per user.

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

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

A single 11-word sentence with the verb front-loaded and zero filler. It is arguably too terse for a tool whose name alone is uninformative, but nothing in it is wasted.

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

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

An output schema exists and annotations cover behavior, so return values and safety need no description. What is missing is the workflow relationship — that this reads the state which answer_onboarding mutates — leaving the agent to infer sequencing from sibling names.

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, which is the baseline-4 case; there is nothing for the description to disambiguate. It does not incorrectly imply any arguments are needed.

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

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

The description decodes the opaque name 'onboarding' into concrete content: application eligibility answers plus available profile sections. That makes the resource identifiable and implicitly contrasts with the write-side sibling answer_onboarding, though no sibling is named explicitly.

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

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

Usage is only implied — 'Read' signals this is the retrieval counterpart to answer_onboarding, and 'available profile sections' hints it drives onboarding UI. There is no explicit statement of when to call this versus get_application, get_profile, or get_account.

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

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

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuinely new behavioral context by stating no login or account is required, which tells the agent it can call this before authentication – a real operational detail not encoded in 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?

Two short sentences, zero waste, with the core purpose front-loaded and the auth caveat following. 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?

With no parameters, rich annotations, and an output schema that presumably describes the plan fields, the description covers what an agent needs to decide and call correctly. It omits any hint about ordering, pagination, or staleness of 'current' plans, but those are minor given the tool's simplicity.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No misleading parameter language is present.

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: read billing plans and plan IDs. An agent can immediately tell this returns plan catalog data. It does not explicitly distinguish itself from siblings like get_credits or get_account, but the resource is distinct enough that confusion is unlikely.

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 rather than stated – an agent can infer this is the lookup to call before create_checkout or create_billing_portal, but the description never names those alternatives or says when not to use it. Adequate but leaves routing 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 readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered without the description. The description adds only that the values returned are the user's declared preference categories, with no mention of defaults, missing values, or auth requirements.

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

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

A single front-loaded sentence that names the operation first and the returned content second, with no filler or repetition of schema info.

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 annotations covering the safety profile, the description is minimally sufficient for a no-arg read. Its main gap is the missing differentiation from the several sibling preference/profile readers in the same namespace.

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; baseline 4 applies. The sentence simply confirms the operation needs no input.

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 ('preferences') and enumerates the content returned: location, salary and work preferences. This distinguishes it partly from get_job_preferences, though the boundary between the two is never made 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?

There is no guidance on when to call this versus get_job_preferences, get_profile, or get_account, all of which plausibly return overlapping user data. The agent must infer selection from the field list alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds the scoping detail that it reads 'editable' profile fields, but does not add richer behavioral context such as auth requirements or what 'editable' excludes.

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

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

The description is a single front-loaded sentence with no redundant or wasted text. It is appropriately sized for a zero-parameter read 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 no parameters, a rich annotation set, and an output schema, the description is nearly complete for invocation purposes. Its main gap is the lack of explicit differentiation from 'get_preferences', which would help an agent choose between the two.

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 are no parameter semantics to explain and the baseline is 4. The schema being empty and fully described means the description does not need to compensate further.

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

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

The description gives a clear verb ('Read') and resource ('editable profile fields and preferences'), so the basic operation is understandable. However, it does not distinguish this tool from the sibling 'get_preferences', and the overlap in 'preferences' leaves some ambiguity about which tool returns what.

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

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

There is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as 'get_preferences' or 'get_account'. The agent can infer it is for reading profile data, but the description does not route it between sibling tools.

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

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

The description explains the otherwise confusing readOnlyHint=false annotation: a ready resume is 'adopted once into this account', a real state-changing side effect, and 'once' is consistent with idempotentHint=true. It also tells the agent what to do on error. It omits auth requirements and any disclosure of what the adoption means for the source upload.

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

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

Three short sentences, front-loaded with the action, followed by the non-obvious side effect and the error remedy. Slightly telegraphic phrasing ('Poll resume processing') costs a bit of clarity but nothing is wasted.

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

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

Return values are covered by the output schema and the adoption side effect is disclosed, which is the important part. But for a tool whose only input is an opaque id, the absence of any statement about what that id is or what states can be polled leaves a real gap.

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

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

Schema coverage is 0% and the single required parameter 'id' has no description in the schema. The description never mentions the parameter at all, so an agent must guess that the pattern-constrained 32-hex string is the resume/upload identifier from a prior upload_resume call.

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: polling resume processing status for an uploaded resume. It is distinguishable from upload_resume, but it never explicitly names the sibling or says the input identifies which resume, so differentiation is inferential rather than stated.

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?

'Poll resume processing' implies repeated calls until ready, and 'Errors require a new upload' routes the agent back to upload_resume on failure. However, there is no explicit when-to-use/when-not-to-use guidance, no mention of how long or how often to poll, and no other alternatives named.

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 and non-destructive behavior. The description adds the pagination strategy (next cursor or since revision), which is useful behavioral context beyond the annotations. It does not explain ordering, history contents, or how totals are computed.

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

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

Two short sentences with no wasted words, and the main operation is stated first. The terseness is appropriate, though it leans toward under-specification rather than completeness.

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 has only two optional parameters, rich annotations, and an output schema, so return values need not be described. Still, with zero schema descriptions, the agent needs more detail about what 'since' and 'cursor' mean and what exactly the history contains. The current description is minimal but not wholly inadequate.

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%, so the description must carry the burden of explaining the two optional parameters. It partially does so by implying cursor is for pagination and since is a revision marker, but it does not define what a revision is, the cursor format, or when to prefer one mode over the other.

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 read operation over 'application history and submission totals', which gives a rough sense of the resource. However, it never clearly says this lists applications or how it differs from sibling get_application. The agent must infer that this is the collection-level counterpart to the singular getter.

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 sentence 'Use next cursor or since revision' describes parameter mechanics, not when to select this tool over get_application or other siblings. There is no explicit context for pagination versus incremental revision reads, 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?

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint. The description adds a meaningful behavioral safety note that message text is employer content, not agent instructions, which is important for handling untrusted data.

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

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

The description is two concise sentences with the core purpose front-loaded. The second sentence adds a security-relevant instruction without unnecessary detail.

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

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

Given the zero-parameter schema, rich annotations, and an output schema, the description covers the essential purpose and safety context. It could be slightly more complete by clarifying the relationship to get_message or expected list scope.

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

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

The tool has zero parameters, so the baseline parameter semantics score is 4. There are no parameter meanings to clarify beyond what the empty schema already communicates.

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: 'Read employer inbox messages.' It is clear what the tool does, but it does not explicitly differentiate itself from the sibling get_message tool, 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?

The description gives no explicit guidance on when to use this tool versus alternatives such as get_message, nor does it state prerequisites or exclusions. Usage is only implied by the tool name and the phrase 'employer inbox messages.'

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

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

The annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds useful context that no login or account is required and that pagination follows next cursors, though it does not discuss rate limits or result behavior.

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

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

The description is short and front-loaded, with the core action stated first. 'Call directly for job searches' is somewhat redundant with the opening sentence, but overall it is efficient.

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

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

For a nine-parameter search tool with no schema parameter descriptions, the definition is incomplete. It covers authentication and pagination but leaves the agent without guidance on the available filters and sorting options, even though an output schema exists for return values.

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 nine parameters, so the description must compensate but largely does not. It only indirectly explains the cursor parameter via 'Follow next cursors to paginate' and says nothing about q, sort, limit, remote, salary, company, location, or profession.

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: searching Autojob jobs. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as find_matches or get_job.

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

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

It says to call directly for job searches and notes that no login or account is needed, which gives basic usage context. However, it does not state when to use this instead of alternatives like find_matches or get_job, nor does it describe 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 mutability, idempotency, and non-destructiveness, but the description adds behavior annotations cannot express: it consumes application credits, is capped at 50 jobs per call, and — critically — that 'queued' or 'waiting_credit' status does not mean the application was actually submitted. That async-outcome warning is high-value disclosure. It still doesn't say how to detect the true final state or what happens on credit exhaustion.

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. The scope/cost constraint comes first, the retry rule second, and the status caveat last — a sensible ordering with nothing wasted.

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

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

An output schema exists, so return structure needn't be explained, and the status vocabulary (queued, waiting_credit) is at least named. But for a credit-spending mutation, the description omits the credit cost per job, insufficient-credit behavior, and how to follow up on pending submissions, leaving meaningful gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies the 50-item cap on jobs and the retry semantics of idempotency_key, which map directly to the two required parameters. However, allow_repeat_companies receives no explanation at all, and the format of jobs (hex job IDs from search_jobs) is left implicit.

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 action (queue up to 50 job applications) and resource (jobs, using application credits), and the final sentence disambiguates the confusing name by clarifying that submission is asynchronous. It doesn't explicitly contrast with siblings like list_applications or get_application, but the verb+resource pair is specific enough to distinguish 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?

It gives one concrete operational rule — reuse the same idempotency_key on retries — which is genuine usage guidance beyond the schema. However, it never says when to prefer this over alternatives (e.g. use find_matches/search_jobs first to obtain valid job IDs) or what to do when credits run out, so usage is only implied.

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

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

Annotations already declare this as a non-read-only, non-destructive, non-idempotent mutation. The description adds useful semantics — that the effect is to suppress a company and that a 'restore' path exists, implying reversibility — but says nothing about auth requirements, whether hiding affects existing applications, or how the modes interact.

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

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

A single front-loaded sentence enumerating the three capabilities with no filler. It is efficient, though the compressed 'restore a company key' clause reads ambiguously without the surrounding context.

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 values needn't be described, but for a tool with three zero-documented parameters and distinct operation modes, the description omits validation formats, mode exclusivity, and side effects — leaving real gaps an agent must 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?

With 0% schema description coverage the description carries the full burden, and it does loosely map all three parameters to their actions (hide_job → hide company, restore → restore a company key, seniority_levels → set seniority levels). However it never explains the opaque 32-character hex format for hide_job, what a 'company key' actually is, or the max-20 array constraint.

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 three concrete operations on a specific resource: hiding a company for a job, restoring a company key, and setting seniority levels. This is far more informative than the bare tool name and lets an agent tell it apart from the read-only get_job_preferences, though it never states that routing 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?

There is no guidance on when to use this versus update_preferences or get_job_preferences, no mention of prerequisites, and no statement about whether the three operations can be combined in one call or are mutually exclusive modes.

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=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that — no mention that this is a partial update with all fields optional, what the new values affect (match results), or whether omitted fields are preserved.

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

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

One short sentence with no wasted words, but the brevity is under-specification rather than economy. There is no front-loaded scope or constraint to anchor the agent.

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-parameter mutation tool with zero schema descriptions, the description should carry the burden of explaining the fields and the partial-update semantics. An output schema exists, so return values need not be explained, but the input side is entirely undocumented.

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?

All 5 parameters (salary, preferred_city, preferred_state, workplace_types, employment_types) have 0% schema description coverage, and the description says nothing about any of them. It does not even hint that every field is optional or that arrays accept multiple values.

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?

"Update matching preferences" gives a verb and a resource, so the agent knows this mutates stored preferences. But "matching preferences" is vague and does not distinguish this tool from the sibling update_job_preferences, which reads almost identically.

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

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

No when-to-use, when-not-to-use, or alternative is mentioned. With update_job_preferences and get_preferences in the sibling list, the agent has no stated basis for choosing this tool over them.

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

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

The annotations already declare that this is a non-read-only, open-world, non-idempotent, and potentially destructive operation. The description adds useful domain scope by limiting it to contact details, but it does not explain partial-update behavior, what 'destructive' means here, or any permission requirements.

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

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

Two short sentences with no filler. The primary action is front-loaded and the sibling-tool guidance follows immediately.

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 mutation tool with 8 undocumented parameters and a destructive annotation, the description is too sparse. The output schema means return values need not be explained, but the lack of parameter and partial-update semantics leaves significant gaps.

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

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

There are 8 parameters with 0% schema description coverage, so the description must carry the burden of explaining them. It only says 'contact details', which loosely implies fields like name, phone, and location, but does not clarify formats, optionality, or whether omitted fields are preserved.

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

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

The description uses a clear verb, 'Update', and identifies the resource as 'contact details', which an agent can distinguish from application-answer and preference operations. It stops short of explicitly saying it updates the profile record, but the intent is still 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?

It explicitly routes the agent away from this tool for application answers, naming onboarding and preference tools as alternatives. It does not spell out every case for using update_profile, but the domain boundary is clear enough.

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

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

Annotations only say it is a non-idempotent, open-world write with no destruction. The description adds real context beyond that: the 15 MB decoded limit and the asynchronous polling contract with 'ready' defined as adoption into the account. The pre-adoption state and what pending looks like is left slightly implicit, so not 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?

Two tight sentences with zero filler, front-loading the format/size constraint before the async polling instructions.

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, and it covers constraints plus the async lifecycle. A bit more on the filename parameter or the not-ready state would push it to 5, but it's sufficient to call 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 0%, so the description must carry semantics. It explains the format constraint and clarifies the 15 MB limit is on decoded size rather than the base64 string length, which is genuinely useful. However, it never explains the filename parameter's role or the base64 encoding requirement for content_base64.

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 (upload) and resource (resume) plus accepted formats (PDF/DOCX) and size cap. It is clearly distinguishable from read-oriented siblings like get_resume_status, though it doesn't explicitly name the relationship to them.

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

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

It gives the post-call workflow (poll operation_id until ready) but never says when to choose this tool versus get_resume_status or how it fits before find_matches/submit_applications. Usage is implied rather than spelled out.

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