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

No annotations are provided, so the description carries the full burden. It clearly identifies a non-mutating read-style behavior (returning validity), but it does not explicitly state that no side effects occur or whether any authentication context is required to call it. Adequate for a zero-parameter check, 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?

The entire description is one efficient sentence that front-loads the action ('Return') and the object ('persisted LinkedIn session'). Every word 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?

For a zero-parameter validation tool, the description is largely complete: it communicates the core purpose and implies a boolean outcome. The only minor gap is that the return format is not explicitly stated and there is no usage context, but nothing is needed to invoke the 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?

The tool has zero parameters and the schema is empty, so parameter semantics are a non-issue. The baseline of 4 applies because the description need not compensate for any undocumented parameters.

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 ('Return') and resource ('whether the persisted LinkedIn session is still valid'). It is clearly distinguishable from siblings like login, which creates a session, and from content operations like create_post or update_headline.

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 when-to-use guidance, such as 'call before authenticated operations to verify login state' or 'use login if the session is invalid.' The need to check a session is implied by the sibling toolset, but the description itself does not state it.

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?

No annotations are present, so the description carries the full behavioral burden. It clearly indicates a mutation by saying 'Publish', but it does not disclose that the post may become publicly visible, whether the action is irreversible, or any rate limits or failure modes. This is thin for a tool that posts content on the user's behalf.

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 compact and front-loaded: one clear action sentence followed by a one-item Args block. There is no filler, repetition, or extraneous 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 with a single required parameter, and the core action is clear. However, with no output schema and no annotations, the missing auth prerequisite and lack of post-publish behavioral detail leave meaningful gaps for a public-facing write operation.

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

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

Schema description coverage is 0%, and the description must compensate. It adds value by explaining that 'text' is 'the full text of the post to publish,' going beyond the schema's bare 'Text' title. However, it provides no constraints such as maximum length, formatting, or handling of empty strings.

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 opens with a concrete verb, 'Publish', and names the exact target resource: 'a post to the authenticated user's LinkedIn feed.' It is unambiguous and easily distinguished from sibling tools that handle auth, profile edits, job search, and applications.

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 guidance on when to use this tool versus alternatives, and does not mention prerequisites such as having an active authenticated session before posting. The appropriate context is only weakly implied by the phrase 'authenticated user.'

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It clearly explains the safety gates: dry_run must be False to submit, and confirm must be True alongside dry_run=False. It also states that dry_run returns unanswered questions, indicating the tool's output behavior. This goes beyond a simple 'apply' description and provides critical safety and side-effect information. It does not contradict any annotations (none exist).

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 concise, front-loaded with the core purpose, and structured as a list of arguments. Every sentence earns its place, explaining the purpose and the critical parameter interactions. There is no fluff or redundancy, and the most important behavioral constraints (dry_run and confirm) are clearly highlighted.

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 tool with only 3 parameters and no output schema, the description is nearly complete. It explains the two modes, the safety gates, and even hints at the return value (unanswered questions) for dry_run. It does not describe potential failure scenarios (e.g., what happens if the URL isn't an Easy Apply job), but for a simple submission tool, this is acceptable. The description covers all necessary invocation details.

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 input schema has 0% description coverage, so the description must compensate fully. It does: each parameter (url, dry_run, confirm) is explained with its role and the logical constraints between them. The description adds meaning beyond the schema's basic types and defaults, making it clear that dry_run defaults to True (inspection mode) and confirm is a secondary safety gate. This is exactly the kind of semantic enrichment 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 opens with a clear verb+resource: 'Inspect or submit an Easy Apply job application.' It distinguishes between two modes (inspection vs submission) and the resource is specific (Easy Apply job application). This makes it unambiguous what the tool does and clearly separates it from siblings like get_job_details or search_jobs, which focus on viewing or searching rather than applying.

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 explains the two primary usage modes via the dry_run and confirm parameters: dry_run for inspection, and the combination of dry_run=False and confirm=True for submission. This provides clear context on how to use the tool. However, it does not explicitly state when to prefer this tool over alternatives (e.g., 'use get_job_details for viewing job info'), so it lacks exclusions or explicit when-not guidance. Still, the purpose is distinct enough that usage context 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only describes the fetch operation and does not mention authentication requirements, failure modes, rate limits, or what 'full details' includes.

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 no filler. The core action comes first, and the single parameter is explained in one clear line.

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?

This is a simple one-parameter tool and the URL format is fully documented, so it is minimally viable for invocation. However, with no annotations and no output schema, an agent receives no information about required session state or the returned structure, which is a notable 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 schema only labels the parameter as 'Url', so the description fully compensates by defining the expected value as a full LinkedIn job URL and providing a concrete example format.

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 ('Fetch full details') and a precise resource ('specific LinkedIn job listing URL'), clearly distinguishing it from sibling tools like search_jobs or easy_apply. The concrete URL example further anchors what the tool operates on.

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 is given about when to choose this tool over alternatives such as search_jobs. The URL requirement implies a use case, but the description does not state selection criteria, prerequisites, or exclusions.

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

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

With no annotations provided, the description carries the full burden. It states it returns the profile, implying a read operation and an authentication requirement, but does not disclose behavior on unauthenticated requests, potential errors, or data completeness. For a simple read-only tool this is adequate but not exhaustive.

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, information-dense sentence that front-loads the purpose and lists the returned fields. There is no fluff or redundant phrasing, making it optimally concise.

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 tool has no output schema, the description's list of fields provides sufficient information about the return value. It does not mention error conditions or authentication prerequisites, but these are implicitly conveyed by the tool name and description. Overall, it is complete enough for an agent to call it correctly.

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

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

The tool has zero parameters and 100% schema coverage, so there is nothing for the description to add about parameters. Per the rubric, a baseline of 4 is appropriate; the description does not need to explain parameters that do not 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 description uses the specific verb 'Return' with a clear resource ('authenticated user's full profile') and enumerates the fields (name, headline, about, experience, education, skills). This unambiguously distinguishes it from siblings like get_job_details and the update_* tools, leaving no doubt about its function.

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

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

The description implies the tool is for retrieving the current user's profile, which is clear context given the sibling set. It does not explicitly state when not to use it or name alternatives, but since it is the only profile-fetching tool, the usage context is evident and no exclusion is necessary.

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

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

With no annotations, the description carries the behavioral burden. It usefully discloses that the window is 'headed', that sign-in is manual, and that wait_seconds bounds the waiting time. It does not say what happens after sign-in or whether a session is persisted, but the core interactive behavior is transparent.

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 contain the necessary information: the action, the triggering context, the parameter semantics, and the default. The structure is front-loaded with the main purpose followed by an Args section.

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-optional-parameter tool with no output schema, the description is largely complete: it explains the interactive login flow and timeout. It does not describe return values or post-login verification, but the sibling check_session can cover that need.

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 fully compensates by explaining wait_seconds as 'Max seconds to wait for manual sign-in' and stating a default of 600. However, the schema declares default null, creating a slight inconsistency about the actual default behavior.

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 and resource: 'Open a headed LinkedIn sign-in window', and contextualizes it with 'first-time use or re-login'. This clearly communicates the tool's function, though it does not explicitly distinguish itself from siblings like check_session.

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 states when to use the tool ('first-time use or re-login'), giving clear context. It does not name alternative tools or explicitly state when not to use it, so it falls short of full routing guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions 'return structured results' without specifying the response format, pagination, authentication requirements, or any side effects. Since the tool is a read-only search, one might expect no destructive behavior, but that is not stated. The lack of detail on output structure and prerequisite conditions (e.g., login) is a notable 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?

The description is well-structured with a clear 'Args:' list that is front-loaded after the purpose statement. Each parameter gets exactly one line with no unnecessary detail. It is efficient and easy to scan, making it highly usable for an 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?

There is no output schema, so the description should explain what 'structured results' means, but it does not. It also does not mention whether authentication is required (siblings include login and check_session, suggesting a dependency). There is no guidance on pagination, sorting, or how results relate to downstream tools like get_job_details or easy_apply. For a tool that returns a collection, this is insufficient context for correct usage.

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 fully document parameters. It does so effectively: each parameter is listed with an explanation, examples, or allowed values (e.g., date_posted: 'day', 'week', 'month'; job_type: full_time, etc.). It also clarifies the default for limit (10). However, it does not explicitly state that most parameters are optional filters (only keywords is required), though the schema implies this via defaults. This slight omission prevents a 5.

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 clearly states the action ('Search LinkedIn jobs') and the resource ('jobs'), and specifies that it returns 'structured results'. It distinguishes itself from siblings like get_job_details (which fetches a specific job) and easy_apply (which applies to a job). The purpose is unambiguous and specific.

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

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

The description implies this is the entry point for job discovery, but it does not explicitly state when to use it versus alternatives. It does not mention that get_job_details should be used after finding a job, nor does it exclude scenarios like 'use only when logged in'. The usage context is implied but not articulated.

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?

No annotations exist, so the description must carry the behavioral burden. It conveys that the tool is a destructive replacement of the existing About text, but it omits whether authentication is required, whether the change is reversible, or what response is returned.

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 short lines and an Args block, with no filler or repeated boilerplate. The key purpose is front-loaded before parameter details.

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 operation is simple and single-parameter, so a short description can suffice, but the absence of annotations or output schema leaves behavior and usage partially under-specified. It is still minimally complete for invoking the tool with the required 'about' value.

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 descriptions cover 0% of parameters, and the description compensates by defining 'about' as 'The new About text,' clarifying that it is the replacement value. Since there is only one parameter and it is required, this is adequate, though it adds only slightly to the property name and type.

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 opens with a direct verb ('Replace') and names the resource ('profile About / Summary section'), making the operation unambiguous. It differentiates from siblings like update_headline, update_experience, and update_education by targeting a distinct profile field.

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

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

The description implies the tool is for changing the About section but gives no explicit when-to-use guidance or exclusions. Sibling tools exist for other profile fields, so an agent must infer routing from the purpose statement rather than explicit instructions.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description says 'Add a new education entry' but the tool is named 'update_education', creating ambiguity about whether this creates a new entry or modifies an existing one. It also does not disclose whether the operation is additive, whether it replaces existing education data, or what the response 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?

The description is compact and front-loaded with the main purpose, followed by a clean parameter list. Every parameter earns its place. The only structural issue is the name/description mismatch ('update' vs 'add') and the lack of any usage context, but the text itself 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 mutation tool with no annotations and no output schema, the description is incomplete. It does not explain whether this appends a new education entry or replaces the existing one, what the response contains, or whether there are prerequisites like being logged in. The sibling list includes login and check_session, suggesting auth context matters, but the description does not mention it.

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

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

Schema description coverage is 0%, so the description must compensate. It does list all six parameters with brief human-readable explanations, which adds meaning beyond the bare schema titles. However, it does not clarify formats for start/end dates, whether degree or field_of_study are required in practice, or how description is used. The parameter list is helpful but shallow.

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: 'Add a new education entry to the profile.' This distinguishes it from siblings like update_experience and update_headline, which target different profile sections. However, the tool name says 'update' while the description says 'add', which is a slight inconsistency that could confuse an agent.

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 provides no guidance on when to use this tool versus alternatives. It does not mention that this tool is for adding a new education entry rather than editing an existing one, nor does it contrast with update_experience or other profile-update tools. The context is implied by the resource name but not explicitly 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?

With no annotations, the description carries the full burden. It states the mutation action ('Add') but provides no details on idempotency, permission requirements, or side effects. The 'leave blank for present role' hint touches on behavior but is more parameter-specific than a broader behavioral disclosure.

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 compact docstring with the action statement followed by a clear parameter list. It is efficient, with no extraneous information, and the core purpose is front-loaded. Minor redundancy exists but overall structure is good.

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 description covers all parameters but omits essential context: it does not specify which profile is affected, whether this is for the current user, what the response looks like, or any prerequisites like authentication. The mismatch between 'Add' and the tool name 'update' is also unaddressed, leaving critical gaps 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 0%, but the description compensates thoroughly by explaining every parameter: title, company, start (with format examples), end, description, employment_type (listing allowed values), and location. This is far more than the schema provides and fully clarifies each argument's 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?

The description clearly states 'Add a new experience entry to the profile', giving a specific verb and resource. It distinguishes from sibling update_education by focusing on 'experience' vs 'education'. However, it doesn't explicitly contrast with the tool name 'update_experience', which implies modification rather than creation, introducing potential ambiguity.

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 is provided on when to use this tool versus alternatives like update_education or update_headline. There are no exclusions or prerequisites mentioned, leaving the agent to infer usage context from the name 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Replace') but doesn't disclose whether the operation is reversible, whether it requires authentication, what happens to the previous headline, or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant 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?

The description is very short and front-loaded with the action. The Args section is redundant with the schema but not harmful. Every sentence earns its place, though the Args block could be considered unnecessary repetition of the schema.

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

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

For a single-parameter mutation tool with no annotations and no output schema, the description is too thin. It doesn't mention authentication requirements, success/failure indicators, or any side effects. An agent would need to infer too much about the expected behavior and response format.

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 does explain that 'headline' is 'The new headline string to set', which adds meaning beyond the schema's bare type/title. However, it doesn't provide constraints like max length, formatting requirements, or whether empty strings are allowed. The description adds some value but not enough to fully 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?

The description states a specific verb ('Replace') and resource ('profile headline'), which clearly distinguishes it from siblings like update_about, update_experience, and update_education. It is concise and unambiguous, though it doesn't explicitly name sibling tools for differentiation.

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like being logged in, nor does it explain when updating the headline is appropriate compared to other profile update tools. The context is implied by the tool name and description but not explicitly stated.

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