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

Annotations already show this is a write and non-idempotent operation. The description adds meaningful behavioral context: it requires the w_member_social scope, always returns status 'PUBLISHED', and creates a publicly visible or restricted feed post. It does not mention rate limits or reversibility, but it does not contradict the annotations.

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

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

The description is well structured with a one-line summary, Args, Returns, and a scope requirement. There is mild redundancy between the first sentence and the title, but the content is relevant and 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?

Given that the schema declares no parameters and there is no output schema, the description is remarkably complete: purpose, parameters, defaults, visibility enum, return fields, and auth scop e are all present. An agent can call this tool and interpret the response without additional 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 is empty, so the description carries the full burden of parameter documentation. It defines text as required with a 1-3000 character constraint, provides the visibility enum with a default, and documents response_format with a default. This is complete and actionable for an agent.

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: 'Create and publish a new LinkedIn post.' It further clarifies that it publishes a text post to the user's feed and supports distinct visibility modes, making it easy to distinguish from siblings like linkedin_send_message or linkedin_delete_post.

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 for when to use the tool: publishing a text post to the LinkedIn feed with PUBLIC, CONNECTIONS, or LOGGED_IN visibility. It does not explicitly name alternative tools or state when not to use it, so it stops short of full routing guidance, but the intended use case is unambiguous.

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

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

Beyond the destructiveHint annotation, the description adds critical context: the deletion is permanent and cannot be undone, and it requires the w_member_social OAuth scope. This gives the agent meaningful behavioral information beyond what annotations already declare.

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 dense with useful information: a clear opening warning, parameter list, return format, and required scope. Every section earns its place, and the destructive warning is front-loaded for immediate visibility.

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 destructive operation, the description is complete. It covers inputs, output shape, required scope, and permanence, and since there is no output schema, the explicit return example fills that gap.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description mostly repeats the schema details, providing the same examples for post_id and the same default for response_format, adding little new semantic value.

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: 'Permanently delete a LinkedIn post by its ID or URN.' This clearly distinguishes the tool from sibling tools like linkedin_create_post and linkedin_list_posts, so an agent can select it without ambiguity.

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

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

The description clearly states the operation and prerequisites, but it does not explicitly say when to prefer this tool over alternatives or mention when not to use it. The destructive warning implies careful usage, but there is no routing to sibling tools such as listing posts first to get a valid post_id.

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

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

Annotations already state readOnly/idempotent/non-destructive, but the description adds meaningful behavioral context beyond those: pagination behavior via start/count/has_more and the critical Partner Program limiation that standard OAuth apps will receive an error. This is genuinely useful risk disclosure.

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

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

The description is well-structured and front-loaded with the core purpose. The Args section is somewhat redundant with the schema, but the return-shape example and the Partner Program caveat ear their place, keeping the overall definition compact and scannable.

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 read-only, non-destructive tool with no output schema, the description provides the return JSON shape, pagination fields, defaults, and a critical access limiation. Nothing an agent needs to select or invoke this 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 input schema already documents all three parameters with defaults, constraints, and descriptions, so the description's Args section mostly repeats schema information. Baseline 3 is appropriate because schema coverage is 100% and the description adds no new semantic meaning beyond what the schema provides.

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

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

The description states a specific verb and resource: 'Get the authenticated user's LinkedIn connections,' and immediately clarifies it lists '1st-degree connections.' This clearly distinguishes it from sibling tools like list_posts or search_people by naming the exact data set being returned.

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 frames when this tool is appropriate: when you need the authenticated user's 1st-degree connections, with pagination. It does not explicitly name alternatives or exclusions, so it misses the top tier, but the context is unambiguous.

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

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

Annotations already carry readOnlyHint, idempotentHint, and destructiveHint=false, so the description mainly adds extra context. It reveals that the feed belongs to the authenticated user, that results are paginated with has_more, and that LinkedIn's public API has limited feed access — useful behavioral nuance beyond the structured 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 front-loaded with the core purpose and then organized into Args and Returns sections. The Args block duplicates schema information somewhat, but the Returns block is valuable because there is no output schema, and the note about limited API access is non-redundant.

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

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

For a read-only tool with full parameter annotations, the description provides everything needed to invoke it correctly: parameter meanings, defaults, output format options, a detailed return structure, and a caveat about API limitations. The absence of an output schema is compensated by the embedded JSON return example.

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

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

Schema description coverage is 100%, so the input schema already fully documents all three parameters. The description restates start, count, and response_format with defaults and enums, but does not add meaningfully new semantics beyond what the schema provides.

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

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

The description names a specific verb and resource: 'Get recent activity from the authenticated user's LinkedIn feed.' It is clear about what the tool returns, but it does not explicitly differentiate itself from the sibling linkedin_list_posts, which could overlap conceptually with feed items.

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 usage is implied by the name and description: reading the authenticated user's feed vs. creating or sending LinkedIn content. However, there is no explicit guidance about when to prefer this tool over linkedin_list_posts or other siblings, and no exclusions are stated.

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

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

Annotations already declare read-only and idempotent behavior. The description goes further by revealing that the tool combines the OpenID Connect userinfo endpoint and the LinkedIn profile API, requiring specific scopes, which is meaningful behavioral context beyond the annotations.

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

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

The description is front-loaded with the main purpose and uses structured Args and Returns sections. It is a bit longer than strictly necessary due to duplicating the schema's parameter info, but the return-structure block earns its place since there is no output 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?

With no output schema, the description compensates by enumerating every return field, the response format options, and scope requirements. It is complete enough for an agent to invoke the tool with confidence. Minor gaps like error scenarios or when email may be missing prevent a perfect score.

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

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

Schema coverage is 100% and the schema already documents response_format with an enum, default value, and description. The description mostly restates that parameter. The detailed return-shape block is useful but relates more to output semantics than to deeper parameter meaning.

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

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

The description clearly specifies the verb 'Get' and resource 'the authenticated user's LinkedIn profile information,' and the details about full profile data and endpoint composition make the purpose apparent. However, it never explicitly differentiates itself from the sibling linkedin_get_user_info, so it stops short of full sibling distinction.

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

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

The description provides clear context for when to use the tool: whenever the authenticated user's own profile data is needed. It also notes the required OAuth scopes, which is valuable operational guidance, but it does not explicitly say when not to use this tool or 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?

The annotations already mark this as read-only, idempotent, and non-destructive. The description adds behavioral context by disclosing the required 'openid' scope, noting that email is only returned if the 'email' scope is granted, and fully documenting the response shape. No contradictions with 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 well-structured and front-loaded: purpose first, then return fields, then sibling differentiation, then parameters/return example/scope. Every section earns its place and the prose is tight with no fluff, even though the JSON return example is somewhat detailed.

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?

Despite having no output schema, the description provides a full JSON return contract, covers the parameter, states the required scope, and clarifies behavior with minimal scopes. An agent has everything needed to invoke the tool correctly and understand what it will receive.

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

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

The single parameter is already fully documented with 100% schema coverage, including enum values, default, and a concise description. The description's Args section merely restates this information without adding deeper semantics, so the baseline score of 3 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 first sentence states a specific action and resource: 'Get basic user identity information via OpenID Connect.' It enumerates exactly which fields are returned and explicitly differentiates from getMyProfile via the minimal-scope guarantee, so an agent can distinguish it from its sibling 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 provides a clear usage context by stating it 'always works even with minimal scopes' and contrasting it with getMyProfile. This tells the agent when to prefer this tool over the likely alternative, though it doesn't explicitly describe when to choose getMyProfile instead.

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

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

Annotations already mark the tool as read-only and idempotent. The description goes well beyond that by disclosing pagination semantics, ordering (newest-first), scopes required (r_member_social/r_organization_social), and the exact JSON response structure including fields like total, has_more, and next_offset. There is no contradiction with 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 front-loaded with the core purpose, then provides structured Args and Returns sections that are dense but not verbose. Every section earns its place, especially the response JSON sample, which is essential because there is no output 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 self-sufficient for an agent: it explains default behavior, member targeting, pagination, maximum count, output format options, required scopes, and the full response shape. Since no output schema exists, the detailed JSON return specification fills exactly that gap.

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

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

Schema description coverage is 100%, so each parameter is already documented in the schema. The description's Args section largely repeats defaults and meanings already present in the schema (count max 50, start defalt 0, response_format enum), adding little semantic value beyond what the input schema provides.

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

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

The description clearly states the verb ('List') and resource ('LinkedIn posts for a member'), and specifies that it returns posts published by the specified member or the authenticated user by default. It does not explicitly contrast itself with sibling tools like linkedin_get_feed, so it stops short of full explicit sibling differentiation.

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

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

The description gives clear invocation context: it lists posts for a specified member, defaults to the authenticated user, and explains pagination behavior with start/count/next_offset. It does not explicitly state when to prefer this over linkedin_get_feed or linkedin_create_post, but the 'posts published by a member' framing makes the intended use obvious.

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 meaningful annotation guidance, the description carries full weight. It discloses that the tool opens a browser, captures the callback, exchanges the authorization code, and saves the token to the config file. It also mentions the return value and prerequisites, giving the agent a clear model of side effects and persistence 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 well-structured with a summary, prerequisites, args, and return value, and it front-loads the core purpose. It is more verbose than strictly necessary because the Args section duplicates the schema, but the extra context about prerequisites and token persistence earns its place.

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

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

For an OAuth login tool with three optional parameters and no output schema, this description is complete. It explains the flow, side effects, prerequisites, parameter behavior, and what the caller receives. An agent can invoke this tool and understand the downstream consequence for all other tools without further guessing.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The Args section mostly repeats the schema's names, ranges, defaults, and meanings, adding little beyond the schema. The only marginal addition is 'Set false for headless,' which is already effectively captured in the 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 states a specific verb and resource: 'Authenticate with LinkedIn using OAuth PKCE flow.' It further describes the end-to-end process, making it unmistakably distinct from the sibling data-operation tools like linkedin_create_post or linkedin_get_my_profile.

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 frames this as the recommended authentication step and notes that 'all other tools can use the saved token automatically,' which establishes when to use it. It also lists the required prerequisites. It does not explicitly name alternatives or exclusion conditions, but the context strongly implies this is the entry point for all other 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?

Beyond the readOnly and idempotent annotations, the description discloses a critical behavioral trait: it returns a clear error message explaining the limitation under standard OAuth. This prevents an agent from expecting real results and is a valuable addition.

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 warning is front-loaded and the error behavior is stated clearly in a few sentences. The Args list is redundant with the schema but does not make the description unnecessarily long or unclear.

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 whose observable behavior is to fail with a clear error, the description is complete: it explains availability constraints, required prerequisites, and expected error behavior. No output schema is needed because the tool does not return real search results under normal circumstances.

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

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

Schema description coverage is 100%, so the parameters are already fully documented in the schema. The description's Args block largely repeats that information without adding semantic detail beyond what the schema provides.

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

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

The description clearly identifies the tool as searching LinkedIn members by keywords, and immediately flags that it is not available with standard OAuth. The title also reinforces this limitation. This is a specific verb and resource, unambiguously differentiated from reading profiles or posts.

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 explicitly warns that the tool is NOT available with standard OAuth and explains that Sales Navigator API or a third-party provider is required. It gives clear when-not-to-use guidance, though it does not point to a specific sibling tool as an alternative.

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

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

The description adds meaningful behavioral context beyond the annotations by warning that the tool is not available with standard OAuth apps and that it will return a clear error message explaining the limitation. This is valuable because it sets expectations that the call may fail in the current auth context. No contradiction with the annotations exists.

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: purpose first, then an important warning, then a note about error behavior, then parameters. The Args section is somewhat redundant with the schema, but the overall layout is scannable and free of unnecessary filler.

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

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

For a tool with three flat params and no output schema, the description covers the parameters, required auth access, limitation behavior, and output format. It does not describe the shape of a successful response, but given the explicit statement that an error message will be returned under the common standard-OAuth setup, the context is adequately 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 100%, so the schema already documents all parameters. The Args block restates the same information with only minor formatting details, such as '1-2000 chars', which duplicates the schema constraints. It adds no new semantic guidance like recipient ID format examples or message encoding details.

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 begins with a specific verb and resource: 'Send a direct message to a LinkedIn member.' This clearly distinguishes it from sibling tools like linkedin_create_post or linkedin_get_feed, which operate on different resources or actions.

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

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

The description clearly states the critical prerequisite: standard OAuth apps cannot use this tool, and Messaging API partner access is required. This tells the agent when the tool cannot be used, though it does not explicitly name alternative tools or direct the agent to alternatives when unavailable.

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