LinkMCP: hosted LinkedIn MCP server

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds that result reliability depends on which company identifier is supplied, but says nothing about behavior when no match is found or about lookup limits.

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 sentences: purpose first, prerequisite second, accuracy tip third. Each sentence carries distinct, actionable information with no 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?

With full parameter documentation and annotations covering the safety profile, an agent has nearly everything needed. The only omission is failure behavior — what comes back when no email is found — which matters for a best-effort lookup like this.

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 baseline would be 3. The description still adds value by ranking company_domain above company_name and explaining that domain drives reliability, which the schema only hints at with 'Recommended for best accuracy.'

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: find a person's work email address from name and company. This clearly separates it from the sibling find_mobile (phone numbers) and from validate_email (verifying an existing address).

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?

Gives a concrete prerequisite (use linkedin_get_profile first when name/company are missing) and advises preferring company_domain for accuracy. It does not explain when to prefer validate_email over this tool, so it stops short of full alternative routing.

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 readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description adds the useful constraint that at least one identifier is required (the schema marks none as required), but says nothing about lookup success/failure behavior or rate limits.

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, front-loaded sentences with zero waste: purpose, inputs, and the constraint in that order. Every sentence 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 simple two-parameter lookup with no output schema and full annotation coverage, the description is largely complete. It would be stronger if it hinted at what a result looks like (found vs not found) or referenced the related find_email 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?

Schema coverage is 100%, so the schema already documents both parameters with examples. The description adds a small amount by clarifying the 'and/or' combination relationship and the minimum-identifier requirement, but provides no format details beyond what the schema gives.

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 (Find) and resource (mobile phone number), which clearly distinguishes it from sibling find_email. However, it does not explicitly name or contrast against that sibling, leaving the differentiation to inference.

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

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

The description implies usage by listing accepted identifiers and the 'at least one required' constraint, giving a usable sense of when it applies. But it offers no explicit when-to-use vs alternatives guidance and does not mention find_email or validate_email as related 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?

The description adds genuinely useful behavior beyond annotations: per-item results with error tracking and no fail-fast on first error. Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld). It does not describe return shape or partial-failure semantics beyond 'error tracking', so a 3 fits.

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 tight, front-loaded sentences. The scope constraint and the key behavioral differentiator (bulk, never stops on first error) are both stated with zero 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 one-parameter bulk reader with a fully documented schema and annotations covering safety, the description supplies the missing non-obvious behavior (per-item error tracking). It lacks explicit routing vs. the singular sibling and any note on response shape, keeping it just under 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 single 'identifiers' parameter already has a 100% coverage schema description listing accepted formats (URLs, slugs, numeric IDs) and the 1–10 range. The description adds no syntax or format detail beyond what the schema provides, so baseline 3 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?

States a specific verb (fetch) and resource (slim company profiles) with a bulk scope of up to 10. It is distinguishable from the singular sibling linkedin_get_company, but the description never names that sibling explicitly, 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?

The 'up to 10' bulk constraint and 'slim' qualifier imply when to prefer this over the single-get tool, but there is no explicit when-to-use guidance, no conditions for choosing it over linkedin_get_company, and no exclusions stated. Usage is only implied.

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, idempotent, non-destructive behavior, so the safety profile is covered. The description adds genuinely useful behavior beyond that: identical per-profile cost, per-item results, and the guarantee that it never stops on the first error.

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?

Front-loaded with the action and limit, then detail semantics, then cost and error behavior. Dense but efficient; the detail descriptions are slightly redundant with the schema enum description but not wasteful.

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?

No output schema exists, so the description compensates by describing return granularity (per-item results) and failure semantics (never stops on the first error). Combined with the cost and detail-mode notes, an agent has everything needed to call this correctly alongside its siblings.

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 both parameters are already documented in the schema, so baseline is 3. The description adds meaning on top of the schema by spelling out exactly what fields each detail mode returns and reiterating the equal cost per profile.

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 (fetch) and resource (LinkedIn profiles) with an explicit bulk scope (up to 10), which distinguishes it from the singular linkedin_get_profile sibling. It also names what it is not (company details) and routes that need to linkedin_get_company.

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?

Gives a clear batching limit (up to 10), explains the detail-mode tradeoff, and explicitly redirects company lookups to linkedin_get_company. It does not state when to prefer this over calling linkedin_get_profile repeatedly, though the batching rationale is implied.

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 non-read-only, non-idempotent, open-world behavior, so the safety profile is covered. The description adds genuinely useful context that mention identifiers are auto-resolved from URLs/slugs/URNs, but says nothing about auth requirements, rate limits, or what happens on duplicate/failed comments.

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 tight sentences with the core action front-loaded and no redundant filler; every clause conveys a distinct capability.

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 tool with no output schema, the description covers the key behaviors (threaded reply, mention resolution, content checking left to schema). It omits return/error semantics, but annotations and the rich schema largely fill the remaining gaps.

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%, including each parameter and the content_check enum, so the schema carries the load. The description's mention of URL/slug/URN resolution largely restates the mentions.identifier schema text, adding little beyond baseline.

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

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

The description opens with a specific verb+resource ('Comment on a LinkedIn post') and immediately names its distinctive capabilities (threaded replies, @mentions), which cleanly separates it from read-side siblings such as linkedin_get_post_comments and linkedin_get_nested_comments.

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 implies when the tool is appropriate by describing threaded replies and mentions, but never states when to use it versus alternatives like linkedin_react_to_post or linkedin_create_post, nor any preconditions (e.g., must be connected to comment).

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 the mutation profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), lowering the bar. The description adds capability context (server-side image fetching from public URLs, reposting) but never states that the post goes live immediately, that it cannot be undone through this tool, or whether credentials/scopes 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?

Two tight sentences with the core action front-loaded and a compact capability list following. No filler or repetition, though it stops short of the kind of routing information that would make the brevity maximally valuable.

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

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

For a mutation tool with no output schema, the definition omits what a successful call returns (e.g., the created post's id/URL) and what failure modes look like, which matters for follow-up calls. Annotations and the rich schema cover safety and inputs, so the gap is moderate rather than severe.

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%, and the schema documents every parameter in more detail than the description (character limits, mention placeholder syntax, content_check enum behavior, link card requirement). The description only broadly restates those capabilities, so the baseline 3 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 states a specific verb and resource ('Create a LinkedIn post') and enumerates the supported content types (text, images, mentions, link cards, reposts). It does not, however, contrast itself against the closest write sibling (linkedin_comment_on_post) or clarify it is for publishing new top-level posts rather than replies.

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 when-to-use or when-not-to-use guidance is given; the sentence describes capabilities, not selection criteria. Nothing tells the agent why it would pick this over linkedin_comment_on_post or how reposting relates to reading existing posts via linkedin_get_person_posts.

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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds real behavioral context beyond them: a name lookup returns a single company on a clear match or a short candidate list otherwise, which tells the agent to expect an ambiguous result shape. It does not cover rate limits or pagination, keeping it short of a 5.

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 tight sentences, front-loaded with the primary action before the conditional lookup guidance. No filler or restatement 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?

There is no output schema, so the description must carry return-value burden, and it does explain the single-result-vs-candidate-list behavior. It never describes what a returned profile contains, but for a straightforward read tool the coverage is nearly sufficient.

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%, so the baseline is 3, and both parameters are already documented with their formats ('Use this or name, not both'). The description adds genuine meaning on top: the rationale for preferring identifier and the failure mode of slug guessing, which the schema does not explain.

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 ('Get a LinkedIn company profile') and explains the two lookup modes, which is more than a tautology. However, it never names the adjacent sibling linkedin_bulk_get_companies, so an agent must infer the single-vs-bulk distinction on its own.

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?

Gives explicit conditional routing: pass identifier when the URL/slug/ID is known, pass name when only the name is known, and explicitly warns against guessing a slug because LinkedIn slugs often differ from the name. The rule for choosing between the two parameters is fully specified.

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 readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: the approximate result volume (~30 posts) and the returned fields (text, engagement counts, post URL), which help the agent decide whether this tool fits.

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 compact sentences, with the core action and identifier forms front-loaded and the return shape following. No 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 read-only listing tool with no output schema, the description covers what is returned and how much, and pagination is handled by the schema's cursor parameter. Only minor gaps remain, such as ordering or freshness of 'recent' posts.

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 both parameters (identifier and cursor) are already documented in the schema, including the identifier formats the description repeats. The description adds no syntax or format detail beyond what structured data 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?

States a specific verb (Get) and resource (a company's recent LinkedIn posts) with the accepted identifier forms. It is distinguishable from siblings like linkedin_get_person_posts and linkedin_get_company without opening either schema.

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

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

Usage is implied by the resource scope (company posts, not person posts or company profile), but there is no explicit when-to-use/when-not-to-use guidance and no named alternative such as linkedin_get_company or linkedin_bulk_get_companies.

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, idempotentHint, destructiveHint=false, so the safety profile is covered. The description adds value beyond them by disclosing the returned fields (name, headline, profile URL, public identifier) and that pagination is cursor-based, which an agent would otherwise not know since no output schema 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?

Three short sentences, front-loaded with the core action, then return shape, then pagination. No filler and every sentence carries 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?

With no output schema, the description correctly compensates by listing returned fields, and it explains pagination. It does not mention auth requirements or rate limits, but for a simple read tool with full annotation coverage this is largely 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%, with both limit and cursor fully documented in the schema. The description reinforces pagination behavior but adds no new syntax or constraint detail beyond the schema, so the baseline 3 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?

States a specific verb ('List') and resource ('your LinkedIn connections'), plus the scope '1st-degree', which implicitly distinguishes it from linkedin_get_shared_connections and linkedin_search_people. It does not name those siblings explicitly, so it stays at 4 rather than 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?

Usage is implied by the purpose (list your connections) but there is no explicit when-to-use guidance, no mention of when to prefer linkedin_search_people for filtering or linkedin_get_shared_connections for overlaps. Minimum viable.

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 readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new behavioral context: page size bounds, the fact that the oldest returned message is not the conversation start when has_more is true, and the loop termination condition. It omits auth/permission or rate-limit notes, keeping it just short of 5.

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?

Four sentences, front-loaded with what the tool does and what it returns, then prerequisite, then pagination. Every sentence carries distinct operational information with no padding.

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 naming returned fields (text, timestamp, sender ID, read status, attachments) and fully specifying the pagination contract. An agent has everything needed to make a correct single call and to page 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 coverage is 100%, so the baseline is 3 and the schema already documents chat_id, limit and cursor. The description goes beyond that by wiring cursor to next_cursor in an explicit multi-call loop, which clarifies intended usage of the parameter rather than restating it.

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 ('Get messages from a LinkedIn DM conversation') plus ordering ('newest first'), which cleanly distinguishes it from the sibling linkedin_list_conversations. An agent can tell exactly what this returns without opening the schema.

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?

Gives the explicit prerequisite alternative ('Use linkedin_list_conversations first to get the chat_id') and a full when-to-repeat rule tied to has_more/next_cursor. Nothing about selecting or continuing this tool is left to inference.

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, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds real behavioral detail beyond that: results are most-recent-first, cursors are type-specific and must be reused with the same type, and the final page may legitimately be empty. Only return-shape detail (fields per item) is partially left implicit.

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?

Front-loaded with purpose, then chaining and pagination in a logical order. Dense but each clause carries usable information; it is slightly long for a 3-parameter list 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?

There is no output schema, so the description carries the burden of describing returns — and it does, naming postUrl, activityUrn, and commentId and explaining what each is used for downstream. Combined with pagination and ordering notes, an agent has everything needed to call and consume this 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?

Schema coverage is 100% and the enum values are already documented in the schema, so the baseline is 3. The description reinforces the type-specificity of cursor and the meaning of limit/pagination, but adds little genuinely new parameter semantics beyond what the schema 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?

States a specific verb and resource ('List your own LinkedIn engagement activity') and immediately splits it into the two enum modes with plain-language glosses. An agent can distinguish it from linkedin_get_post_comments / linkedin_get_post_reactions because it is explicitly scoped to the caller's own activity.

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?

Gives clear follow-up routing: pass postUrl/activityUrn to linkedin_get_post_comments or linkedin_get_post_reactions, and use commentId as parentCommentId in linkedin_get_nested_comments. It also explains pagination procedure. It does not state any when-not condition, but the positive guidance is unusually actionable.

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 readOnly/idempotent/non-destructive, so the safety bar is met. The description adds value beyond them: result ordering, the lightweight (preview-only) nature of each item, the enumerated preview fields, version limitation to 'posts', and the pagination contract. It doesn't discuss auth scopes or rate limits, but for a read-only listing those are minor.

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 sentences with zero filler: capability and ordering first, return shape second, alternative and pagination last. Every sentence earns its place and the most important 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?

With no output schema, the description compensates by enumerating the preview fields (activityUrn, postUrl, author, text snippet, relative time) and explaining pagination termination via nextStart. Combined with the two fully-documented parameters, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's pagination note largely echoes the schema's own 'use nextStart as start' text, and the type restriction is also documented in the enum description, so it adds little beyond structured fields.

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

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

States a specific verb+resource ('List items the connected user has saved on LinkedIn') plus ordering semantics ('most recent first'). It scopes the current capability ('v1 supports type "posts"') so the agent knows exactly what comes back and can distinguish it from siblings like linkedin_get_person_posts or linkedin_get_my_engagement.

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?

Explicitly routes the agent to the alternative ('Use linkedin_get_person_posts to fetch full post detail for any returned activityUrn') and states the condition that selects it. It also gives the pagination procedure ('passing the nextStart from a prior response as start'), so both when-to-use and how-to-iterate are covered.

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 readOnly, idempotent and non-destructive, so safety is covered. The description adds the meaningful behavioral context of an auth prerequisite ('Requires a connected LinkedIn account') and the chaining workflow. It doesn't discuss pagination behavior, but that is documented on the cursor parameter.

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 tight sentences: purpose first, then the chaining instruction, then the auth requirement. Every sentence earns its place and nothing is 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?

Complete for a read-only list tool: purpose, prerequisite, and the upstream workflow are all present. With no output schema required to be explained and full schema coverage of inputs, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so all three parameters are already documented, including cursor semantics and URN sourcing. The description reinforces which parentCommentId to pick, but adds little beyond what the schema text already says. Baseline 3 applies when the schema carries the detail.

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?

Specific verb (Get) plus resource (nested comments/replies) and scope (under a specific comment on a LinkedIn post). It clearly distinguishes itself from the sibling linkedin_get_post_comments, which returns top-level comments.

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?

Explicitly states when to use it ('Chain this after linkedin_get_post_comments') and the exact selection condition ('pick a comment where replyCount > 0'). The alternative and the routing rule are both named, leaving nothing to inference.

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, idempotent, open-world, and non-destructive behavior. The description adds valuable return context (up to ~50 posts, including text, engagement counts, and post URL), which is meaningful since no output schema exists. It does not cover pagination behavior or data freshness.

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 tight sentences with zero waste: the core action and identifier options are front-loaded, followed by return details. Every clause 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 simple read tool with 100% schema coverage, rich annotations, and no output schema, the description is largely complete: it names the resource, accepted identifier forms, and return contents. It could add a note about cursor-based pagination, but the schema already covers that parameter.

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 both `identifier` and `cursor` are already fully documented in the schema. The description restates the accepted identifier formats (URL, public ID, URN), which duplicates schema content without adding new semantics. Baseline 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 description states a specific verb (Get) and resource (a person's recent LinkedIn posts), and uses "person's" to implicitly distinguish from the company-posts sibling. However, it does not explicitly differentiate from other person-focused tools like linkedin_get_profile or linkedin_get_connections.

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 when-to-use guidance is provided. The description never states conditions for choosing this tool over alternatives like linkedin_get_company_posts, linkedin_get_profile, or linkedin_search_people, nor does it mention any exclusions or 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds a genuine behavioral constraint beyond that: the ownership requirement that silently fails for third-party posts. It omits any note on rate limits, latency, or data freshness.

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 tight sentences, front-loaded with the capability and then the constraint. Every clause carries information; nothing is padded.

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, enumerating the returned metrics in the description is valuable and largely compensates. The main remaining gap is that the demographics breakdown is only implied by the parameter name, but the schema already explains it, so the definition is nearly 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%, and the schema fully documents both the accepted post identifier formats and the include_demographics flag. The description adds no parameter-level detail, so the baseline 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?

States a specific verb (Returns) plus resource (engagement metrics for one of your own LinkedIn posts) and enumerates the exact metric set, which cleanly distinguishes it from siblings like linkedin_get_post_comments, linkedin_get_post_reactions, and linkedin_get_my_engagement.

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?

Clearly bounds when the tool applies: only posts authored by the connected account, with an explicit exclusion ('analytics for other users' posts are not available'). It does not name an alternative tool for the excluded case, so it stops 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the return shape (comment text, commenter profile, timestamp) and a non-obvious identifier hazard about ugcPost/share URLs.

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 sentences, front-loaded with the purpose, then inputs, then returns, then the edge-case caveat. Every sentence carries distinct information and nothing is repeated from 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?

With no output schema, the description helpfully states what is returned, and the cursor/pagination parameter is documented in the schema. The remaining gap is disambiguation from linkedin_get_nested_comments, which an agent choosing among comment-related siblings would want.

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%, so the baseline is 3, but the description adds meaning the schema does not: it explains the provenance of activityUrn (from linkedin_get_person_posts) and warns that the number inside a ugcPost/share URL is not an activity number. That materially reduces misuse of the identifier 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?

States a specific verb+resource ('Get comments on a LinkedIn post') and names the source tool for the primary identifier, so an agent can tell it apart from most siblings. However, the close sibling linkedin_get_nested_comments is never mentioned, leaving ambiguity about top-level vs. nested reply comments.

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?

Gives explicit input-selection guidance: pass activityUrn from linkedin_get_person_posts, or fall back to postUrl when the URN is unavailable. It also warns against constructing an activity URN from ugcPost/share URLs, which is genuinely actionable. It does not, though, say when to prefer this tool over linkedin_get_nested_comments.

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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: comment-mode reactions require a connected LinkedIn account, and it enumerates the reaction types returned. It doesn't mention rate limits or cursor exhaustion behavior, but that is a minor 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?

Front-loaded with the core purpose, then parameter sourcing, then return shape. Four sentences with little waste; the parenthetical sourcing notes are dense but informational rather than padding.

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

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

With no output schema, the description carries the burden of explaining returns and does so by naming reactor profiles and the reaction-type set. Combined with the schema's cursor pagination documentation, an agent has enough to call this correctly; only edge-case behavior (e.g. empty results, pagination termination) is unaddressed.

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% and the schema already documents provenance for each parameter (cursor, postUrl preferred-unless, commentId optionality, activityUrn preference). The description largely restates this, adding only the note that commentId works for your own comments. Baseline 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?

States a specific verb and resource ('Get reactions on a LinkedIn post or on a specific comment') and immediately distinguishes the two modes of operation. An agent can tell this apart from linkedin_get_post_comments or linkedin_react_to_post without opening any other schema.

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?

Explicitly routes the agent: supply activityUrn from linkedin_get_person_posts or a post URL, and pass commentId only when comment reactions are wanted, sourced from linkedin_get_post_comments or linkedin_get_nested_comments. It does not say when to prefer this over linkedin_get_my_engagement or how it relates to linkedin_get_post_analytics, so it stops short of full when/when-not coverage.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered. The description adds nothing beyond that: no note on auth/credits, rate limits, failure modes for invalid or private identifiers, or return shape.

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

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

One sentence, front-loaded with the verb and resource, zero filler. Nothing in it is wasted.

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

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

There is no output schema, and the description says nothing about what a profile response contains or what happens for unresolved identifiers. For a 2-param read tool with a fully documented schema it is adequate, but the return-value gap leaves it short of 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 both parameters are already documented with examples, including the boolean's default and behavior. The description's restatement of the identifier forms adds only marginal redundancy, which is the baseline 3 case.

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 ('Get a LinkedIn person profile') and enumerates the accepted identifier forms (URL, slug, URN). It is distinct from bulk siblings such as linkedin_bulk_get_profiles and from linkedin_get_company, though it never names them explicitly.

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

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

No when-to-use guidance, no prerequisites, and no routing to alternatives like linkedin_bulk_get_profiles, linkedin_search_people, or linkedin_get_connections. An agent must infer the single-profile scope from the tool name alone.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavioral context: the Premium gating with its degraded output, pagination via nextStart, and that some entries are aggregated with no profile URN. These are exactly the traits an agent needs before calling.

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 tight sentences, front-loaded with purpose, then entitlement caveat, then pagination and data-shape notes. No filler; every sentence 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?

No output schema exists, yet the description conveys return shape (viewer entries, aggregated non-URN entries) and pagination mechanics, plus the Premium failure mode. Nothing essential is missing for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the round-trip pattern (use nextStart from a prior response as start), which is operational guidance the schema only hints at.

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+resource: returns recent viewers of your own LinkedIn profile, and names the exact surface ("Who viewed your profile"). This is clearly distinguishable from sibling linkedin_get_profile (own profile data) and linkedin_get_shared_connections.

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?

Gives clear context: it is a Premium feature on the connected account, and without Premium LinkedIn returns blurred or empty results. It also explains the pagination workflow. It does not name an alternative tool for non-Premium scenarios, so it stops short of 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds that results are paginated via cursor and that the identifier can be a URL, public ID, or URN, which is useful behavioral context beyond the annotations, though it does not cover auth needs or rate limits.

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 adds a use case, accepted identifier formats, and pagination note. Every sentence is informative and none is wasted.

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

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

Given the low complexity (2 parameters, no nested objects, no output schema), the description provides everything an agent needs: what is returned, how to identify the target, and that results are paginated. The annotations cover the safety profile, so 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?

Schema description coverage is 100%, so both parameters are fully documented in the schema. The description repeats the identifier formats and mentions pagination, but adds no meaning beyond what the schema already provides. A 3 is the baseline when the schema does the heavy lifting.

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 (List) and resource (mutual/shared connections between you and a target profile), and clarifies the scope as people in your 1st-degree network also connected to the target. This clearly distinguishes it from sibling tools like linkedin_get_connections, which lists only your own connections.

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

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

It gives a clear use case ('Usable for finding who can give a warm introduction') which implies when to use it. However, it does not explicitly name alternatives or state when not to use it, 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?

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds cursor-based pagination behavior, which is genuinely beyond the structured fields, though it omits details like page-size behavior beyond the schema.

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 sentences, front-loaded with purpose, then direction semantics, then pagination. Every sentence carries information and none is redundant padding.

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 list tool with full annotations, 100% schema coverage, and no output schema, the description covers purpose, direction, and pagination adequately. It could note the default sort/order of pending requests, but nothing required for correct 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?

Schema description coverage is 100% with an enum on direction, so the schema already documents all three parameters thoroughly. The description restates the direction semantics without adding syntax or format detail beyond what the schema provides, matching the baseline of 3.

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 (List) and resource (pending LinkedIn connection requests) with clear scope. This distinguishes it from siblings like linkedin_get_connections (existing connections) and linkedin_manage_connection_request (mutating a request).

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 direction explanation implies when to use each mode, which is helpful usage context. However, it never states when to choose this tool over siblings such as linkedin_manage_connection_request or linkedin_get_connections, so the routing guidance is only implicit.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior the annotations do not: page-based result delivery, the has_more/next_cursor contract, and the fact that participant search scans up to 1250 recent conversations rather than searching exhaustively.

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?

Four compact sentences ordered purpose-first, then return payload, then the participant option, then pagination mechanics. Every sentence carries information, though the return-field enumeration is the kind of detail that could be trimmed if a further sentence were needed elsewhere.

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 correctly takes on the burden of naming the returned fields, and it fully explains the pagination loop an agent must implement to retrieve all results. For a read-only listing tool with six optional parameters, nothing essential to correct 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?

Schema description coverage is 100%, so all six parameters are already documented in the schema, and the description's parameter content (participant lookup, cursor continuation) largely restates it. The one addition, the 1250-conversation scan ceiling for participant lookup, also appears in the schema, so no real value is added beyond the structured fields.

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

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

The opening sentence states a specific verb and resource ("List your LinkedIn DM conversations (inbox)") and enumerates the returned fields, which is far more than a restatement of the title. It does not explicitly name or route away from the neighboring linkedin_get_conversation_messages tool, so the sibling distinction is left to inference.

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

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

Usage is implied rather than stated: the participant parameter is framed as an optional lookup path and pagination continuation is spelled out ("call again with the same arguments and cursor set to next_cursor"). There is no explicit when-to-use-this vs. when-to-use-an-alternative guidance, and no mention of when to prefer this over linkedin_get_conversation_messages.

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 cover safety posture (readOnly=false, destructive=false, idempotent=false, openWorld=true), and the description adds real value beyond them: the shared_secret prerequisite differs by action (required for accept/decline, not needed for withdraw) and withdraw is described as cancelling a pending invitation. It omits irreversibility of accept/decline and any rate-limit or error behavior, keeping it short of a 5.

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 compact sentences, front-loaded with the prerequisite list tool and then branching cleanly by direction. Every clause carries operational information; only the generic 'Manage' opening is filler.

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

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

For a mutation tool with no output schema, the definition supplies the prerequisite call, the per-action secret requirement, and the direction-to-action mapping. Minor gaps remain around failure modes (invalid/expired secret, wrong direction for an action) and return behavior, but an agent has enough to call it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters including the enum and the shared_secret requirement. The description restates this mapping rather than adding syntax, format, or edge-case meaning, so the baseline of 3 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 names the resource (a LinkedIn connection request) and enumerates the exact operations per direction (accept/decline for received, withdraw for sent), which lets an agent distinguish it from siblings like linkedin_send_connection_request and linkedin_list_connection_requests. The only weakness is the generic lead verb 'Manage', but the body immediately disambiguates.

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 explicitly conditions each action on the request's direction and identifies linkedin_list_connection_requests as the source of both the request and the shared_secret. There is no explicit 'when not to use' statement (e.g., that other actions are impossible), but the routing 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 declare readOnlyHint=false, destructiveHint=false and idempotentHint=true, so safety is covered structurally. The description adds real value beyond that by naming the external side effect (the unread badge on LinkedIn) and clarifying the read-vs-mark distinction. It stops short of mentioning rate limits or whether re-marking an already-read chat is a no-op (implied by idempotentHint only).

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 sentences, front-loaded with the action and effect, then the two most likely agent errors (assuming a read clears it, and where to find chat_id). No 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 single-parameter mutation with no output schema, the description covers action, side effect, the key misconception to avoid, and the source of the required ID. An agent can invoke this correctly with no further information.

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% for the single chat_id parameter, so the baseline is 3. The description adds provenance the schema does not: it tells the agent to obtain chat_id from linkedin_list_conversations, which is actionable information beyond the field's type 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?

States a specific verb+resource ('Mark a LinkedIn conversation as read') plus the observable effect ('clearing its unread badge'). This cleanly separates it from the adjacent read-only sibling linkedin_get_conversation_messages, which an agent could otherwise confuse with it.

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?

Gives explicit when-to-use context: reading messages via linkedin_get_conversation_messages does NOT clear unread state, so this tool is required for that outcome. It also names linkedin_list_conversations as the source of the chat_id, so the agent knows the prerequisite call.

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=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false, so the mutation and non-idempotence profile is covered. The description adds no auth, rate-limit, or reaction-toggle semantics beyond restating the reaction options.

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

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

Two short sentences, front-loaded with the action and its variants, with zero filler. Appropriately sized for a simple engagement 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 low-complexity mutation with no output schema and fully documented parameters, the description covers the essentials. A note on the non-idempotent reaction behavior would have completed it.

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

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

Schema description coverage is 100%, including the post_id/post_url requirement and the comment_id optionality, so the baseline is 3. The description adds nothing about parameter usage beyond echoing the enum values already 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?

States a specific verb (react) and resource (LinkedIn post) and enumerates the valid reaction types. It does not explicitly contrast itself with siblings like linkedin_comment_on_post or linkedin_create_post, so it falls 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?

"The lowest-friction engagement action" implies this is the lightweight alternative to commenting or posting, but it never names those alternatives or states exclusions. Usage is only implied, not spelled out.

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, idempotent, open-world behavior, so the safety profile is covered. The description adds genuinely useful traits beyond that: the automatic resolution of a free-text location to a LinkedIn region, the set of fields each posting carries, and the cursor-based paging mechanism.

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?

Four short sentences, front-loaded with the core action and return shape, with usage and pagination last. Tight overall, though the location-resolution and cursor sentences duplicate schema 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?

There is no output schema, yet the description enumerates the returned posting fields, so an agent knows what it will get back. All three optional parameters are covered and pagination is explained, leaving no practical gap for invoking the 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?

Schema description coverage is 100%, so all three parameters are fully documented in the schema. The description's mentions of location resolution and cursor paging restate what the schema already says rather than adding syntax, defaults, or 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?

States a specific verb and resource ('Search open LinkedIn job postings') plus the two filtering dimensions, which cleanly separates it from linkedin_search_people and linkedin_search_sales_navigator. An agent can select it without opening the schema.

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?

'Useful for sourcing open roles or tracking hiring activity in a market' gives clear usage context, but there is no explicit when-not guidance or named alternative among the many sibling search tools. It stops short of routing the agent between 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?

Annotations already declare readOnly/idempotent/openWorld, so the safety profile is covered. The description adds genuinely non-obvious behavior: the exact return fields, that text filter values are auto-resolved to LinkedIn IDs, and that total_count can be null when LinkedIn doesn't report it. Auth/rate-limit constraints are absent, keeping it from a 5.

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?

Four sentences, front-loaded with purpose and input modes, followed by return shape and pagination. Every sentence carries information an agent needs; nothing is redundant with the name or title.

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 listing returned fields (name, headline, location, profile URL, network distance), explaining total_count's nullable semantics, and covering pagination. An agent has everything needed to call and consume the result 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 coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema by explaining that text filter values (location, industry) are resolved to LinkedIn IDs automatically and by clarifying total_count/cursor semantics for pagination.

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+resource ("Search LinkedIn for people") and immediately names the two input modes (keywords/filters vs. a pasted search URL). This distinguishes it from sibling searches such as linkedin_search_jobs and linkedin_search_sales_navigator, which target different resource types.

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?

Explains the two invocation paths and notes that url is mutually exclusive with keywords/filters, plus tells the agent to use cursor for more results. It stops short of saying when to prefer this people search over linkedin_search_sales_navigator or linkedin_get_connections, so it's clear context without explicit 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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuine behavioral context beyond them: the subscription prerequisite, that text filters are auto-resolved to LinkedIn IDs, and that results carry fields (open profile status, premium status, tenure) that classic search does not return.

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?

Four sentences, front-loaded with purpose before the caveats, and each sentence carries real information (search modes, richer output, subscription requirement, ID resolution). The trailing 'and more' is the only mildly wasteful phrase.

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, all-optional search tool with no output schema, the description covers the prerequisite, both input modes, and the shape of the returned data well enough to call it correctly. It could say slightly more about pagination behavior or result limits, but the cursor semantics are already in the 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 100%, so the schema already documents every parameter, including the 'resolved to LinkedIn IDs automatically' note for function/industry/location. The description's ID-resolution sentence restates that rather than extending it, so this sits at the baseline for a fully documented 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 names a specific verb and resource ('Search LinkedIn Sales Navigator for people') and explicitly contrasts the result set with 'classic search,' which routes the agent away from the sibling linkedin_search_people. It also states the two distinct input modes (keywords/filters vs. a pasted search URL), so the tool's identity is unambiguous.

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

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

It gives a real usage gate ('Requires a Sales Navigator subscription on the connected LinkedIn account') and notes the mutual exclusivity of url versus keywords/filters. What is missing is an explicit 'prefer this over linkedin_search_people when X' rule; the richer-results comparison implies it but leaves the selection slightly to inference.

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 readOnly=false, idempotent=false, openWorld=true, destructive=false, so the safety and mutation profile is covered. The description adds essentially nothing behavioral beyond that — it doesn't explain that the call is non-idempotent (repeat sends create duplicates), whether a note consumes connection-request quota, or what happens when a request is already pending. The identifier and 300-char details it does add are parameter-level, not behavioral.

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 sentences, front-loaded with the action and followed by input and optional-message constraints; nothing is padded. Slight redundancy with the schema's own parameter descriptions keeps it from a 5.

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 2-parameter mutation with no output schema, the essentials are covered, and the lack of return-value explanation is acceptable here. What's missing is guidance an agent needs before firing a non-idempotent, open-world write: no note on duplicate sends, quota/permission prerequisites, or how it relates to linkedin_manage_connection_request.

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 both parameters are fully documented in the schema, including the URL/slug/URN formats and the 300-character message limit. The description merely restates those same facts, adding no syntax, format, or edge-case meaning beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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?

Clear verb+resource ('Send a LinkedIn connection request to a person'), and it specifies the operation is a single-request send rather than a bulk or list operation. However, it does not differentiate itself from the sibling linkedin_manage_connection_request, which plausibly covers accept/withdraw/other request actions, leaving ambiguity an agent must resolve by schema inspection.

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

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

Usage is implied by the name and the identifier guidance, but there is no explicit when-to-use, no exclusions, and no routing to alternatives such as linkedin_manage_connection_request (for other request actions) or linkedin_send_message (for messaging existing connections). An agent gets context but no decision 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?

Annotations already declare it is a non-idempotent, open-world write (readOnlyHint=false, idempotentHint=false), so the safety profile is covered. The description adds genuinely useful behavior: InMail works for non-connections, and a new conversation returns a chat_id for later replies. Permissions and rate-limit behavior are 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?

Three short sentences, the core action front-loaded, and the return-value note placed last. Every sentence carries distinct information with no padding.

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 usefully discloses that a new conversation yields a chat_id. It covers the main call paths, though it omits permission requirements or error behavior for a write 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by framing chat_id and recipient_identifier as a reply-vs-new-conversation choice and tying InMail to the recipient path. It restates the mutual exclusivity the schema already documents, so it does not fully exceed the baseline.

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

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

States a specific verb+resource ('Send a LinkedIn message') and immediately branches into the two modes of operation (reply vs. new conversation), plus the InMail capability. No sibling tool sends messages, so the scope is unambiguous.

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?

Explains the two entry paths clearly: use chat_id to reply, recipient_identifier to start new, and InMail only for non-connections. It stops short of naming when to prefer this over e.g. linkedin_send_connection_request, but the in-tool routing is 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely useful behavioral context beyond that: it is an account-introspection call that reveals which premium products (Sales Navigator, Recruiter) are active, which directly gates whether sibling tools like linkedin_search_sales_navigator will function.

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 with no filler. The return payload is front-loaded and the usage rationale follows immediately; every clause carries 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?

There is no output schema, so the description must carry the return contract itself, and it does by listing the four returned data points. Combined with annotations covering safety, an agent has everything needed to invoke this correctly.

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

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

The tool takes zero parameters, which is the baseline-4 case. The description correctly reflects this by describing no inputs and focusing entirely on what the call returns.

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 precise verb+resource ('Returns information about the connected LinkedIn account') and enumerates the exact fields returned: display name, public profile URL, LinkedIn URN, and active premium features. This is clearly distinguishable from profile-fetching siblings, which target other users rather than 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?

Explicitly says to use it 'before choosing search or messaging strategies' to understand available capabilities, giving a concrete decision context. It stops short of naming specific alternative tools or stating when not to call it, 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?

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false, idempotentHint=false). The description adds no behavioral detail beyond that – nothing about what happens after submission, whether a reply is expected, or delivery timing. With annotations carrying the safety burden, a 3 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?

Two sentences, front-loaded with the core action and then the use cases. There is mild redundancy between "send feedback..." and "Use this to tell us...", but nothing is wasted and the intent is immediately clear.

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-shot submission tool with full schema coverage and a complete annotation set, the description is sufficient; no output schema is needed since a feedback send has no meaningful return contract. It could mention that submissions are one-way, but 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?

Schema description coverage is 100%, so the schema fully documents the type enum, message, and nested context object. The description adds no parameter-level meaning (e.g., how much detail the context fields need or which fields pair with which type), so the baseline 3 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?

States a specific verb (send) plus resource (feedback) and the recipient (LinkMCP team), then enumerates the concrete payloads (feature requests, bug reports, help requests). It is unmistakably distinct from every LinkedIn sibling, which all operate on LinkedIn data rather than contacting the team.

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?

"Use this to tell us what is working well, what could be improved, to request new features, or to ask for help" gives clear positive-use context that maps to the enum types. It does not state when-not to use it or name any alternative, but the tool's role is unique among the siblings so ambiguity is low.

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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description earns credit by disclosing the return taxonomy (valid/invalid/catch-all/unknown) and MX provider details, which no structured field provides since there is no output schema; it stops short of cost, quota, or rate-limit context.

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 tight sentences: what it does and returns, then when to use it. No filler, and the purpose is front-loaded ahead of the usage context.

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 tool with no output schema, the description responsibly enumerates the possible return statuses and the supplementary MX data, so an agent knows what to expect. Missing only operational details such as rate limits, cost, or latency expectations.

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% for the single parameter, which already carries its own example and description. The tool description adds no syntax, format, or normalization guidance beyond what the schema states, so the baseline 3 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?

States a specific verb+resource ('Validate an email address for deliverability') and names the exact outcome space (valid/invalid/catch-all/unknown plus MX details). It is clearly distinguishable from sibling 'find_email', which locates rather than evaluates addresses.

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?

Explicitly says when to use it: verifying addresses from a CRM, lists, or other sources before sending outreach. It gives a clear triggering context but never names an alternative tool or a when-not-to-use condition relative to siblings like find_email or send_message.

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