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

With no annotations provided, the description carries the full burden. It discloses the scope (locked to authenticated account) and that this is a write operation. But it does not state whether the credential appends to existing education entries, replaces anything, or what happens if the session is invalid. The description provides minimal behavioral context but leaves several questions unanswered.

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 efficiently structured: a one-line purpose, a one-line security notice, and a terse bulleted argument list. Every sentence adds information, and the format makes the parameter semantics easy to scan.

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 10-parameter mutation tool with no annotations and an output schema available, the description covers the purpose, scope, and all parameters sufficiently. It could still mention whether the education entry is appended vs. replaced and what validation is applied to month/year values, but the core invocation information is present.

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 fully does: every parameter is given a clear plain-language meaning and an example, and optionality is explicitly marked for grade, activities, and description. This is high-value documentation beyond the raw 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 opens with a specific verb and resource: 'Add an education credential to your own LinkedIn profile.' This clearly differentiates the tool from siblings like add_experience and add_skill, and the security notice further defines the scope as the authenticated account.

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 clearly implies when to use it—when adding an education credential to the user's own profile. However, it does not explicitly mention when not to use it or name alternative tools for different profile sections, so it lacks the explicit exclusions needed for 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?

With no annotations, the description carries the behavioral burden. It states that this is an 'Add' mutation and adds a valuable security scope ('Strictly locked to your authenticated account (/in/me)'). However, it does not disclose side effects such as public visibility, duplicate handling, validation failures, or any irreversible consequences, so behavioral detail remains only adequate.

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 purpose and security context, then presents a clean Args list. Each line earns its place and none of the prose is redundant or 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 an 11-parameter tool with no annotations, the description covers all parameters, the target profile, and the authentication boundary. An output schema is present, so not describing return values is acceptable, and nothing needed to invoke the tool correctly appears to be 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%, but the description compensates fully: every parameter is explained with examples or allowed values. It even adds conditional semantics (end_month/end_year only if not current), a default for is_current, and enumerated choices for employment_type and location_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 specific verb and object ('Add a work position or experience') and clearly scopes it to the user's own LinkedIn profile. This differentiates it from sibling tools like add_education, add_skill, and add_project without requiring an agent to inspect 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 establishes the correct context: adding a work-position entry to the authenticated user's own profile, and the security notice reinforces that it cannot act on anyone else's profile. It does not explicitly name alternative tools or say when not to use this one, so it falls just 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 burden. It discloses a key behavioral trait: strict locking to the authenticated account (/in/me). It also details the parameters with optionality and examples. However, it does not mention side effects (e.g., whether it overwrites existing projects), error handling, or rate limits. Given the output schema exists and the security notice is prominent, the description adds meaningful transparency beyond the basic action.

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 and front-loaded: purpose first, then security notice, then parameter breakdown. Every sentence adds value—no fluff. The parameter list is organized clearly with defaults and optionality, making it easy for an agent to parse.

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 7 parameters, only 1 required, and an existing output schema, the description covers everything needed to call the tool correctly: it specifies the resource type, the scope (own profile), all parameter meanings and optionality, and the security constraint. The output schema handles return values, so no further description is necessary. The tool is actionable without ambiguities.

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 schema has 0% description coverage, so the description fully compensates by explaining every parameter: title, description, url, start_month, start_year, end_month, end_year. It provides examples (e.g., 'Argus Agent', 'January') and marks optionality. This gives an agent all the semantic meaning needed to populate arguments correctly.

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: 'Add a project to your own LinkedIn profile under Projects.' This specifies the verb (Add), resource (project), and precise location (own LinkedIn profile under Projects). It distinguishes this from sibling tools like add_education or add_experience by explicitly targeting the Projects section.

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 clear context: the tool is locked to the authenticated user's own profile, implying it is for adding projects to one's own profile rather than others. While it doesn't explicitly say when not to use it or name alternative tools, the 'Security Notice' and the phrase 'your own LinkedIn profile' give sufficient guidance for an agent to select it appropriately among similar add_* tools.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It adds a valuable security/scope constraint that goes beyond the schema, but does not mention duplicate handling, whether it overwrites existing skills, or what happens if the user is not authenticated.

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 extremely compact: one sentence for the operation, one security notice, and one parameter definition. Every part earns its place and is front-loaded appropriately.

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 one-parameter mutation tool with an output schema present, the description provides enough to invoke it correctly: what it does, the security scope, and the parameter format. Slightly more detail about duplicate/error behavior would be nice, but the low complexity keeps the gap minor.

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 fully compensates by naming the single parameter, explaining it as 'The name of the skill', and giving concrete examples like 'Model Context Protocol (MCP)', 'Python', and 'FastAPI'. It adds meaningful guidance beyond the raw schema's title.

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 the specific action (add), resource (skill), and target (your own LinkedIn profile). The resource clearly distinguishes it from sibling tools like add_education, add_experience, and add_project.

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 clear context that this tool operates only on the authenticated user's own profile via the explicit 'Strictly locked to your authenticated account (/in/me)' notice. It does not explicitly name alternative tools or conditions, but the scope is clear enough to avoid misuse.

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 conveys an audit/advice behavior and is non-mutating in tone, but it does not explicitly state that it only reads data, whether it uses cached or live profile data, or whether it modifies anything. Given the simple analysis nature, this is a moderate 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?

A single, front-loaded sentence that directly states what the tool does and the value it produces. No filler or repeated schema information.

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

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

For a parameterless tool with an output schema, the description is largely adequate: it identifies the subject ('your profile'), the action, and the output (recommendations). It would be slightly stronger with an explicit 'does not modify your profile' or a note about when to use it, but nothing required for 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?

The schema has zero parameters, and the input schema already carries complete coverage (100%). The description adds no parameter detail, but none is needed; baseline 4 applies for a parameterless 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 action ('Audit') on a clear resource ('your profile') and specifies the deliverable ('actionable recommendations'). It is readily distinguishable from sibling tools like get_my_profile or update_* because it focuses on analysis and optimization advice rather than retrieval or mutation.

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

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

No guidance is given on when to prefer this tool over related profile tools such as get_my_profile or update_my_headline. The description implies it is for profile optimization, but it never states when to use it versus alternatives or any prerequisites.

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 burden of behavioral disclosure. The verbs 'check' and 'inspect' imply a read-only operation with no side effects, which is useful, but the description does not mention what happens for an expired/invalid session or what identity fields are included. It is adequate but minimally detailed.

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

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

The description is a single, front-loaded sentence with no wasted words. It directly states the primary purpose and the additional identity inspection capability without 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?

For a zero-parameter, read-only status-checking tool with an output schema available, the description covers the essential behavior. It could be slightly more complete by explicitly noting that this is the tool to use for verifying the current session before performing authenticated actions, but the low complexity means nothing critical 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?

The tool has zero parameters, and the schema coverage is 100% trivially. The description adds no parameter details because none are needed, and the baseline for a zero-parameter tool is appropriate.

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 tool checks LinkedIn authentication status and inspects the active user's identity details. It is specific about the action and resource, though it does not explicitly differentiate itself from the sibling get_my_profile, which could also involve retrieving user identity information.

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 like start_login, logout, refresh_session, or get_my_profile. The intended context of 'call this to verify an authenticated session' is only implied by the tool name, not stated in the description.

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 must carry behavioral context. It does disclose that the action is performed as the authenticated account and that the comment text is 'to publish,' which signals an outward, identity-bound action. However, it does not mention side effects, public visibility, rate limits, or failure modes.

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 action, followed by a short Args section. Every stated sentence earns its place; there is no filler or repetition of the input schema beyond the intentionally included param descriptions.

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 two-string-parameter tool with an output schema, the description provides a sufficient call contract: what it does, who it acts as, and what each parameter means. The main gap is that the login requirement is implied rather than explicitly stated, so it stops just short of a 5.

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 per-parameter lines add necessary meaning: post_url is a URL and comment_text is the published text. This is minimal but adequate for two simple string parameters. No format, length, or URL validation details are given.

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 specific verb and resource: 'Leave a comment on a LinkedIn post.' It also states the acting identity clearly. This distinguishes it from siblings like create_post and send_message without requiring the agent to infer intent.

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 phrase 'as your authenticated account' implies a login prerequisite, but the description does not explicitly tell the agent to verify login or route to start_login/check_login_status if needed. It also gives no when-not-to-use guidance, though the comment intent is reasonably 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 does mention parameter constraints (character limits, option counts, duration values) and the default duration, which is helpful. However, it does not disclose side effects such as whether the poll is immediately visible, whether it requires authentication, or whether it is irreversible. For a mutation tool, this 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 concise and well-structured: a single purpose sentence followed by a clear 'Args' section with per-parameter details. Every sentence earns its place, and the core purpose is front-loaded. There is no redundancy or fluff.

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's complexity (3 params, 2 required, one with default) and the presence of an output schema, the description covers the essential inputs and constraints. It lacks explicit mention of authentication requirements or error handling, but these are likely implied by sibling tools like check_login_status and are not critical for an agent to invoke the tool correctly. Overall, it is sufficient for a straightforward poll-creation action.

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 provides no descriptions (0% coverage), so the description fully compensates by detailing each parameter: question (up to 140 chars), options (list with min/max and per-option length), and duration (enumerated values and default). This adds meaning far beyond the raw schema types and defaults.

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 tool's action ('Create and publish') and its resource ('an interactive poll') with a specific destination ('to your LinkedIn feed'). It is distinct from sibling tools like create_post (which would handle regular posts) and get_feed (which reads), so an agent can easily tell them apart without inspecting 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?

The description implies usage by specifying 'interactive poll', which naturally distinguishes it from create_post, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or preconditions (e.g., being logged in). Guidance is left to inference rather than being directly 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It does reveal the main side effect (publishing to the feed) and the author restriction, which is useful. But it does not mention authentication requirements, visibility, rate limits, or reversibility, leaving some important behavior unstated.

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

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

The description is compact and front-loaded with the core purpose, followed by a tight Args block. Every sentence adds useful information, and there is no filler or repetition of the input 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 simple two-parameter tool with an output schema present, the description covers the essential operation, the required text, and the optional media path and allowed types. It could add an explicit login prerequisite, but the sibling set already includes auth tools and the operation itself is straightforward.

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 schema has 0% description coverage, so the description must define the parameters, and it does so clearly. text is described as the post content, and media_path is optional with explicit allowed file types (.png, .jpg, .pdf). This adds real meaning beyond the bare schema.

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

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

The description states a specific verb ('Publish'), a resource ('post to your LinkedIn feed'), and a key constraint ('authored exclusively by your profile'). This makes it easy to distinguish from sibling tools like create_poll and comment_on_post without needing 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?

The intended context is clearly implied: this tool creates a feed post with optional media. However, it never explicitly names alternatives or exclusions, such as using create_poll for polls or comment_on_post for comments. An agent must infer when this tool is the right choice relative to siblings.

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 clearly labels the operation as 'Read', implying a non-mutating call, and it discloses the limit behavior. However, it creates a mild ambiguity by claiming 'full message history' while the limit parameter caps retrieval to recent messages, and it omits ordering, matching semantics, or error behavior.

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

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

The description is compact and front-loaded: one clear purpose sentence followed by a minimal, well-structured args list. Every sentence adds value, and there is no redundant restating of schema fields.

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 low parameter count and the existence of an output schema, the description covers the essential invocation details: purpose, key parameter semantics, and limits. It is slightly incomplete in resolving the 'full history' vs 'recent messages' tension and does not mention pagination, but overall an agent has enough to call 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?

Schema description coverage is 0%, so the description must and does compensate. It explains recipient_name as 'Name or keyword matching the conversation partner', adding meaningful semantics beyond the schema title, and gives limit an explicit maximum (30) not present in the schema, plus its default.

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 ('Read') and names a precise resource ('full message history and replies for a specific conversation in your inbox'), making the tool's function immediately clear. It is naturally distinguishable from siblings like list_conversations or send_message without needing to open 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?

The phrase 'for a specific conversation' and 'in your inbox' gives clear context for when the tool applies, and the sibling list confirms it is the message-retrieval counterpart to list_conversations. However, it does not explicitly name alternatives or state when not to use this tool, so it falls 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?

No annotations are provided, so the description must disclose behavioral traits. It only mentions the limit parameter and its default/max. It does not state that the operation is read-only, safe, or free of side effects. It also omits any auth requirements, rate limits, or error behaviors. The absence of such disclosures, combined with no annotations, leaves the agent with limited insight into the tool's behavior.

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

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

The description is concise and front-loaded with the primary purpose. The argument explanation is minimal and to the point, with no filler or redundant content. Every sentence serves a purpose, making it easy for an agent to parse quickly.

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 a single parameter and an output schema, the description is adequate but not exhaustive. It does not mention authentication prerequisites, which are implied by the presence of login-related sibling tools, nor does it describe potential errors. However, given the simplicity of the operation and the availability of an output schema, the description covers the essential aspects, though it could note read-only behavior or provide usage context.

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 only defines limit with a default, lacking a description. The description adds the max value (15) and clarifies the meaning as 'Number of posts to read'. This compensates for the schema's zero description coverage, providing critical context for the parameter's usage and constraints.

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: 'Read recent posts from your personal LinkedIn home feed.' It identifies the resource (personal home feed) and the operation (read), making it distinct from sibling tools like create_post or search_people. The verb 'read' is specific, and the resource is well-defined.

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 usage (reading the home feed) but provides no explicit guidance on when to choose this over alternatives. It doesn't mention when not to use it or name any sibling tools for comparison. For a simple read operation, the purpose itself offers some implicit guidance, but it lacks explicit differentiation from related tools like get_network_briefing or get_profile_views.

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 bears full responsibility. It explicitly discloses the read-only, self-scoped nature ('can only read your own profile information') and mentions the authenticated requirement. This is valuable but does not go into other traits like rate limits or response size; however, the output schema covers return values.

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 main action, followed by a security notice. No filler words; every sentence 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?

Given the tool's trivial parameter surface (0), the existence of an output schema covering return value structure, and annotations absent, the description covers what the tool is for and its key constraint. 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?

The tool has zero parameters, so there is nothing for the description to add; schema coverage is 100% by an empty schema. Baseline 4 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?

The description uses a specific verb ('retrieve'), a precise resource ('full profile details'), and a clear scope ('your own authenticated LinkedIn profile'). This distinguishes it from siblings like view_profile, which would presumably target other profiles, and from profile-mutation tools like update_my_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?

It clearly states the tool is for your own authenticated profile, which implies when to use it (self-profile reads) and implicitly not for others. However, it does not explicitly list alternative tools or exclusion criteria, so it is clear context without explicit 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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states what the tool does but does not mention side effects (though likely read-only), authentication requirements, rate limits, or what happens when data is missing. The only extra detail is the default limit value. This is a significant gap for an aggregation tool that could potentially pull a lot of data.

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

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

The description is extremely efficient: a one-sentence purpose followed by the parameter explanation. It is front-loaded with the core action and content list, and every sentence adds value. There is no wasted text.

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

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

The tool has an output schema, so return format is covered elsewhere. The description explains the purpose and the parameter, but it lacks usage guidance and behavioral transparency. For a composite tool that aggregates multiple data sources, it would be helpful to explicitly state that it is a one-stop briefing and to note any implications (e.g., latency, data volume). These gaps make it only moderately 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 schema provides zero description for the 'limit' parameter (coverage 0%), but the tool description explicitly explains its meaning: 'Number of feed items and recent posts to include in the briefing (default: 5).' This fully compensates for the schema gap, giving the agent clear semantics for the only parameter.

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 ('Synthesize a complete daily intelligence briefing') and lists the included content (unread messages, pending invitations, post analytics, top feed trends). This clearly conveys the tool's purpose and distinguishes it from the individual sibling tools like get_feed, get_post_analytics, and get_pending_invitations. However, it does not explicitly name or contrast those alternatives, so it stops short of a 5.

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

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

There is no guidance on when to use this tool versus calling the individual endpoints it aggregates. The description does not mention that this is a convenient alternative or that it should be used when a quick overview is needed. With many sibling tools, this absence makes it hard for an agent to decide between this and the more granular options.

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 burden of conveying behavior. It indicates a read-only listing action and scopes it to the caller's account, but it does not mention whether authentication is required or whether any read-side effects such as marking items as seen could occur. These are unlikely for a list tool, so the lack is not severe.

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, compact sentence with no filler. The key scope ('pending incoming', 'received by your account') is front-loaded and every word adds meaning.

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

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

For a zero-parameter read-only listing tool, the description fully explains what the tool does and what it does not cover. An output schema is present, so the return shape does not need to be spelled out in the description. No critical calling context 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?

The input schema has zero parameters, so there is nothing for the description to explain. The only relevant scoping information, 'your account', is provided in the description itself, satisfying the baseline for a parameterless 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?

The description uses a specific verb ('List') and a specific resource ('pending incoming connection invitations received by your account'). The 'incoming' and 'received by your account' wording clearly distinguishes it from sending requests or managing existing invitations.

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 phrase 'pending incoming' implies the tool is for viewing unanswered invitations addressed to the caller, which gives some context. However, it does not explicitly name alternatives such as manage_invitation or send_connection_request, nor does it state when not to use this 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?

No annotations are provided, so the description carries the full burden. It implies a read-only operation ('Retrieve') but does not explicitly state that it has no side effects, nor does it mention authentication requirements or potential limitations (like 'recent' definition). It adds some context by listing metrics and the parameter, but it's not fully transparent for a tool with no annotation support.

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 highly concise—two sentences. The first states the main purpose, and the second details the only parameter. There is no redundant information, and it's front-loaded with the core functionality.

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 tool with one parameter and an output schema, the description covers the essentials: what it does, scope, and parameter details. It could be more explicit about what 'recent' means or any auth prerequisites, but given the simplicity and the availability of an output schema, it's largely complete. A minor gap in defining 'recent' prevents a 5.

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

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

Schema coverage is 0%, so the description must fully explain the parameter. It does so clearly: 'limit: Maximum number of recent posts to analyze (default: 5, max: 15).' This adds meaning beyond the schema by specifying the purpose, default, and maximum value, which is exactly what the agent needs.

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 verb 'Retrieve' and the resource 'engagement metrics (impressions, reactions, comments, reposts) for recent posts authored by your account.' It specifies what metrics are included and the scope (own account, recent posts), making it distinct from sibling tools like get_feed or get_profile_views.

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 clear context about when to use the tool (when you need engagement metrics for your recent posts). It doesn't explicitly contrast with alternatives or mention situations to avoid, but given the narrow scope, it's reasonably clear. It lacks explicit exclusionary guidance, hence a 4 rather than 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?

With no annotations, the description carries the full burden of behavioral disclosure. It clearly signals a read-only retrieval of private, account-scoped data, which covers the key safety and scope traits. It does not detail edge behavior such as empty analytics or authentication requirements, but for a simple no-argument getter this is sufficient.

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

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

A single front-loaded sentence that names the action, the resource, and the scope with no filler. Every word contributes to understanding the tool.

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

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

Given zero parameters, an output schema that can define return values, and no annotations, the description provides the missing scope and privacy context. What remains is either captured by structured fields or not needed for correct invocation.

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

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

The tool has zero parameters, so the schema already documents everything an agent could pass. The description adds no parameter details but reinforces account scoping, which is appropriate when there is nothing to document.

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: retrieving analytics and viewer demographics for private profile views. 'Private' and 'for your account' clearly differentiate it from viewing others' profiles or retrieving one's own profile data.

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 usage via 'private profile view analytics for your account,' suggesting it is for own-account insights. However, it does not explicitly say when to choose this over siblings like get_post_analytics or get_network_briefing, nor does it name 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It conveys that the operation is read-only ('List') and authentication-dependent ('authenticated inbox'), and hints at recency. Still, it does not specify ordering, whether results are paginated, or what happens when the user is not authenticated.

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

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

The description is two concise sentences with the core action front-loaded and the parameter explanation kept in a clear 'Args:' block. There is no redundant or filler content.

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 tool with only one optional parameter and an output schema available, the description is largely complete. It could be improved by noting ordering/pagination or pointing to get_conversation_messages for reading a specific conversation's messages, but these are minor gaps for this use case.

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%, but the description fully compensates for the sole parameter 'limit' by defining it as 'Maximum conversations to retrieve' and stating the default and max values. This adds meaningful usage semantics beyond the bare schema definition.

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: 'List recent direct message conversations from your authenticated inbox.' This clearly identifies what the tool does and differentiates it from sibling tools like get_conversation_messages, which handles individual messages rather than conversation listings.

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 phrase 'from your authenticated inbox' implies the tool is for retrieving the user's own recent DMs, giving some usage context. However, it does not explicitly state when to use this tool versus alternatives such as get_conversation_messages or get_feed, nor does it mention any exclusions.

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

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

With no annotations, the description carries the full behavioral burdenheb and does well by clearly disclosing that it removes all stored session credentials, cookies, and local profile caches. It accurately conveys the destructive, session-ending nature of the operation without relying on the schema or 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?

The description is a single, efficiently written sentence that front-loads the action and lists the affected resources without any filler or redundancy. Every word contributes to the agent's understanding of the tool's behavior.

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

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

For a zero-parameter tool with an output schema, the description fully covers what the tool does and what it affects. No additional behavioral context is needed for an agent to decide whether to invoke it, and the output schema handles return-value 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?

The tool has zero parametersplay. The empty schema is fully self-explanatory, and the description adds no parameter information because none is needed. The baseline of 4 for zero-parameter tools 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?

The description uses a specific verb ('Clear') and identifies the exact resources affected: stored LinkedIn session credentials, cookies, and local profile caches. This makes the tool's purpose unmistakable and distinguishes it from session-management siblings like check_login_status, start_login, and refresh_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 does not explicitly state when to use this tool versus alternatives, nor does it mention any preconditions or side effects beyond clearing credentials. The use case is inferable from the name and wording, but the tool provides no direct guidance about session lifecycle or when logout is appropriate.

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 disclosure burden. It explains the core actions and the default behavior, but it omits whether the action is reversible, what side effects occur after accepting or ignoring, and whether authentication or specific permissions are required.

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, stating the action first and then the necessary parameters. Every sentence adds value with no filler or redundant 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?

The description is mostly sufficient for a simple two-parameter tool with an output schema, but it omits usage context and side-effect details. Given the absence of annotations, an agent would benefit from explicit notes on when to invoke this vs. related connection tools.

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 clarify sender_name as the person whose invitation is managed and explicitly constrains action to 'accept' or 'ignore' with a default, adding meaning absent from the bare schema.

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

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

The description clearly states the tool accepts or ignores a pending incoming connection invitation. This specific verb-resource combination distinguishes it from sibling tools like send_connection_request and get_pending_invitations.

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 explicit guidance is given about when to use this tool versus alternatives. The description does not mention that it should be used after viewing pending invitations, nor does it note that it is not for sending or managing outgoing requests.

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 burden of behavioral disclosure. It does convey that the tool performs a keep-alive and extends session validity, but it does not mention side effects, failure behavior, authentication requirements, or rate-limit implications. This adds some behavioral context but not rich detail.

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 sentence and front-loads the main action. The phrase 'sliding window keep-alive telemetry' is somewhat vague and could be trimmed, but overall the description is appropriately 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?

For a no-parameter tool with an output schema, the description is mostly sufficient to understand what the tool does. However, it lacks guidance on when to use it relative to session-related siblings and does not clarify the meaning or implications of 'sliding window keep-alive telemetry.'

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

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

The tool has zero parameters, so the schema already fully covers the parameter surface. The description has no need to explain parameter semantics, and the empty schema makes this a non-issue.

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

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

The description names a specific verb ('Test and extend') and resource ('active LinkedIn session validity'), which clearly distinguishes it from siblings like check_login_status, start_login, and logout. The phrase 'sliding window keep-alive telemetry' is somewhat jargon-heavy but does not obscure the core purpose.

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

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

There is no explicit guidance on when to call this tool versus alternatives such as check_login_status or start_login. The description implies it is used to maintain session validity, but it does not state prerequisites, exclusions, or a preferred call order.

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?

There are no annotations, so the description carries the behavioral disclosure burden. It adds useful context like 'through your authenticated account' and the maximum result limit, but it does not explicitly state read-only behavior, rate limits, error conditions, or session prerequisites beyond the auth implication.

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 operation, followed by a tight parameter list. Every line is informative and nothing is redundant with 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?

An output schema is present, so return-value details are already covered. The description addresses all four parameters, marks optionality, gives the result cap, and mentions authentication. It does not explain how filters combine (e.g., AND vs OR), but that is a minor gap for a search 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 schema only provides property titles with 0% description coverage, so the description's Args block is essential and fully compensates. Each parameter gets a clear semantic meaning with examples for keywords and location, plus the default and max for limit.

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 ('Search') and resource ('professionals on LinkedIn'), and adds that this happens through the authenticated account. Siblings like view_profile, get_feed, and get_network_briefing are clearly different, so an agent can confidently select this as the people-search tool.

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 use case is implied by 'Search for professionals' and there is no other search tool among the siblings, so the intended context is understandable. However, the description gives no explicit when-to-use or when-not-to-use guidance, exclusions, or routing hints toward 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'authenticated account' (auth requirement) and the custom_note length limit, but does not disclose side effects (e.g., creating a pending invitation, sending a notification), reversibility, rate limits, or any required permissions beyond authentication. This is a significant gap for a mutating 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 two sentences plus a compact argument list. The purpose is front-loaded, and every sentence adds value. No fluff or repetition of schema defaults.

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 two-parameter tool with an output schema, the description covers the core purpose and parameters. It does not explain post-send behavior or error conditions, but given the tool's simplicity and the existence of an output schema, the description is adequately complete for an AI agent to invoke 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?

Schema description coverage is 0%, so the description must compensate. It does by explaining both parameters: profile_url is the URL of the member to connect with, and custom_note is an optional personalized message with a clear 300-character limit. This adds meaningful constraints and purpose that the schema lacks, though it could include a format example for profile_url.

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 explicitly states the action ('Send a connection invitation to a professional') and the resource ('from your authenticated account'). It clearly differentiates from siblings like manage_invitation (handling invitations) and send_message (messaging) by using the specific verb 'send' and noun 'connection invitation'.

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 purpose implies when to use the tool (when you want to initiate a connection), but there is no explicit guidance about when not to use it or how it compares to alternatives such as manage_invitation or search_people. No exclusions or conditional routing are provided.

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 states the action and arguments; it does not disclose potential irreversible effects, failure modes, rate limits, or whether an active login or recipient relationship is required. The description adds little beyond what the tool name already implies.

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

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

The description is short and front-loaded with the core action, followed by a minimal argument list. There is no filler or redundant information; every sentence contributes to understanding the tool.

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

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

For a two-parameter action tool with an output schema, the description covers the basic mechanics. It is incomplete for a LinkedIn messaging context because it omits login preconditions, recipient eligibility requirements, and common error scenarios—details that matter when the sibling set includes authentication and messaging tools.

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 Args section gives plain-language meanings for both parameters ('Profile URL of the recipient', 'message body to send'), which helps because schema description coverage is 0%. However, it largely restates the property names and provides no URL format, message length constraints, or other validation details, so it only partially compensates 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 uses a specific verb-resource pair ('Send a direct message to a LinkedIn member') and names the arguments. This clearly distinguishes it from sibling tools like send_connection_request, create_post, or get_conversation_messages without needing to inspect 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?

The purpose statement implies the main use case—send a direct message as the authenticated user—and 'from your authenticated account' gives some context. However, it does not explicitly explain when to choose this over send_connection_request, manage_invitation, or get_conversation_messages, nor does it mention preconditions like being logged in or recipient connection status.

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 discloses three important behaviors: the window is interactive, the user must complete 2FA, and the session is saved for later use. It could go further by noting side effects on any existing session or environment requirements, but what it states is genuinely informative.

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 definition is compact and front-loaded. The main behavior is in the first sentence, and the only parameter is documented in exactly one line. There is 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 tool with no required arguments and an output schema, the definition is nearly complete. It explains the action, the interactive nature, the 2FA step, the session persistence, and the timeout semantics. A small gap is the absence of any statement about whether an existing session is replaced or invalidated.

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 explain the parameter, and it does. 'Maximum time in seconds to wait for sign-in (default: 300)' adds real semantic meaning beyond the bare schema, clarifying that the tool blocks up to this timeout and that 300 is the default.

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 specific verb and object: 'Open an interactive browser window to sign in to LinkedIn, solve 2FA, and save the session.' This clearly distinguishes the tool from siblings like check_login_status, logout, and refresh_session by focusing on the initial interactive login flow.

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 intended use is clear: call this when you need to establish a LinkedIn session interactively. However, the description does not explicitly say when not to use it, mention checking an existing session first, or name an alternative tool such as check_login_status for verifying authentication.

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 carries the full behavioral disclosure burden. It does add the useful account-scope constraint, but it does not state whether omitted fields are reset, whether the update is partial or full replacement, whether an active session is required, or any side effects. This is a significant gap for a mutation 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 compact and well organized: purpose first, then a security notice, then a clear Args breakdown. Every line adds value and there is no redundant restatement 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?

The description covers the core purpose, parameter meanings, and account scope, and an output schema exists so return values need not be described. Still, without annotations it leaves important operational context unstated, such as partial-update behavior, authentication prerequisites, and what happens if an empty argument list is provided.

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

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

Schema description coverage is 0%, yet the description compensates thoroughly by explaining every parameter, providing examples, and listing the expected values for location_types and employment_types. This gives the agent the semantic meaning that the sparse schema lacks.

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 ('Configure') and a clear resource ('your Open to work job preferences on LinkedIn'). It is easily distinguished from sibling tools like update_my_headline or update_my_about because the target is uniquely identified.

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 purpose implies this tool should be used when updating the authenticated user's LinkedIn job preferences, and the security notice clarifies it applies only to /in/me. However, there is no explicit when-to-use guidance, no mention of alternatives, and no exclusions beyond the account-scope constraint.

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?

There are no annotations, so the description carries the behavioral burden. It discloses an important security/auth constraint ('Strictly locked to your authenticated account'), which is useful. However, it doesn't state whether the existing About section is replaced, what side effects occur, or any permission details beyond being authenticated.

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, front-loaded with the core purpose, and every sentence adds value. The security notice is placed prominently, and the parameter explanation is minimal but sufficient.

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 one-parameter update tool, the description covers the essential facts: what is updated, whose profile, and what the parameter means. It doesn't explicitly state that the summary overwrites the existing About text, but 'New bio/summary text' implies replacement. An output schema exists, so the lack of return-value detail is acceptable.

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 clarify the parameter. It does: 'summary: New bio/summary text for your About section' adds meaning beyond the raw schema by explaining that this is the new replacement text. It could add length limits or formatting details, but it sufficiently compensates for the missing schema description.

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 ('Update') and the exact resource ('the About / summary section on your own LinkedIn profile'). It also distinguishes this tool from siblings like update_my_headline by naming a different profile section, and 'your own' establishes scope.

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 clear context: this tool is strictly for updating your own profile's About section. It doesn't explicitly list alternatives or say when not to use it, but the scope is unambiguous enough that an agent won't confuse it with other update tools.

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

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

With no annotations, the description carries the behavioral disclosure burden. It goes beyond the schema by stating the tool is strictly locked to the authenticated account and refuses other profile targets. It does not detail auth or failure behavior, but for a simple single-field update the key security behavior is disclosed.

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 sections with no filler: purpose, security notice, and argument definition. The most important scoping information is front-loaded.

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

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

For a one-parameter update tool with an output schema, everything an agent needs to call it correctly is present: what it updates, on whose profile, and what the argument means. No return-value documentation is required because 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?

The schema only provides the parameter name and type; the description's 'Args' section explains that 'headline' is the new text displayed under your name. This is exactly the kind of semantic enrichment the schema lacks.

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 ('Update the headline on your own LinkedIn profile') and adds a clear scope boundary ('Does not accept any other profile target'). This is sufficient to distinguish it from sibling profile update tools like update_my_about or update_my_services.

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 makes it clear this applies only to your own profile and sets a hard exclusion ('Does not accept any other profile target'). It does not explicitly name alternative tools or state 'use this when...', but the scope is clear enough for an agent to select 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?

With no annotations provided, the description carries the full burden. It discloses that the operation is strictly locked to the authenticated account, which is useful behavioral context. It also mentions the 500-character limit for description. However, it doesn't disclose whether the operation is additive, destructive, or reversible, what happens to existing services not mentioned, or whether the tool requires an active session. The security notice adds value but the mutation behavior is under-specified.

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 core purpose. The security notice is prominent and the parameter explanations are concise. The only minor issue is that the parameter explanations could be considered redundant with the schema names, but the examples and character limit justify their inclusion. No wasted sentences.

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

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

The tool has 3 parameters, no required fields, no annotations, and an output schema exists. The description covers the parameters and the account-scoping constraint, which is the main contextual risk. However, it doesn't explain what the output schema contains, whether the operation is idempotent, or how it interacts with existing services (e.g., does removing a service also remove associated projects?). For a mutation tool with no annotations, this is adequate but not complete.

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

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

Schema description coverage is 0%, so the description must compensate. It does: it explains services_to_add and services_to_remove with concrete examples, and describes the description parameter with a character limit. This adds meaning beyond the bare schema, which only provides types and defaults. The examples are particularly helpful for an agent deciding how to format list values.

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

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

The description clearly states the verb ('Configure or update') and the resource ('client services listed on your own LinkedIn profile'). It distinguishes itself from siblings like update_my_headline and update_my_about by focusing on services. However, it doesn't explicitly name a sibling alternative, so it doesn't fully differentiate from other profile-update tools.

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 usage context: it's for updating services on your own profile, and the security notice clarifies it's locked to the authenticated account. It doesn't explicitly state when to use this tool versus alternatives like update_my_about or add_experience, nor does it mention any prerequisites. The context is clear enough for an agent to infer the primary use case, but exclusions and alternatives are missing.

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 burden and explicitly discloses that the operation is 'strictly read-only' and acts as the authenticated user. It doesn't cover edge cases such as private-profile visibility, but for a simple read operation this is adequate.

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 plus an Arg line and contains no filler. Every clause ('another', 'strictly read-only', 'as your authenticated user') carries signal.

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 a single-parameter read-only lookup, with an output schema present, so the description covers the input format and the operation's safety. Nothing required to invoke the tool 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?

The schema only says 'Profile Url', so the description's clarification that the value can be a profile URL or vanity username adds meaningful input guidance. This compensates for the 0% schema coverage.

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 ('View another LinkedIn member's profile') with an explicit scope ('another', not your own), which distinguishes it from get_my_profile and search_people. The read-only qualifier further sharpens the intent.

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?

Indicates this is the tool for inspecting another member's profile as the authenticated user, and the 'another' framing implies get_my_profile is the alternative for one's own profile. It doesn't name sibling alternatives explicitly, but the context is clear enough.

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