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

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds that the guidelines are recruiter-search based and section-by-section, but it does not describe response shape, size, or any other behavioral detail beyond 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?

Two short sentences, front-loaded with the core purpose and immediately followed by the key optional-parameter behavior. There is no unnecessary wording.

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 read-only tool with one optional enum parameter and no output schema, the description covers purpose and the main parameter behavior adequately. It could say a bit more about the returned content structure, but nothing essential is missing for correct invocation.

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

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

Schema coverage is 100% and the enum already documents valid section values. The description adds meaningful semantics by explaining that omitting 'section' returns the full guide, which is not evident from the schema alone.

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

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

The description states a specific verb and resource: returning section-by-section LinkedIn profile guidelines, with the recruiter-search basis noted. It is clearly a guidelines-retrieval tool rather than a review or linting tool like its siblings, though it does not explicitly name those siblings.

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 useful usage rule: omit 'section' to get the full guide. It does not explain when to use this tool versus siblings such as review_profile or lint_field, so the agent must infer that this is reference material rather than an evaluation tool.

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?

readOnlyHint=true already tells the agent this is a safe read, and the description correctly matches that by framing it as 'find' and 'report'. It adds the useful detail that the output is a coverage comparison rather than a rewrite, but says nothing about limits (e.g. the 1-10 posting cap or the top bound) or what the report looks like.

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 core operation and no filler. The second sentence drifts slightly into editorial advice rather than tool specification, but it is short enough to earn 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 no output schema, the description carries the burden of explaining returns, and it only says a coverage report is produced without describing its structure or how `top` shapes it. Adequate for a simple read-only analysis tool, but an agent cannot predict the result shape.

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

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

Schema coverage is 67%; profile_text and job_descriptions are documented in the schema, and the description reinforces that the profile text is the comparison baseline. The `top` parameter, which controls how many recurring terms are reported, carries no description in either place, so its meaning must be inferred.

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

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

States a concrete verb+resource: extracts recurring terms from job descriptions and reports which are present in the profile text. That is clearly distinct from the sibling review_* and lint_field tools, though the description never names those siblings to reinforce the distinction.

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 second sentence gives a conditional rule ('only add a missing term if it truly describes the person's work'), which is guidance about acting on results rather than about when to call this tool. There is no explicit when-not case or pointer to review_profile/lint_field as 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?

The readOnlyHint annotation already establishes that this is a safe inspection tool. The description adds useful behavioral detail by naming the lint categories and noting that it shows what is visible before truncation, but it does not describe the result format, severity, or whether it suggests fixes.

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 sentences, front-loads the main action, and every clause contributes specific information about what is checked. There is no repetition or wasted wording.

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 low-complexity, read-only tool with no output schema, the description covers purpose and lint scope adequately. It still leaves gaps around the returned output and sibling differentiation, and it does not compensate for the undocumented field enum.

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%: the text parameter is described, but the field parameter's enum lacks a schema description. The description clarifies that the field is a LinkedIn field and that text is checked against its limit, but it does not explain how the enum values differ or how field choice affects limits and checks.

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

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

The description gives a specific verb ('Check') and resource ('one LinkedIn field'), and it enumerates the checks: character limit, AI-sounding text, list markers, and emoji. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as review_headline or review_experience.

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

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

Usage is implied by the mention of checking a field and showing visible text before truncation, which suggests pre-post or pre-review validation. However, there is no explicit when-to-use guidance or statement about when to choose this over sibling tools like review_profile or keyword_coverage.

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, so the safety profile is covered. The description adds real value by disclosing exactly which checks run, which hints at the shape of the findings. However, it does not say whether findings are scored, pass/fail, or free-text, and gives no indication of how the optional keywords input changes behavior.

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

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

A single front-loaded sentence with a clean colon-delimited checklist; no filler and no redundant restatement of the title. The dense enumeration is efficient, though the list is long enough that a slight structural break (e.g., grouping structural vs. language checks) would aid scanning.

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

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

With no output schema and 0% parameter coverage, the description carries the full burden, and it leaves the return format undefined as well as the semantics of the optional keywords argument. For a review tool whose output an agent must interpret, this is a substantial 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 description coverage is 0% for two parameters, so the description must compensate and largely does not. It mentions 'keywords' only as one of the reviewed dimensions, leaving it ambiguous whether keywords is an input to check against or an output finding, and the required 'description' parameter is never explained (format, length, single vs. multiple entries).

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 ('Check') and a specific resource ('one Experience description'), then enumerates the exact dimensions examined (length, opening line, bullet count, numbers, action verbs, duty phrasing, keywords, AI-sounding text). That enumeration distinguishes it reasonably well from review_headline and review_profile, though it never names those siblings explicitly.

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

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

Usage is only implied: the phrasing 'one Experience description' suggests a single-entry review, but there is no statement of when to call this versus lint_field, review_headline, or keyword_coverage, and no prerequisites (e.g., is a draft required first?). An agent must infer routing from the tool name.

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 readOnlyHint=true annotation already establishes this is a non-mutating evaluation, so the description carries a lighter burden. It usefully discloses the rubric dimensions that will be scored (first-60-character role placement, length, vague labels, segments, 'open to' line, target keywords), which is real behavioral context beyond the annotation. It still omits the scoring scale, whether findings are pass/fail or graded, and any thresholds, so it is useful but not rich.

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 verb and resource, then a compact enumeration of the checked dimensions — no filler or hedging. It is slightly list-heavy and would read better with light grouping, 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?

With three simple parameters and no nested objects, the tool is low complexity, and the enumerated rubric dimensions partly imply what the response contains. But there is no output schema, and the description never states what 'score' returns — numeric values per dimension, prose findings, or a single grade — nor how missing optional parameters like keywords affect the review. That is the outstanding 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 67%: keywords ("Must-have terms from job postings") and target_role ("e.g. 'AI Engineer'") are already documented in the schema, while headline is undocumented. The description adds some meaning by tying the review to 'target keywords' and to whether the role appears in the first 60 characters, which hints at how target_role is consumed. With the schema doing most of the work, this lands at the baseline.

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 pairs a specific verb ("Score") with a specific resource ("a headline") and enumerates the dimensions being evaluated: role in first 60 characters, length, vague labels, segments, 'open to' line, keywords. That is clear and distinguishable from siblings at the object level. It does not, however, name or contrast itself with review_experience, review_profile, or lint_field, so it stops short of the sibling differentiation a 5 requires.

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, when-not-to-use, or alternative routing guidance. The agent must infer from the name that this applies to headlines versus the sibling reviewers for experience sections or full profiles, and nothing tells it whether this should be run before or after keyword_coverage or lint_field. Usage is only implied by the object of the verb.

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, so the safety bar is lower, yet the description still adds meaningful behavior: it never logs in to or scrapes LinkedIn, which tells the agent the tool works only on supplied text and makes no network/account calls. It also discloses the return shape (per-section results and a checklist), which 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?

Two sentences, front-loaded with the core action, then the input example, then the return shape and the LinkedIn disclaimer. No sentence is filler.

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

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

The return value is described (no output schema exists, so this matters), and the no-scraping constraint is covered. But for a nine-parameter tool with zero schema documentation, the description leaves the input contract underspecified, which is the main completeness 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 description coverage is 0% across nine parameters, so the description carries the full burden and largely fails: it explains only that the payload comes from pasted profile text, without clarifying what 'headline', 'target_role', 'featured_count', 'connections', or 'job_descriptions' mean or how they affect the checks. An agent must guess the meaning and expected format of most fields.

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

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

The description gives a specific verb and resource: it runs 'every check' on a 'pasted profile' and returns per-section results plus a checklist. The phrase 'whole profile' implicitly contrasts it with field-level siblings like review_headline and review_experience, but it never names them, so the differentiation is left to inference.

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

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

It clarifies the input form ('the text of LinkedIn's Save to PDF'), which is real usage context, and 'every check' implies whole-profile use versus the single-field sibling tools. However, it never states explicitly when to use this instead of review_headline/review_experience, nor any prerequisites or exclusions.

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