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

Annotations already declare readOnlyHint=true, destructiveHint=false and idempotentHint=true, so safety is covered. The description adds genuinely useful, non-redundant context: it returns no cookies or tokens, and the agent has no capability to log in itself. It omits how the check is performed or whether results are cached, which is why this sits at 4 rather than 5.

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

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

Four short sentences, front-loaded with the read-only constraint, then purpose, then the security boundary, then remediation. Every sentence carries distinct information and none is padded.

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; the description nonetheless clarifies the negative case ('not signed in') and the agent-capability boundary. For a zero-parameter diagnostic tool with annotations covering safety, this is complete.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4; there is nothing for the description to clarify beyond the schema, and it correctly does not invent parameter guidance.

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: checks whether the persistent browser profile is signed in to LinkedIn. No sibling tool addresses authentication state, so it is trivially distinguishable, and the leading '[READ - no LinkedIn state is changed]' frames the operation type immediately.

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

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

Explicitly says when to use it ('diagnose NOT_AUTHENTICATED / LOGIN_REQUIRED errors') and what to do when it reports a negative result ('the USER must run `npm run login`'). The when-to-use condition and the follow-up path are both stated, leaving nothing 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 openWorldHint=false and destructiveHint=false, and the description reinforces this by stressing 'local state only; performs NO external action' twice. It also adds state-machine detail (PENDING/CONFIRMED) that the annotations do not convey. No contradiction, and it contributes beyond the structured fields.

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

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

Front-loads the critical PREPARE/local-only caveat in brackets, then the operation and its usage in two short sentences. Every clause earns its place with no redundancy.

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

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

With an output schema present, return values need no explanation, and the description covers purpose, effect, and usage. It is nearly complete for a one-parameter tool; the only gap is the unexplained actionId semantics.

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

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

There is a single parameter (actionId) with 0% schema description coverage, so the description must compensate and largely does not. It only implies actionId refers to an action via 'PENDING or CONFIRMED action'; it never explains ID format, source, or the 8-64 char 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?

States a specific verb (cancels) and a precisely scoped resource (a PENDING or CONFIRMED action), including the consequence ('can never be executed'). This clearly separates it from siblings like linkedin_get_action and linkedin_list_actions, which read rather than cancel.

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

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

Explicitly gives the triggering context: 'Use when the user changes their mind or the draft is superseded.' That is clear when-to-use guidance, though it names no explicit alternative tool for related operations.

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

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

Annotations only declare generic hints (readOnlyHint=false, destructiveHint=false, openWorldHint=false); the description adds the substantive behavior: changes local state only, nothing is transmitted, and the tool cannot send at all. It also states the 2000-char cap and that the draft must be surfaced to the user. No contradiction with the annotations, since writing a local draft is consistent with readOnlyHint=false.

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 bracketed safety tag, then purpose, then usage rules, then workflow instruction. Every clause earns its place; 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?

With an output schema present, return values need no explanation; the description covers the safety profile, recipient/length constraints, and the user-review workflow an agent needs to invoke this correctly. No material gap remains for a 3-param local-state 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 coverage is 33% (only recipientUrl documented in the schema). The description restates the 2000-char message limit but adds no meaning for recipientName or recipientUrl beyond the schema, so it only partially compensates for the coverage gap. Baseline 3 for a low-coverage 3-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+resource ('Stores a DRAFT LinkedIn message') with an explicit [PREPARE] tag and the crucial scope limit 'performs NO external action; Nothing is sent'. It clearly distinguishes itself from send/action siblings and from the found-recruiter case.

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

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

Gives an explicit when-to-use condition ('only when the user asked for a message to a specific person') and an explicit when-not ('never because a recruiter was merely found'), plus the follow-up workflow ('show the draft so the user can send it manually'). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description still adds value beyond them: it clarifies that only local state is involved and no LinkedIn state is changed, and it names the OUTCOME_UNKNOWN scenario as a reason to call it.

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

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

Three short clauses, zero filler, with the read-only constraint and local-state scope front-loaded before the usage triggers. Every sentence earns its place.

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

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

An output schema exists, so return values need not be described, and the description still usefully frames what comes back (state and exact preview). For a one-parameter read tool with full annotations, this is nearly complete; only the actionId sourcing is left implicit.

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?

Single parameter with 0% schema description coverage, so the description carries the burden. It implies actionId refers to a previously 'prepared action', but never explains the id format, length constraints, or where to obtain it (e.g., from linkedin_list_actions output). Minimal viable semantics rather than compensating for the 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 ('Returns the state and exact preview of a prepared action') and pins the scope as local state only, which separates it from state-changing siblings like linkedin_save_job or linkedin_prepare_save_job. It does not explicitly name the nearby sibling it could be confused with (linkedin_list_actions), so it falls just 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?

Gives two concrete trigger conditions: checking whether a user has confirmed an action, and recovering after an OUTCOME_UNKNOWN error. This is clear when-to-use guidance, but there are no explicit when-not conditions or named 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, non-destructive and closed-world. The description adds real value: it clarifies that only local state is read and LinkedIn is never contacted (a stronger claim than readOnlyHint alone) and describes the shape of the returned state including answer provenance and needsInput flags.

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 [READ] safety marker, then two dense sentences that each carry useful detail with 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?

For a single-parameter read tool with an output schema and full annotation coverage, the description is essentially complete; the only minor gap is any hint about the applicationId format/lookup, which the schema also leaves blank.

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 applicationId parameter, so the schema does not document it. The name is largely self-explanatory and the description says nothing further about it, which is adequate but not compensating 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 (Returns/Get) and resource (local state of an in-progress application), then enumerates the returned content: status, CV, fields, questions with answer/source and needsInput. The phrase 'local state only, never touches LinkedIn' implicitly distinguishes it from siblings like linkedin_preview_application, 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 implied by 'in-progress application', which tells the agent the applicable context, but there is no explicit when-to-use/when-not guidance and no routing to alternatives such as linkedin_preview_application or linkedin_provide_application_answer.

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 '[READ - no LinkedIn state is changed]' prefix largely restates structured data. The one genuinely additive fact is that only the public 'About' section is retrieved, which hints at limited result scope, but nothing about failure modes or rate limits is given.

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

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

One sentence, front-loaded with the read-only guarantee, then the resource and its payload. No filler or redundancy.

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

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

With an output schema present, return-value documentation is not required, and the description still lists the expected fields. For a one-parameter read tool this is essentially complete, with only usage routing left implicit.

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

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

Schema description coverage is 100% and the single url parameter is fully documented in the schema (format, https://www.linkedin.com requirement, example). The description adds no syntax or format detail beyond it, so the baseline 3 applies.

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

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

Specific verb (reads) plus resource (company's public LinkedIn 'About' page) and an explicit enumeration of the returned fields. It is clearly distinguishable from siblings like linkedin_get_profile or linkedin_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?

The description establishes context by labeling the tool READ-only, but it gives no when-to-use condition, no prerequisite, and no distinction from siblings that also fetch LinkedIn entities. Usage is implied rather than stated.

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

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

Annotations already declare readOnly/ idempotent/ non-destructive, so the safety profile is covered. The description adds non-obvious behavior beyond that: a local side effect ('Marks the job as "viewed" locally') and a data-fidelity policy ('Fields LinkedIn does not show are omitted (never guessed)'). Auth requirements and failure modes are not covered, keeping it at 4 rather than 5.

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

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

Four short sentences, front-loaded with the '[READ - no LinkedIn state is changed]' tag so the safety signal lands first. Every sentence adds distinct information (state safety, return content, field policy, local side effect, usage timing) with 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?

For a single-parameter read tool with full annotations and an output schema, the description covers what an agent needs: what it fetches, that remote state is untouched, that a local viewed-flag is set, how missing fields are handled, and when to call it. Return-value detail is rightly left to the output schema.

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

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

There is a single required parameter with 100% schema description coverage, including format and URL constraints, so the schema carries the meaning. The description adds nothing about the url parameter itself, which is the expected baseline-3 outcome when coverage is complete.

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

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

The description uses a specific verb+resource ('Opens one LinkedIn job posting and returns its full description and metadata') and scopes it to a single posting, which cleanly separates it from linkedin_search_jobs and linkedin_get_saved_jobs. What is returned is stated concretely, so an agent can tell what this tool does 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?

It gives a clear condition of use: 'Use it before analysing a job against the user's CV.' That is a real usage cue, but it does not name competing alternatives (e.g. search_jobs vs get_saved_jobs) or state when not to use it, so it falls short of the explicit when/when-not routing a 5 requires.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the '[READ - no LinkedIn state is changed]' line is partly redundant. However, the incompleteSections caveat is genuine added value: it warns the agent that partial results must be treated as unknown rather than empty, which is not derivable from the annotations.

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

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

Two tight sentences with no filler; the safety marker and scope come first, followed by the returned fields and the caveat. Every clause earns its place.

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

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

With an output schema present, the description need not explain return structure, and it correctly avoids that. Scope, safety, and the partial-read caveat cover everything an agent needs to call and interpret this no-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?

The tool takes zero parameters, and the extended schemas correctly apply the baseline of 4 when there is nothing to document. The description's field list describes output rather than input, so it neither helps nor hurts here.

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 (Reads) and a precisely scoped resource (the signed-in user's OWN profile), then enumerates the fields returned (headline, about, experience, education, skills). This clearly separates it from siblings like linkedin_get_company (other entities) and linkedin_prepare_profile_update (writes).

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 OWN-profile scoping and the READ marker give clear context for when this tool applies, and the sibling set makes read-vs-write intent obvious. It stops short of naming an explicit alternative or a when-not condition, so it does not reach a 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?

Beyond the readOnlyHint annotation, the description discloses a non-obvious side effect: every returned saved job is written into local tracking (localStatus becomes 'saved' unless already further along). It also explains the hasMore pagination contract, which is behavioral information the annotations do not cover.

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 a bracketed [READ] marker and a single dense paragraph; every sentence carries information (scope, side effect, pagination). The sentences are long and pack several ideas together, which slightly hurts skimability but there is 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?

Scope, the local-tracking side effect, and the pagination loop are all covered, and the presence of an output schema means return values need no further explanation. An agent has everything required to call this correctly.

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

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

Schema coverage is 100% and the schema already documents maxResults' 1-25 range and default, so the baseline is 3. The description adds relational meaning by tying maxResults to hasMore and the retry pattern, which the schema alone does not convey.

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 ('Reads LinkedIn's own Saved-jobs list') and explicitly scopes it ('jobs actually saved on the real account right now, not just local tracking'), which separates it from the local-tracking siblings. An agent can identify the tool's job without opening the schema.

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

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

It gives clear context for use: read the real saved list, and if hasMore=true call again with a larger maxResults. It implicitly contrasts with local tracking but never names the alternative sibling (e.g. linkedin_list_tracked_jobs) as an explicit routing choice, so it falls short of the 5 bar.

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 and the '[READ - no LinkedIn state is changed]' prefix largely repeats it. The genuinely additive detail is '(local state only)', which tells the agent these are staged local records rather than live LinkedIn data — a meaningful behavioral clarification.

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 the read-only constraint first and the filter optionality last; every clause adds information and 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?

With an output schema present, return values need not be described, and the description covers scope, safety, and filtering adequately. It could note ordering or the default page size implied by 'recent', but nothing critical to correct invocation is missing.

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

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

Schema description coverage is 0% for 2 parameters, and the description only restates the status filter without explaining its enum values or the meaning/default of 'limit' (max 50). Baseline 3 is warranted since the enum carries the filter values but limit stays fully undocumented in prose.

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

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

States a specific verb and resource ('Lists recent prepared actions and their states') and scopes it as local-only, which distinguishes it from the single-record linkedin_get_action. It never names a sibling explicitly, so differentiation still relies on the reader inferring from the plural 'actions'.

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?

'Optionally filtered by status' implies when to narrow results, but there is no explicit when-to-use framing or routing against alternatives such as linkedin_get_action for a single action. Usage must be inferred.

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 readOnly, idempotent, non-destructive, and closed-world hints. The description adds that no LinkedIn state is changed and that it operates on LOCAL tracking only, reinforcing that it doesn't touch the remote platform. It does not mention pagination or ordering, but the output schema likely covers return shape, so the gap is minor.

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

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

Two sentences, front-loaded with the READ qualifier and local-only scope, then the usage guidance. No wasted words; every phrase adds value.

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

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

For a simple list tool with an output schema and annotations covering safety, the description provides enough context: local-only scope, status filtering, and usage intent. It could mention pagination or default behavior for limit, but those are minor given the output schema exists.

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

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

Schema description coverage is 0%, so the schema itself provides no help. The description partially compensates by explaining the 'status' parameter meaning (local status values like discovered, viewed, etc.) and implying 'limit' via 'optionally by local status'. But it doesn't explain 'limit' or clarify that status is a filter. Baseline 3 is appropriate given partial compensation.

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

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

States a specific verb and resource ('Lists jobs from LOCAL tracking'). It clarifies the local-only scope, which distinguishes it from sibling tools like linkedin_search_jobs or linkedin_get_saved_jobs. However, it doesn't explicitly name which sibling to use for LinkedIn-side job retrieval.

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

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

Provides clear context: 'Use it to avoid re-presenting jobs the user already handled.' This gives a concrete when-to-use scenario. But it doesn't contrast with alternatives like linkedin_get_saved_jobs or explain when NOT to use it (e.g., to fetch remote jobs).

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 and destructiveHint=false, but do not explain WHAT is mutated. The description supplies the critical missing context: this is a local-state-only write with no external side effect, plus a durable consequence ('so it is not shown again'). That is meaningful disclosure beyond the annotations, not a restatement.

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 most decision-relevant fact (local only, no external action) in a bracketed prefix, then states the resource and the one risky enum rule. No filler sentences; every clause carries routing or behavioral information.

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

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

Return values need not be explained since an output schema exists, and the local-vs-remote distinction is fully covered. Minor gaps remain: no mention of overwrite/idempotency behavior when re-marking the same job, and no note on what happens to the url parameter's sibling linkage.

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 50% (url documented, status enum undocumented). The description compensates by explaining the enum semantics ('viewed, considering or rejected') and adding a decision rule for the non-obvious value 'rejected', which the schema's bare enum cannot convey.

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

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

States a specific verb and resource ('Sets the LOCAL tracking status of a job') and immediately scopes it as a local-only write that performs NO external action. This differentiates it from the mutating siblings linkedin_save_job and linkedin_unsave_job, which an agent would otherwise confuse it with.

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

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

Gives explicit when-to-use guidance, including a strong conditional rule: use "rejected" only when the USER said they are not interested. It also clarifies the negative scope (does not touch LinkedIn), though it does not name a specific alternative tool to use for external actions.

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 only tell the agent it is a non-destructive mutation; the description adds the crucial facts that it changes local state only, performs no external action, and cannot actually send. That 'no external action' guarantee is a behavioral trait the annotations do not convey and materially affects how the agent should present the result.

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 bracketed tag followed by dense but purposeful sentences; nothing is filler. Slightly heavy punctuation, but appropriately sized for a state-changing preparation step.

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 safety profile is covered by annotations. Combined with the explicit no-send/no-bulk constraints, the description gives the agent everything needed to call and frame this tool 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 low (33%), and the description only restates the note's 300-char limit (already in the schema) and implies a named recipient. It does not explain recipientUrl, its LinkedIn-URL requirement, or how the agent should source those values, leaving the schema to carry most parameter meaning.

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

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

States a specific verb (prepares, not sends) and resource (a LinkedIn connection request with optional note), and immediately distinguishes itself from a send action and from bulk preparation. An agent would not confuse it with any sibling.

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

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

Explicit conditions are given: 'Only for a specific person the user named' and 'Never bulk-prepare,' plus the instruction to show the preview so the user acts manually. It doesn't name a specific sibling alternative, but the constraint set is clear.

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 beyond the annotations that it mutates only local state, performs no external action, reads the current LinkedIn value, and returns a PENDING action rather than applying it. This resolves the tension around readOnlyHint=false (it does create a local pending action) rather than contradicting it.

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

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

Front-loaded bracketed scope marker plus tight sentences, but the no-apply constraint is restated twice ('does NOT apply' and 'cannot apply profile changes'), which is mild redundancy.

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

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

With an output schema present, return-shape detail is unnecessary, yet the description still usefully says it returns current vs proposed as a pending action. For a two-field local-state tool, nothing 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 description must compensate, and it does: it names the two valid fields and gives field-specific limits (220 for headline, 2600 for about) that the schema only captures as a generic maxLength of 2600. It does not elaborate on proposedValue formatting, so it stops short of full compensation.

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 (prepares) and resource (user's own LinkedIn headline or about section), and explicitly demarcates the PREPARE-only scope versus applying. An agent can distinguish it from apply-capable siblings without opening any schema.

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

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

Explicitly states when to use it (to produce a preview) and when it must not be treated as final, routing the user to manual application. It also sets the boundary 'never propose changes the user did not ask for', leaving no inference needed.

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

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

Beyond the annotations, the description discloses the key behavioral distinction: it 'changes local state only; performs NO external action' and returns 'a PENDING action with a preview.' It also explains the confirmation workflow required before execution, which is crucial for a non-idempotent, non-destructive prepare tool.

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

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

The description is front-loaded with a bracketed PREPARE warning, then states purpose, behavior, usage constraint, and execution path. Every sentence adds necessary information; none is redundant.

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 output schema exists, the description needn't explain return values fully, yet it still notes the PENDING action and preview. With annotations and schema present, the description covers the essential local-state-only behavior, confirmation workflow, and sibling execution tools, leaving no critical gaps.

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

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

Schema description coverage is 50%: the url parameter is documented in the schema, but the mode enum lacks a description. The description's wording 'saving or un-saving' loosely maps to the save/unsave modes, but it adds no syntax, default behavior, or constraint details beyond the schema.

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

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

The description states a specific verb and resource: 'Prepares (does NOT perform) saving or un-saving a job on LinkedIn.' It immediately distinguishes itself from the actual execution tools by naming linkedin_save_job and linkedin_unsave_job, so an agent can tell it apart without opening schemas.

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 explicit when-to-use guidance ('only prepare this when the user asked to save it'), a when-not condition ('Recommending a job does not require saving it'), and the exact execution path ('the user confirms in their terminal, then call linkedin_save_job / linkedin_unsave_job'). Alternatives and sequencing are both covered.

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 still adds real behavioral context beyond them: it discloses that only local state is touched, that no LinkedIn state changes, and the readyToSubmit gating semantics. It does not describe output shape, but an output schema exists for that.

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 a bracketed [READ] tag and the core action. There is mild redundancy — '[no LinkedIn state is changed]' and 'never touches LinkedIn' convey the same fact — but nothing is wasted verbatim.

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-value explanation is not required. The description covers purpose, timing, prerequisites, and state guarantees; the only gap is any hint about how to obtain a valid applicationId, which is minor for a low-complexity 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% and the single applicationId parameter has no schema description, so the description must compensate. It only implies the parameter identifies the application to preview; it gives no guidance on the ID's origin, format, or the min/max length constraints. This is the minimum-viable baseline for a one-parameter 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 ('Renders the exact human-readable payload for an application') and enumerates what the preview contains (job, CV, fields, every question and answer). It clearly distinguishes itself from the sibling linkedin_provide_application_answer, which it names directly.

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

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

Explicitly states the moment to use it ('so the user can review it before any confirmation') and routes the agent to the alternative when a prerequisite is unmet ('readyToSubmit is false while any question is unanswered; use linkedin_provide_application_answer for those first'). When/when-not and the alternative are all present.

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 flag readOnlyHint=false and openWorldHint=false; the description confirms and enriches this by declaring the operation is local-state-only and that nothing is sent to LinkedIn, plus it discloses the downstream state machine effect (application becomes READY_TO_SUBMIT once all questions are answered). That is behavioral context beyond what the annotations convey.

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

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

Front-loaded with the scope tag and operation, then constraints, then the state-transition and cross-reference. Every clause carries information; 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?

Output schema exists so return values need no explanation, and the safety/scope profile is fully covered. The only gap is that the agent isn't told how to obtain valid applicationId/answerId values, which is a real if minor omission for a 3-required-param 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 coverage is 0% and no parameter descriptions exist, so the description must compensate; it clarifies the intent of 'answer' (must be a real user-provided answer, not generated) but gives no guidance on where applicationId or answerId come from, nor the 2000/64-char limits. Partial compensation only.

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 action ('records the USER's own answer to one application question') plus a bracketed scope tag [PREPARE - changes local state only; performs NO external action] that separates it from the sibling prepare/save tools. It also names the state transition target (READY_TO_SUBMIT) so the agent knows what this call accomplishes.

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

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

Explicitly scopes when to use it ('one application question that could not be established from their profile/CV/config'), states a hard prohibition ('Never invent the answer yourself: only call this with an answer the user actually gave'), and routes to the verification sibling ('check with linkedin_preview_application').

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 tell the agent this is a non-read-only, non-idempotent, non-destructive write. The description adds the crucial operational context they lack: user confirmation is mandatory, the specific CONFIRMATION_REQUIRED error, and that retrying is harmful because the call is not idempotent. That is genuine value beyond the structured fields.

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

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

Front-loaded with the EXECUTE warning and a dense but single-paragraph body where each clause earns its place (precondition, failure, no-retry, reversal). The closing 'Never save jobs just because they look good' is slightly editorial but still functional guidance.

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 an output schema exists, the description needn't document returns, and it covers everything else an agent needs: prerequisite actionId, required user confirmation, error behavior, and reversibility. No meaningful gap remains for invoking this tool correctly.

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

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

Schema coverage is 100% for the single actionId parameter, and the description largely restates the schema's own wording ('after the user confirmed it'). Baseline 3 applies since the schema already carries the semantics; the description adds only the terminal-confirmation nuance.

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

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

States a specific verb and resource ('Saves a job on LinkedIn') with an execution tag up front. It clearly distinguishes itself from the sibling prepare/unsave tools by naming both, so an agent can route without opening any schema.

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

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

Explicitly states the precondition (an actionId from linkedin_prepare_save_job that the USER confirmed in their own terminal), the failure path (CONFIRMATION_REQUIRED), and the anti-pattern (do not retry in a loop, ask the user). It names the reversal tool linkedin_unsave_job and even gives a policy guardrail against gratuitous saves.

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 safety (readOnlyHint, destructiveHint=false) and openWorld/idempotent traits, but the description adds real value: the 25-result cap, the local tracking side effect, and the isNew/localStatus annotation of results. It does not explain the interaction between idempotentHint and the tracking-based dedupe, which is a minor gap.

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

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

Front-loads the '[READ - no LinkedIn state is changed]' tag, then packs scope, return annotations, the onlyNew switch, ID convention, and the loop warning into three tight sentences with 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?

With an output schema present, return values need not be described, yet the definition still explains the isNew/localStatus annotations the agent will see. For an 8-parameter search tool at 63% schema coverage it is largely complete, with only the unmentioned filter parameters left to the schema.

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

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

Schema coverage is 63%, so the schema documents most parameters already. The description adds meaningful semantics for onlyNew and reinforces the maxResults cap and job-ID convention, but says nothing about location, workType, easyApply, postedWithin, or employmentType beyond what the schema provides.

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

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

States a precise verb+resource ('Searches LinkedIn jobs'), quantifies the scope ('at most 25 results (one page)'), and clarifies the read-only posture. An agent can distinguish it from linkedin_list_tracked_jobs and linkedin_get_job without opening their schemas.

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

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

Gives clear operating guidance: set onlyNew=true for unseen jobs, use the `id` field to refer to jobs, and 'Do not call repeatedly in a loop.' It lacks an explicit named alternative (e.g. list_tracked_jobs for re-checking already-seen jobs), which keeps it short of a 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 readOnlyHint=false, openWorldHint=true, and destructiveHint=false; the description adds the crucial external-side-effect context ('changes LinkedIn state'), the terminal-confirmation requirement, and the execute-stage guard. This goes well beyond what the structured annotations convey.

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

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

Front-loaded with the execute marker and the core action, and stays to two sentences. Slight redundancy between 'REQUIRES the user to have confirmed this exact action' and 'that the USER has confirmed in their own terminal' costs it the top mark.

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 execution tool with an output schema, everything an agent needs is present: the state-changing nature, the confirmation gate, and the source of the required actionId. No return-value explanation is needed since an output schema exists.

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

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

Schema coverage is 100%, so the actionId definition is already documented. The description adds provenance meaning (must come from the matching prepare tool, post-confirmation), which is useful but largely mirrors the schema text.

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

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

States a specific verb and resource: 'Removes a job from the saved list on LinkedIn'. This clearly distinguishes it from linkedin_save_job and linkedin_prepare_save_job, and the '[EXECUTE]' framing signals the execution stage versus the prepare stage.

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

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

Explicitly names the prerequisite chain: the actionId must come from linkedin_prepare_save_job (mode "unsave") and must have been confirmed by the user in their own terminal. An agent knows both which sibling to call first and the gate condition for invoking this one.

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