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

The annotations already declare readOnlyHint=true, and the description aligns by presenting the tool as a non-mutating status check. It adds useful context by clarifying that the check is about the server's stored token state, and it signals no side effects such as starting a flow or modifying credentials.

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 states exactly what the tool checks and avoids redundant restatements of the tool name.

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 status check with no output schema, this description is mostly complete: 'Check whether' clearly implies a boolean or status result. It does not spell out the return shape, but the ambiguity is low given the tool's simplicity and the sibling 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 tool has zero parameters and the schema covers 100% of what an agent needs to know. The description adds no parameter detail, but none is needed because there is nothing for the agent to configure or pass.

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 ('Check') and a specific resource ('stored LinkedIn OAuth token'), making the tool's purpose immediately clear. It also distinguishes itself from the sibling auth tools, which perform actions like starting OAuth, exchanging codes, or logging out.

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 a read-only pre-flight check before using authenticated LinkedIn operations, but it does not explicitly state when to use it versus the OAuth-flow siblings. There is no exclusion like 'do not use this to start OAuth' or 'call this before other LinkedIn 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?

Annotations already signal that this is a mutating, non-read-only operation, so the description does not need to restate that. It adds the useful distinction between publishing and drafting, and specifies that only text content is supported. It does not disclose additional behaviors such as the post becoming publicly visible, permission requirements, or irreversible external effects.

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 14-word sentence carries the core purpose, action, resource type, and author scope without any filler. The most decision-relevant 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 6-parameter write operation with no output schema, one sentence is insufficient. The description omits any mention of the response/return value, auth prerequisites, the meaning of the visibility and lifecycle defaults, and when to use this tool versus the auth and retrieval siblings. An agent would need schema and external reasoning to invoke it confidently.

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 only 50%, so the description needed to compensate. It does clarify that author_urn can be a person or organization and that the content body is text-only, which addresses commentary's undocumented schema entry. However, it does not elaborate on visibility, lifecycle_state, reshare_parent_urn, or access_token beyond what the schema already states.

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 pair, 'Publish or draft', names the exact resource ('text-only LinkedIn post'), and scopes it to 'member or organization author URN'. This clearly distinguishes it from sibling tools like linkedin_get_post and linkedin_find_posts_by_author, which are retrieval operations.

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 'Publish or draft' implies that the tool is for creating posts rather than fetching them, so usage is inferable from context. However, there is no explicit guidance about prerequisites such as OAuth, when to prefer DRAFT vs PUBLISHED, or when not to use this tool compared with the auth/profile sibling 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?

Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive. The description adds the useful side-effect that the token is stored locally, but it does not cover other behavioral details such as network interaction consequences or whether existing stored tokens are overwritten.

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, well-front-loaded sentence communicates the core action and the local-storage side effect with no wasted words.

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

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

With no output schema and minimal annotations, the description leaves important context unstated: how the authorization code is obtained, what the result looks like, whether existing tokens are replaced, and the relationship to the sibling OAuth flow tool. An agent can call it correctly only by relying on OAuth domain knowledge.

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?

Only one of five parameters has a schema description, and the tool description does not compensate by explaining client_id, client_secret, redirect_uri, or code beyond their names. The description adds little meaning beyond what an agent can infer from standard OAuth parameter names.

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: exchanging a LinkedIn OAuth authorization code for tokens. It clearly distinguishes itself from the sibling linkedin_start_oauth_flow by focusing on the code-exchange step rather than flow initiation.

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 term 'authorization code' implies this tool is used after the OAuth flow has produced a code, but the description does not explicitly say when to use it versus siblings like linkedin_start_oauth_flow or linkedin_auth_status. Usage context is implied rather than stated.

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

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

The annotations already declare readOnlyHint=true, and the description's read behavior is consistent with that. But the description adds no extra behavioral context such as pagination behavior, response contents, or what the openWorldHint implies in practice.

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 one clear, front-loaded sentence with no filler or redundant phrasing. Every word contributes to identifying what the tool retrieves and for whom.

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 schema provides useful defaults and constraints, and the readOnlyHint covers safety, so a default call with author_urn is understandable. However, there is no output schema and no explanation of how view_context, count, and start affect results, leaving non-default invocations under-specified.

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?

With only 20% schema description coverage, the description needed to clarify the less obvious parameters, especially view_context, count, and start. It only echoes the author_urn concept already present in the schema, leaving the READER vs AUTHOR distinction unexplained.

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 ('Find'), a specific resource ('LinkedIn posts'), and a clear scope ('by member or organization author URN'). This differentiates it from sibling tools such as linkedin_get_post or linkedin_create_text_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 phrase 'by member or organization author URN' implies the tool is for retrieving posts associated with a known author. However, it does not explicitly contrast this with alternatives or state when not to use 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?

Annotations already declare readOnlyHint=true, so the description does not need to restate safety. It adds the useful detail that this uses the OIDC userinfo endpoint, which implies OIDC-style profile claims, but it does not mention token failures, required scopes, or return-value behavior. With annotations carrying the core safety signal, a mid score is appropriate.

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 sentence that names the action, resource, and endpoint with no filler. Every word contributes meaning and the core purpose 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 simple one-parameter read tool with supportive annotations, the description is nearly complete. It could explicitly mention the standard OIDC claims returned, but 'OIDC userinfo endpoint' gives a strong signal about the response shape, and no output schema is present to fill 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?

There is only one optional parameter and the schema describes it completely, including its defaulting behavior. The description adds nothing beyond the schema, but with 100% schema description coverage, the baseline of 3 is correct.

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 specific action ('Read'), the resource ('authenticated LinkedIn member profile'), and the implementation path ('OIDC userinfo endpoint'). Sibling tools are all about auth or posts, so this tool is unambiguously distinguished as the one for retrieving the current user's 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 implies the right context: the caller must be authenticated, and the tool returns the caller's own profile. It does not explicitly name alternatives or state when not to use it, but the sibling set contains no other profile-fetching tool, so the intended usage is clear.

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

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

The readOnlyHint annotation already signals this is a safe read operation, and the description's 'Retrieve' wording is consistent with that. The description does not add much behavioral context beyond the schema, such as response shape, authentication expectations, or error behavior, but it also introduces no contradiction.

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 filler. It communicates the core purpose efficiently and is well-sized for a straightforward retrieval 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 simple read operation, the core call pattern is clear, and annotations cover safety. However, the description leaves the view_context parameter unexplained and does not describe what the returned post object contains, which is a notable gap given there is no output schema.

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

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

Schema description coverage is only 33%. The description mentions URN-based lookup but does not explain the meaning of view_context (READER vs AUTHOR) or how it affects the response, and it adds little beyond the property name 'post_urn' already present in the schema.

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

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

The description states a specific action and resource: 'Retrieve a LinkedIn post by URN.' This clearly distinguishes the tool from siblings like create_text_post and find_posts_by_author, which involve different operations and inputs.

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 using this tool when you have a LinkedIn post URN and need the post's details. However, it provides no explicit guidance about when not to use it or when to prefer find_posts_by_author 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?

The annotations already flag destructiveHint=true, and the description adds valuable context by specifying the deletion is local only and scoped to this MCP server. This clarifies that the action is not a full LinkedIn account logout or server-side token revocation, which is useful beyond what annotations provide.

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 and target resource without any filler. Every word earns its place.

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

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

For a no-parameter, destructive-but-local operation with annotations already covering the safety profile, the description is nearly complete. The main omission is what happens if no token exists (e.g., idempotency or error behavior), but this is minor for such a simple 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?

With zero parameters, there is no schema burden to compensate for. The baseline of 4 applies, and the description accurately reflects that no inputs are needed.

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

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

The description states a specific action (delete) and a specific resource (the locally stored LinkedIn OAuth token for this MCP server). This clearly distinguishes the tool from its OAuth-flow siblings and leaves no ambiguity about its function.

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

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

The purpose implies when to use it: when logging out of LinkedIn via this MCP server. However, it does not explicitly contrast it with alternatives like linkedin_auth_status or linkedin_start_oauth_flow, nor does it state when not to use it, so usage guidance remains implied rather than explicit.

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 indicate a mutating, open-world tool, and the description adds concrete behavioral detail: it launches a browser-based flow, waits for a localhost callback, exchanges the authorization code, and persists the token locally. This goes beyond the annotations without contradicting them.

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 that names the action, the mechanism, and the outcome with no filler or redundancy. Every phrase contributes to the agent's understanding.

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 captures the core flow and side effect well, which is adequate for a high-level selection decision. However, it omits important operational context for a complex OAuth tool: browser availability, human authorization steps, timeout implications, token storage details, and what the result contains, especially since no output schema 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 high at 86%, so the schema carries most parameter meaning. The description mentions 'localhost callback' and 'store the token locally,' which loosely aligns with redirect_uri and token handling, but it does not meaningfully expand on any individual 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 verb and resource: starting a browser-based LinkedIn OAuth flow, then captures callback, exchanges code, and stores token. It is clear what the tool does, though it does not explicitly distinguish itself from the sibling linkedin_exchange_authorization_code, which also involves exchanging a code.

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

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

The description gives no guidance on when to use this tool versus alternatives such as linkedin_exchange_authorization_code or linkedin_auth_status. Contextual conditions, prerequisites like a registered redirect URI, and whether this is the right tool for an already-obtained code are all left unstated.

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