Reach MCP — LinkedIn for AI agents

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the core behavioral profile is covered. The description adds the constraint that the request must be 'pending' and 'received', but does not disclose additional behavioral details such as what happens if the invitation is already accepted or rate-limit implications.

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

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

A single concise sentence that fully describes the tool's core purpose with no filler, front-loaded with the action on the resource.

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 accept-invitation tool, the description, combined with comprehensive schema documentation, an output schema, and annotations, gives an agent sufficient context to invoke the tool correctly. Minor gap: no explicit note about accepting only invitations in 'pending' status, which is implied but not stated as a precondition.

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 all parameters are already well-documented in the schema. The tool description adds no parameter-level semantics, which is acceptable given the schema carries the full burden.

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

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

The description states a specific action ('Accept') on a specific resource ('pending received connection request'), and clearly differentiates from siblings like decline_invitation, list_received_invitations, and invitation_status. An agent can immediately understand what the tool does.

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 when to use the tool: when there is a pending received connection request to accept. It does not explicitly say when not to use it or name alternatives, but the context is clear enough given the sibling tool names.

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 provide readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the bar for additional disclosure is lower. The description contributes the reversible-toggle nuance (archive=false to unarchive), which is beyond the annotations. It does not disclose permission requirements, rate limits, or state-dependent behavior, but the annotation coverage keeps this at an acceptable mid-level.

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 concise, front-loaded sentences cover the operation, the toggle behavior, and where the ID comes from. No redundant filler or restatement of schema properties that are already fully described.

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 4-parameter toggle with a full output schema and rich annotations, the description communicates the core reversibility and the source of the thread ID. It lacks a worked example or edge-case notes, but the tool's low complexity and the presence of the output schema make this adequately complete.

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

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

Schema description coverage is 100%, so all four parameters are already adequately documented. The description repeats the schema's meaning by saying archive=false reverses the action and conversation_linkedin_id comes from list_conversations, but it adds little beyond the schema, so the baseline score 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?

Description clearly states the verb and resource ('Archive or unarchive a LinkedIn conversation') and distinguishes the operation in principle from siblings like delete_conversation and star_conversation. It does not explicitly name those alternatives, so it falls just short of full 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 description offers operational guidance: set archive=false to unarchive and source conversation_linkedin_id from list_conversations. It never says when archiving should be chosen over deleting, starring, or other conversation actions, leaving usage timing implied rather than explicit.

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

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

Annotations already mark readOnlyHint=false and idempotentHint=false, so the mutating nature is known. The description adds useful auth context by saying the action happens 'on behalf of the connected account,' but it does not disclose public visibility, rate limits, or other side effects beyond the post being created.

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

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

The description is a single sentence with no filler, opens immediately with the action, and contains exactly the necessary components: action, target, and actor. It earns its place without redundancy.

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

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

With full parameter documentation, an output schema, and annotations present, the description provides enough operational context for a straightforward posting tool. The only slight gap is not explicitly routing replies to an existing comment toward reply_comment, but that is more of a usage-guideline concern.

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 parameters are already fully documented. The description does not add parameter-specific meaning beyond identifying the target as a LinkedIn post and the acting account, which is the expected baseline for complete schema coverage.

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

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

The description uses a specific verb and target: 'Post a comment on a LinkedIn post,' and names the acting identity ('on behalf of the connected account'). It clearly describes the action, though it does not explicitly distinguish this from the sibling reply_comment beyond the word 'post.'

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

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

The description gives no guidance on when to use this tool versus alternatives such as reply_comment, like_post, or send_message. It does not mention exclusions or prerequisites, so the agent must infer usage from the tool name and target.

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 establish that this is a non-read, non-destructive, non-idempotent action. The description adds a meaningful behavioral nuance—message length is capped at 300 chars on premium and 200 otherwise—which is not captured in the schema. It does not disclose rate limits or account-level requirements, but the added cap detail earns a mid-score.

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 focused sentences with zero filler. The core action is front-loaded, and the optional-message constraint is stated compactly. 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?

Given a fully documented schema, an output schema, and relevant annotations, the description is sufficient for correct invocation. It covers the primary action and message constraint; any additional details like authentication or rate limits would be nice but are not essential for 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 description coverage is 100%, so the schema already documents all four parameters, including the idempotency_key semantics. The description adds only the message cap detail, which is useful but not necessary for parameter understanding.

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: 'Send a connection request to a LinkedIn member.' This clearly differentiates it from sibling invitation-management tools like accept_invitation, decline_invitation, and withdraw_invitation, which represent different stages of the invitation lifecycle.

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

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

The description gives clear context: use this when you want to initiate a connection request to a LinkedIn member. It does not explicitly contrast with accepting or declining invitations, but the wording is unambiguous enough that a tool-selecting agent would not confuse it with the invite-management siblings.

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

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

Annotations already indicate this is a write operation (readOnlyHint=false, idempotentHint=false), so the description doesn't need to restate that. It adds useful downstream context about the identifierUrn, but does not disclose additional behavioral traits such as side effects, rate limits, or asset requirements. The return value is likely already captured by the output schema, so limited extra credit is given.

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 with no filler. The action is stated first, the output and downstream use come second, and the special parameter guidance is last. 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 tool with an output schema, 100% parameter coverage, and three required parameters, this description is complete. It tells the agent what the tool creates, what to pass in, what to do with the result, and where to source the author URN. No critical operational detail is missing.

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

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

The schema has 100% coverage, but the author_urn schema description is misleading ('Only messages from this author URN'). The tool description corrects this by explaining that author_urn is the connected account's urn:li:fsd_profile URN obtained from get_me. It also clarifies that media_urns are digitalmediaAsset URNs, adding real semantic value beyond the schema.

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

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

The description clearly states the action ('Create a LinkedIn multi-photo object'), the input (a list of digitalmediaAsset URNs), and the output (an identifierUrn to pass to create_post). It also differentiates this from the sibling create_post tool by positioning its output as a prerequisite for create_post.

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

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

It provides clear pipeline context: the returned identifierUrn is meant to be passed to create_post, and author_urn should come from get_me. It stops short of explicitly saying when not to use it or naming alternative paths, so it misses the explicit exclusion part.

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?

It discloses that the call either publishes immediately or schedules, and explains the media URN format constraints, which adds behavioral detail beyond the annotations. It stops short of discussing permissions, rate limits, or post visibility effects, but the readOnlyHint=false annotation already flags that this mutates external state.

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 three sentences with the core action front-loaded and every sentence contributing useful specifics (media URN types, scheduling behavior). No filler or redundant restating of parameter names.

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 rich 100%-coverage schema and existing output schema, the description covers the important non-obvious choices: media URN sourcing and schedule vs. publish-now. It does not explicitly mention the upload_media_from_url prerequisite for a brand-new asset, but the reference to create_multi_photo partially covers the media workflow.

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

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

With 100% schema description coverage, the baseline is 3, and the description adds value by clarifying the exact accepted media_urn formats (digitalmediaAsset vs fsd_multiPhoto) and how scheduled_at toggles scheduling. This complements rather than repeats the schema.

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

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

The description uses a specific verb pair ('Create or schedule') with a clear object ('a LinkedIn post') and immediately clarifies the optional media attachment. It also differentiates itself from media-creation siblings by referencing create_multi_photo as the source of multi-image URNs.

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

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

The description gives concrete usage context: single vs. multiple image URNs, scheduling via scheduled_at, and immediate publishing when omitted. It could be stronger by naming alternatives like update_scheduled_post, but the workflow guidance is clear enough for correct invocation.

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

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

Beyond annotations, it discloses the one-time signing secret, the exact Reach-Signature header format, the supported event list, the account_ids omission behavior, and the https-only requirement. These are non-obvious side effects and security-critical details that substantially exceed the annotations.

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

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

The description is front-loaded with the core purpose and follows with dense, high-value specifics in short sentences. There is no filler or repetition of schema fields.

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

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

An output schema exists, so return values are already specified; the description covers the remaining context an agent needs to call it correctly: event selection, subscription scope, signature verification, and one-time secret handling. The definition is effectively self-contained.

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 goes further by enumerating the exact event types, clarifying that omitting account_ids subscribes to every account, and stating https-only. It does not need to revisit already well-documented schema 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 description uses the specific action 'Register a URL to be called when something happens on LinkedIn', clearly identifying webhook endpoint creation. This distinguishes it from sibling tools like list/update/delete/test_webhook_endpoint without ambiguity.

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

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

It gives a clear motivating use case: enabling an agent or n8n/Make workflow to react to events instead of polling. However, it does not explicitly state when not to use it or name alternatives such as list_webhook_endpoints or update_webhook_endpoint.

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 conveys the state-changing nature ('decline/ignore'), and the annotations already supply destructive/idempotent hints. It adds scope (received vs sent) but no additional side-effect or safety details.

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?

Single clear sentence, no filler, front-loaded with the action and target.

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 complete schema coverage, idempotency and destructive annotations, and clear target scope ('pending received' vs sent), an agent has enough contextual clues to call it correctly, though it doesn't mention sibling alternatives.

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?

All three parameters are fully documented in the input schema (100% coverage), so the description adds no parameter-specific meaning, but no gap exists.

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: decline/ignore a pending received connection request. The 'pending received' qualifier distinguishes it from sent-invitation tools, though it does not explicitly name sibling alternatives.

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?

Provides clear context ('pending received connection request') so an agent knows it applies to incoming, not sent, invitations. However, it gives no explicit 'when to use vs. not use' guidance or reference to alternatives like accept_invitation or withdraw_invitation.

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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false, covering safety and idempotency. Beyond that, the description adds a specific behavioral detail not captured by annotations: 'Also clears invitation references before deletion.' This provides extra context about what gets cleaned up, which is valuable for an agent reasoning about side effects.

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

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

The description is two short sentences with zero filler. It front-loads the core action and then adds the notable side effect. There is no redundancy or wasted wording, making it easy for an agent to parse quickly.

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

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

Given the presence of an output schema, comprehensive parameter descriptions, and informative annotations, the description is complete enough for an agent to invoke the tool correctly. It covers the primary action and the key side effect; the permanent destructive nature is implied by destructiveHint. No additional context is necessary for safe use.

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 (account_id and idempotency_key) are already well documented in the input schema. The tool description does not add any parameter-specific guidance beyond what the schema provides. This meets the baseline of 3 for tools where the schema carries the descriptive load.

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

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

The description clearly states a specific verb and resource: 'Delete a LinkedIn account by account_id.' It also mentions a secondary behavior (clearing invitation references), which distinguishes it from other deletion tools like delete_conversation or remove_connection. The purpose is unambiguous and immediately actionable.

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

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

The description gives clear context that this tool deletes a LinkedIn account, so an agent knows when to use it for full account removal. However, it does not explicitly mention alternatives or exclusions (e.g., 'for deleting a conversation, use delete_conversation instead'). The guidance is implied but not stated, and with many sibling deletion tools, a brief note on differentiation would improve selection accuracy.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds the 'permanently' qualifier, reinforcing irreversibility, but it does not disclose other behavioral details such as whether messages within the conversation are also deleted or whether the action affects other participants. This is acceptable but not rich beyond the annotations.

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

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

The description is two short sentences with no filler. The primary action is front-loaded, and the clarification about conversation_linkedin_id directly supports correct invocation. 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 delete operation with only three parameters, the description combined with the detailed input schema and annotations is sufficient. The tool's destructive and idempotent nature is captured, all parameters are documented, and the output schema covers return expectations. No important calling context appears 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 account_id, idempotency_key, and conversation_linkedin_id. The description repeats that conversation_linkedin_id comes from list_conversations, which is already in the schema property description. No additional parameter meaning is added beyond the schema.

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

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

The description states a specific verb and resource: 'Permanently delete a LinkedIn conversation.' It is clear and unambiguous about the operation. However, it does not explicitly distinguish itself from sibling tools like archive_conversation, so the differentiation is implicit rather than explicit.

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 offers no guidance on when to use this tool versus alternatives such as archive_conversation or star_conversation. It does not state when deletion is appropriate or warn against using it when archiving would suffice. The destructive nature is implied by 'permanently delete' but no explicit usage direction is provided.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description's 'Delete' is consistent with that. It adds little behavioral context beyond the annotation, though the 'scheduled' qualifier clarifies this operates on scheduled, not published, posts and points to list_scheduled_posts as the source. No contradiction.

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

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

Two short sentences with a clear front-loaded action. No filler or repetition that would burden the agent.

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

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

For a simple, well-schema'd tool with annotations and an output schema, this is sufficient: required params, source of post_urn, and destructive nature are all evident. An agent can select and invoke it without missing 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%, so the schema fully documents all three parameters. The description mostly repeats the schema's provenance for post_urn and adds only a small example format (urn:li:ugcPost:…), which is useful but not substantial. It adds no information about account_id or idempotency_key beyond 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?

Description opens with a specific verb+object ('Delete a scheduled LinkedIn post'), and the object type distinguishes it from sibling tools like update_scheduled_post, delete_conversation, and delete_account. It states exactly what resource is affected.

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

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

The description clearly conveys when to use it (when a scheduled post needs to be removed), but gives no explicit alternatives or exclusion criteria. It provides provenance for post_urn but does not mention update_scheduled_post for modifying rather than deleting. Usage is implied rather than explicitly contrasted.

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

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

The annotations already declare destructiveHint=true and idempotentHint=true, which the description does not contradict Section; the description does not add behavioral context beyond the fact that delivery history is deleted. There is no mention of consequences like irreversibility, permission requirements, or side effects on dependent resources. With annotations covering the safety profile, a 2 feels slightly low, but the description adds minimal behavioral detail (only the history deletion) beyond the hints, and since destructiveHint is already set, a 3 might be fair, but given the instruction to use full range and that the description does little to explain the impact, I'll assign 2 as the gap is notable.

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

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

The description is a single sentence that is concise and to the point. It could be seen as slightly terse, but it captures the essential action and scope. It earns a 4 for being efficiently written without extra fluff.

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

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

The tool is relatively simple with few parameters and an output schema, but it is a destructive operation. The description does not mention what happens in terms of reversibility or any special conditions (e.g., if the endpoint is in use). Given the presence of an output schema and complete parameter documentation, a 3 is appropriate; it is adequate but not rich.

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

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

The input schema covers both parameters with 100% coverage; the description does not add any parameter-specific details. However, the schema already names the 'endpoint_id' and explains the idempotency_key thoroughly. Since schema coverage is high, the baseline is 3, and no extra value is added by the description here.

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

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

The description clearly states the action (delete) and the resource (webhook endpoint), and explicitly mentions it also deletes the delivery history, which distinguishes it from other webhook operations like test_webhook_endpoint or update_webhook_endpoint. This is a specific and unambiguous purpose.

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

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

The description clearly indicates that deletion also removes delivery history, providing context on the scope of the operation. However, it doesn't explicitly contrast with alternatives (e.g., when to use update instead of delete), but the destructive nature and singular action make usage clear. Since there is no explicit 'when not to use', it scores 4 rather than 5.

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

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

Annotations already declare readOnlyHint=falseanding idempotentHint=true, so the description carries less burden. It adds the key behavioral distinction ('without connecting') and notes the unfollow behavior, which is useful. However, it doesn't mention idempotency or any side effects beyond the basic action, so it stops at adequate.

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

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

Two short sentences. The primary action is stated first, and the edge case (follow=false) is tied to the schema parameter without redundancy. Every word earns its place.

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

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

The description covers what the tool does and the one behavior flip (follow/unfollow). With an output schema present and detailed parameter descriptions in the schema, the description doesn't need to explain return values or every parameter. It is complete for an action with a small, clearly defined surface.

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 adds 'Set follow=false to unfollow', which slightly reinforces the parameter's meaning, but this is already fully described in the schema (`True to follow, False to unfollow`). No additional semantic value beyond the schema.

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

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

The description uses a specific verb ('Follow or unfollow') with a clear resource ('a LinkedIn member') and explicitly states the scope ('without connecting'). The 'without connecting' phrase distinguishes it from the sibling `connect` tool.

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

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

The phrase 'without connecting' directly signals when to use this tool instead of `connect` or `withdraw_invitation`. It doesn't enumerate explicit exclusions, but the primary alternative is clearly distinguished. A small deduction for not naming the sibling explicitly.

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, so the safety profile is covered. The description adds only that the result covers configuration and usage counters; it does not mention auth requirements or rate limits, but the annotation coverage lowers the burden. No contradiction with annotations.

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

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

One concise sentence that states the core action and data scope up front. There is no filler or repetition of the 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 a single well-documented parameter, an output schema, and full safety annotations, the definition gives an agent what it needs to call the tool correctly. It could be marginally stronger by explicitly routing mutations to update_account_quotas, but that is not required for 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% and the account_id parameter is already documented with its type and source ('from list_accounts'). The tool description adds no separate parameter detail, 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 a specific verb ('Get') and a concrete resource ('quotas configuration and usage counters') for a LinkedIn account. This clearly distinguishes it from siblings like update_account_quotas by read intent, even without naming the sibling.

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

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

The use case is implied by 'Get' and the account_id provenance note 'from list_accounts', but there is no explicit when-to-use statement or exclusion such as 'use update_account_quotas to change quotas.' An agent must infer the read-only workflow from the name and annotations.

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, and destructiveHint=false, covering safety. The description adds little behavioral detail beyond the schema, such as ordering or output shape, but there is no contradiction.

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

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

A single sentence front-loads the action and resource, then states filtering and pagination options with zero wasted words.

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

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

For a read-only, idempotent log-retrieval tool with a fully described schema and an output schema, the description covers the essential behavior. It does not explain when to choose this over get_account_request_logs_stats, but that is a minor gap.

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

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

All four parameters have schema descriptions, so the schema already explains limit, offset, request_type, and account_id. The description paraphrases filtering and pagination but does not meaningfully add beyond the structured definitions.

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 request logs for a LinkedIn account') and mentions optional filtering and pagination. It is clearly distinct from the sibling stats tool by focusing on raw logs, though it does not explicitly name the sibling.

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?

Clear usage context is given via optional request_type filtering and pagination. It does not explicitly state when to prefer this over the sibling stats tool, but the read-only log-fetching purpose is evident.

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, and destructiveHint=false, so the safety profile is fully covered. The description adds the aggregation behavior (grouping by day/week/month) and optional filters, which is useful. It does not disclose details like default date ranges or whether empty buckets are included, but the annotations carry the main behavioral burden.

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

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

A single, well-structured sentence that front-loads the core purpose and then lists the key options. No wasted words; every phrase 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 read-only aggregation tool with a 100%-covered schema and an output schema present, the description is nearly complete. It could explicitly mention the default date range (30 days ago to now) or the sibling raw-log tool, but those are minor gaps given the schema and annotations already provide the necessary context.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds the notion of aggregation and filtering but does not add meaning beyond what the schema provides. Baseline 3 is appropriate because 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 ('Get'), a specific resource ('aggregated request-log statistics for a LinkedIn account'), and the grouping dimensions ('day, week, or month') with optional filters. It clearly distinguishes this from the sibling get_account_request_logs, which presumably returns raw logs rather than aggregated statistics.

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 when to use this tool: when aggregated statistics are needed, as opposed to raw logs. It names the grouping options and filters, giving clear context. However, it does not explicitly state when not to use it or name the sibling alternative (get_account_request_logs) as the raw-log counterpart.

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

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

The annotations already declare read-only, idempotent, and non-destructive behavioraint. The description adds the proxy/cookie mechanism and output normalization, which is helpful, but does not mention failure modes like expired credentials or invalid account IDs.

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 compact sentence conveys endpoint, auth context, return type, and output compatibility without filler. The key action 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?

Given the output schema exists and this is a simple read operation, the description covers the essential context: what it calls, how it authenticates, and what it returns. Extra detail about auth expiry or error behavior would be nice but is not required.

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%: account_id has a clear description. The tool description adds that it acts 'on an account' and points to list_accounts as the source, but this is marginal beyond the schema.

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

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

The description states a specific action and target: call LinkedIn's /me endpoint through stored proxy/cookies and return the normalized profile. This clearly differentiates it from general scraping or listing tools.

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

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

It provides useful context—acting on a specific account via stored credentials and using account_id from list_accounts—but does not explicitly contrast with sibling tools like scrape_profile or profile_viewers. The usage situation is implied rather than stated.

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

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

Annotations already signal read-only, idempotent, non-destructive behaviortons. The description adds behavioral clarity by specifying the returned fields and the valid invitation_type values, which is useful context beyond the annotations. No contradiction with the annotations.

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

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

Two tightly written sentences that state the purpose and the key output fields. Every word earns its place, and the most important detail (read-only status check) is front-loaded in the verb 'Get'.

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-only status query with a clear schema, the description is mostly sufficient. It includes the output enum values and the object of the query/Tn. It does not explain possible edge cases or what happens if the member is not found, but the output schema likely covers return structure. Minor gap in missing routing guidance to list_sent_invitations/list_received_invitations for broader status queries.

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%, with both account_id and linkedin_id_or_url clearly described. The tool description adds no additional parameter meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Get') and clearly names the object: connection and invitation status between the connected account and a LinkedIn member. It also lists the key returned fields, making the purpose immediately understandable and distinct from broader listing tools.

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

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

No guidance is given on when to use this tool versus siblings like list_sent_invitations, list_received_invitations, or withdraw_invitation. There is no mention of prerequisites or scenarios where this tool is preferred, leaving the agent to infer its role from the name and description 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 readOnlyHint=false, idempotentHint=true, and destructiveHint=false, which covers the core safety profile. The description adds the 'on behalf of connected account' context and input format, but does not disclose anything beyond what annotations and schema already imply (e.g., whether unlike is possible, 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 two short sentences, each earning its place. The core action is front-loaded, and the input formats are specified in the very same sentence. No repetition or filler.

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

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

For a simple action that mutates a post like state, the description combines with a 100% documented schema and an output schema to cover everything an agent needs. The idempotency and safety profile are already in annotations. Nothing important is left unexplained.

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 includes the full meaning of both parameters. The description's mention of 'post URL, slug, or URN' restates what the schema already says for post_url_or_urn, so it adds no new semantic information.

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 ('Like'), resource ('LinkedIn post'), and scope ('on behalf of the connected account'), which clearly separates it from sibling tools like comment_post or send_message. It also covers the three accepted identifier formats (URL, slug, URN), leaving no ambiguity about what the tool targets.

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

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

The description makes it obvious when to use this tool — whenever the user wants to like a post. It gives concrete input guidance ('Pass the post URL, slug, or URN') but does not explicitly contrast with alternatives or state when not to use it, so it stops short of full sibling 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the behavioral detail about restricted keys returning only allowed account IDs, which is useful. No contradiction with annotations.

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

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

Two sentences, no filler, and the key scoping behavior is front-loaded. Every word earns its place.

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

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

For a zero-parameter read-only tool with an output schema present, the description is nearly complete. It explains the key restriction behavior, which is the main contextual nuance. It doesn't describe the output format, but the output schema covers that.

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

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

The tool has zero parameters, so there are no parameter semantics to clarify. The description correctly focuses on the output behavior instead. Baseline 4 for zero-param tools is appropriate.

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

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

The description clearly states the tool returns LinkedIn accounts accessible with the provided API key, and adds a scoping detail about restricted keys. This distinguishes it from sibling tools like get_me or list_connections, which target different resources.

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 when to use this tool: when you need to know which accounts are accessible with the API key. It doesn't explicitly name alternatives or exclusions, but the context of sibling tools and the clear resource scope make the usage context reasonably clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by specifying the data source ('Voyager dash connections') and pagination mechanism, plus a direct API equivalence, which are behavioral details not present in annotations. It does not contradict any annotation.

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

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

The description is a single sentence that packs in the core purpose, data source, pagination, and API equivalence without any fluff. It is front-loaded with the primary action and resource, and every phrase contributes to understanding. This is an exemplar of concise, efficient writing.

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

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

The tool has an output schema (which covers return values), annotations cover safety and idempotence, and the description covers purpose, source, and pagination. For a simple read-only list operation, this is everything an agent needs to select and invoke the tool correctly. No important behavioral or usage context is missing.

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

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

Schema description coverage is 100%, so the parameters (account_id, start, count) are already fully documented. The description only slightly enhances this by mentioning pagination with start/count, but it adds no new meaning beyond what the schema provides. The baseline of 3 is appropriate since the schema handles 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 a precise resource ('LinkedIn 1st-degree connections for an account'), which clearly distinguishes it from sibling tools like invitation lists or conversation lists. It also adds a clarifying source ('Voyager dash connections') and an API equivalent, removing ambiguity about what kind of data is returned.

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

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

The description gives clear context on what the tool does and mentions pagination behavior (start/count), but it does not explicitly state when to use it over alternatives or when not to use it. The purpose is straightforward enough that a user would not confuse it with siblings like list_sent_invitations, but the lack of explicit exclusions prevents a higher score.

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, and destructiveHint=false, so the core safety profile is covered. The description adds useful behavioral context beyond the annotations by naming the exact underlying endpoints and explaining that created_before controls legacy/unused paging; this is meaningful, even though it does not discuss authorization, rate limits, or response structure.

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

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

The description is a single, front-loaded sentence: it states the core action first, then compacts relevant implementation details into a short clause. There is no filler, and every segment—action, endpoint, paging hint, exact equivalent route—adds useful information without making the text bulky.

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

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

For a read-only tool with a clear schema, a complete output_schema, and no nested objects, the description provides enough context to guide correct invocation: it identifies the use case, the relevant conversation ID source, and the optional paging direction. It does not discuss ordering, default page size, or 'latest message first' behavior, but the output schema and annotations compensate for most of that.

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

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

The input schema already provides 100% descriptive coverage of all three parameters, including origin and type for account_id, conversation_linkedin_id, and created_before. The description adds little beyond restating created_before as 'paging' and echoing the endpoint pattern, so it stays at the schema-covered 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 first phrase is a specific verb+resource statement: 'List messages in a LinkedIn conversation,' making the function's purpose unmistakable. It also references the exact Voyager/Kanbox/GET endpoints and the optional 'created_before' paging, which differentiates it from sibling listing tools like list_conversations.

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 when to use it—when you need the messages of a specific LinkedIn conversation—and even mentions optional paging behavior. However, it does not explicitly distinguish when to prefer this tool over related sibling tools such as salesnav_list_thread_messages or react_message, nor does it document prerequisites or excluded cases.

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 establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral context beyond those hints: it reveals the underlying Voyager GraphQL route, the REST-alias, pagination with next_cursor, and the semantic meaning of returned IDs for cross-tool flows. It does not disclose rate limits or default ordering, but the annotation bar lowers the burden.

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 wasted words. The first sentence front-loads the action, resource, filters, and paging; the second compacts essential ID semantics without repeating schema descriptions. 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?

Given the rich annotations, complete input schema, and presence of an output schema, the description covers what an agent needs to invoke the tool successfully. It also supplies the cross-tool mapping for conversation_id and recipient_linkedin_id, which is critical context that no structured field provides.

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

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

The input schema already has 100% parameter coverage, so the baseline is 3. The description mostly restates filter and paging concepts already present in the schema and adds meaning to returned fields rather than the input parameters themselves. There is modest added value but no substantial new input-parameter semantics.

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

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

The description states a specific verb and resource ('List LinkedIn messenger conversations') plus the implementation context ('Voyager Messaging GraphQL') and the same as GET /api/linkedin/{account_id}/conversations. It also distinguishes from sibling tools like list_conversation_messages and salesnav_list_messaging_threads by framing this as the conversation-level listing with IDs meant for downstream message operations.

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

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

The description gives clear context for using the tool to list conversations and then explains how the returned IDs feed into fetching messages, replying, or sending a new message. It does not explicitly state when not to use it or name alternatives, so it falls short of a fully prescriptive usage guide.

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, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it lists pending invitations and includes the invitation_secret needed to accept them. This goes beyond the annotations by explaining what the returned data enables.

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 with no waste. The core purpose is front-loaded, and the parenthetical about invitation_secret adds valuable context without bloating the description.

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

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

The tool has an output schema, so return values need not be described. The description covers the essential purpose and the key behavioral detail (invitation_secret). It doesn't mention pagination, but the schema already documents count/start, 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 the schema already documents all three parameters. The description adds no parameter-specific meaning beyond what the schema provides, 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?

The description states a specific verb ('List'), a specific resource ('pending connection invitations received by the account'), and adds a key detail (the invitations include invitation_secret to accept them). This clearly distinguishes it from siblings like list_sent_invitations and accept_invitation.

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

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

The description implies the tool is for viewing received pending invitations, which is clear context. It doesn't explicitly state when not to use it or name alternatives like list_sent_invitations, but the phrase 'received by the account' and the sibling list make the usage context reasonably clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered. The description adds useful behavioral context: pagination ('paged'), the return fields, and the account scoping. It doesn't describe pagination mechanics (e.g., how to know when pages end), but the schema's start/count parameters plus the output schema cover the basics. No contradiction with annotations.

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

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

One sentence, front-loaded with the core action and resource, then the key return fields. No filler, no repetition of the schema. Every word earns its place.

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

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

For a read-only, idempotent list tool with a full output schema and 100% parameter coverage, the description is nearly complete. The only minor gap is that it doesn't explicitly state the pagination behavior beyond 'paged' (e.g., whether start is an offset into the full list or a cursor), but the schema's start/count descriptions cover the mechanics. An agent can call this tool correctly with the information given.

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. The description adds the account scoping ('for an account') and the return fields, but it doesn't add meaning beyond the schema for count/start. Baseline 3 is appropriate because the schema does the heavy lifting and the description doesn't need to compensate.

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'), a specific resource ('scheduled LinkedIn posts'), and a scope ('for an account, paged'). It also names the return fields (post URNs, text content, scheduled publish times), which distinguishes it from siblings like delete_scheduled_post and update_scheduled_post. The title 'List scheduled posts' reinforces the same meaning without adding ambiguity.

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

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

The description implies when to use it: when you need to list scheduled posts for an account, and the account_id parameter is explicitly tied to list_accounts, giving a clear prerequisite. It does not explicitly name alternatives or say when not to use it, but the sibling set makes the distinction fairly obvious (delete_scheduled_post, update_scheduled_post, create_post). A small gap: it doesn't mention that this is read-only vs. other mutation tools, but the annotations cover that.

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 convey read-only, idempotent, and non-destructive behavior. The description adds the 'pending and not yet accepted' filter, but does not disclose pagination behavior, ordering, or any account-authorization expectations beyond what the schema suggests.

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

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

The description is a single, front-loaded sentence with no filler. 'Pending' and 'not yet been accepted' are slightly redundant, but the sentence is still compact and immediately scannable.

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

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

Given the simple listing behavior, rich schema, and output schema present, the description covers the core context an agent needs. It does not mention exclusions or ordering, but those are not essential for correct invocation here.

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

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

The schema already documents all three parameters with descriptions and defaults, so the description does not need to repeat them. It adds no parameter-specific meaning beyond the overall endpoint purpose.

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 action ('List'), a clear object ('sent invitations'), and a precise state ('not yet been accepted'), making the tool's purpose immediately obvious. It also implicitly differentiates from received or already-accepted invitation tools.

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

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

The description communicates when the tool applies: when an agent needs pending invitations sent by the account. It does not explicitly name alternatives or state when to use a different endpoint, but the context is clear enough for basic selection.

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, and destructiveHint=false, making the safety profile clear. The description adds context about the event types and explicitly says 'Read-only', which aligns with annotations. However, it does not disclose other behavioral details like pagination, ordering, or response structure (though output schema likely covers this). The added event-type context is useful but not behavioral beyond safety.

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

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

The description is a single sentence with a colon and a parenthetical list of event types. It is front-loaded with the primary action ('List the webhooks registered for this user'). While the event enumeration is somewhat long, it is purposeful and not redundant. No wasted words, though the parentheticals add density. It earns a 4 for being appropriately sized and structured.

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

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

Given the tool's low complexity (no parameters, simple list operation) and the presence of an output schema, the description need not explain return values. It fully covers the purpose, scope ('for this user'), and event types. There are no obvious gaps in what an agent needs to invoke it correctly: the read-only nature is stated and annotations confirm safety. Complete for a zero-parameter tool.

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

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

The tool has zero parameters, and the schema coverage is trivially 100% (empty properties). Per the rubric, a zero-parameter tool gets a baseline of 4. The description adds no parameter information, which is correct since there are no parameters to explain. The description does not need to compensate for any schema gaps.

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

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

The description clearly states the tool lists webhook endpoints registered for the user, using a specific verb ('List') and resource ('webhooks'). It enumerates the event types that trigger the webhooks, distinguishing this from sibling tools like create_webhook_endpoint or update_webhook_endpoint. The purpose is unambiguous and distinct from all 47 sibling tools.

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

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

The description implies usage by stating 'List the webhooks registered for this user' but does not explicitly compare to alternatives or state when not to use it. There is no mention of why an agent might prefer this over other webhook-related tools (though no direct alternative exists for listing). The context is clear but exclusions are absent, so it falls at 'implied usage' rather than explicit 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 cover read-only, idempotent, non-destructive behavior. The description adds useful context beyond the annotations: it reveals the premium subscription requirement and that the result is limited to recent viewers. It does not contradict annotations and adds an external dependency the annotations do not capture.

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

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

The description is one concise sentence that states both the operation and a critical usage requirement. There is no filler or redundancy, and the main action 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?

Given the tool has only one parameter, an informative output schema, and strong annotations, the description is complete enough. It covers the operation outcome and the required product entitlement, so an agent has sufficient information to invoke the tool correctly.

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

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

The schema already documents account_id fully, including its type, required status, and source (list_accounts). The description adds no new parameter-level semantics, but because schema coverage is 100%, baseline 3 is appropriate and no compensation is needed.

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

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

The description states a clear verb ('Get') and resource ('the list of members who recently viewed the account's profile'). This is specific enough to distinguish the tool from siblings like list_connections or list_received_invitations, since it uniquely targets profile viewers.

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

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

The description gives one practical precondition—LinkedIn Premium—but provides no explicit guidance about when to use this tool versus alternatives or when not to use it. It implies the usage case through the purpose, but does not name sibling tools or exclusion conditions.

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

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

The annotations already declare readOnly, idempotent, and non-destructive behavior, so the description does not need to re-cover safety semantics. It adds useful behavioral context by describing the catalogue as the orchestration entry point and noting that include_instructions produces longer output. No contradiction with annotations.

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

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

The description is front-loaded with 'START HERE' and each sentence earns its place: what the catalogue is, what entries contain, when to use it, and how to drill into a single playbook. It is compact but very informative.

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 catalogue/routing tool with no required parameters, an output schema, and full annotations, this description is complete. It explains what the output represents, when to call it, and how to request specific playbook instructions; the output schema covers return-value details.

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

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

Schema description coverage is 100%, so the parameters are already well documented. The description adds some contextual value by saying 'Pass playbook_id to get one playbook's instructions and then follow them,' but this largely restates the schema meaning rather than introducing new parameter semantics.

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

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

The description clearly states what the tool returns: a catalogue of ready-made LinkedIn playbooks and their instructions. It explicitly frames this as the meta/entry-point tool rather than a raw endpoint, which distinguishes it from the many sibling tools in the list.

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

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

The description gives clear when-to-use guidance: call this first when the user asks what the server can do or when a request is vague, and pass playbook_id for one playbook's instructions. It does not explicitly state when not to use it in favor of a specific sibling tool, but its 'START HERE' directive provides strong practical routing context.

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 clearly states the write operation (add or remove reaction), explains how to toggle the behavior, and discloses a side effect (marking the conversation as read). Annotations already flag idempotency, so the description adds meaningful behavioral detail without contradiction.

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

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

The purpose is stated first and the supporting parameter guidance is brief and organized. It is not trimmed to one sentence but every clause adds practical value.

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

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

For a single-action mutation tool, it covers inputs, source of the key ID, and side effects. Missing explicit error/rate-limit info is not critical given annotations and 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?

Parameter descriptions in the schema are already detailed, and the tool description adds useful guidance on where message_urn comes from and how to remove a reaction. This goes slightly beyond the baseline for fully-schema-documented parameters.

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

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

The description states a specific verb and resource: 'Add or remove an emoji reaction on a LinkedIn message.' This clearly identifies the tool's function and distinguishes it from sibling conversation tools like archive_conversation or list_conversation_messages.

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

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

The description gives practical guidance by telling the agent that message_urn comes from list_conversation_messages and that setting react to false removes the reaction. It also notes the read side-effect when conversation_linkedin_id is passedhols, giving clear usage context without explicit exclusion of alternatives.

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

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

The description states that an existing 1st-degree connection is removed, which tells the agent what is destroyed. Annotations already declare destructiveHint=true, so the description adds only marginal value beyond what annotations provide; it does not mention permanence, notifications, or other side effects, but it does not contradict the annotations.

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

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

One short, front-loaded sentence with no filler. Every word contributes to the meaning, and the core action and target are presented immediately.

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 destructive action, the description combined with the full schema coverage, output schema, and annotations provides enough information for correct invocation. The only notable gap is the lack of explicit differentiation from invitation-related sibling tools, but this is minor given the clarity of 'existing 1st-degree connection.'

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 in the schema. The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Remove') and a precise resource ('existing 1st-degree connection'), which clearly distinguishes this tool from siblings like connect, withdraw_invitation, or decline_invitation. Even without additional wording, an agent can tell what action is being performed.

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

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

The phrase 'existing 1st-degree connection' implies the tool is for current connections, not pending invitations, but it does not explicitly state when to use it versus alternatives like withdraw_invitation. The usage context is implied rather than 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 indicate readOnlyHint=false, idempotentHint=false, but the description does not contradict them. It adds crucial context: the comment_urn is used directly as threadUrn, which implies the API will treat it as the thread identifier. It also implies a write operation by 'post a reply', which aligns with destructiveHint=false but not enough to flag. The description does not mention idempotency behavior, but that is covered by the idempotency_key parameter schema. No contradiction, and it adds value beyond annotations.

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

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

The description is a single informative sentence that front-loads the primary action and immediately provides the critical mapping instruction. Every word adds value; there is no fluff or repetition of schema details. This is appropriately concise.

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

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

The tool has an output schema, so return value details are covered there. The description covers the main purpose and the key parameter mapping, but it does not mention idempotency or any limitations beyond that. Given the complexity (only 4 params, no enums, simple operation), it is quite complete. However, a note about idempotency behavior might be useful, but the schema already explains that, so 4 is appropriate.

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 all parameters, including the idempotency_key's behavior in detail. The description adds extra meaning by clarifying that comment_urn is the comment_id from scrape_post and is used as threadUrn. This goes beyond the schema's simple 'URN of the comment' by specifying the source and direct usage, so it earns above 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 clearly states the action (post a reply), the resource (existing LinkedIn comment), and the direct parameter mapping (comment_id to comment_urn). It distinguishes from siblings like comment_post and send_message by specifying the target is a comment, not a post or message.

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

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

The description explicitly instructs to pass the comment_id returned by scrape_post as comment_urn, and states it is used directly as threadUrn. This gives precise when-to-use guidance and avoids ambiguity about which identifier to use. It does not explicitly say when not to use it, but the mapping instruction is strong enough.

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, and destructiveHint=false. The description adds critical behavioral details beyond these: the disambiguation return object ({needs_disambiguation:[...]}), boolean syntax support, exclusion objects, and the execute=true side effect of running the search and returning leads. These are genuinely useful and do not contradict the annotations.

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

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

The description is long but well-organized with labeled sections (RESOLUTION, BOOLEAN, EXCLUSION) and front-loads the core purpose. Each sentence adds new information without redundancy. It could be slightly tighter, but given the complexity of 30 parameters, the structure is efficient and scannable.

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

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

An output schema exists (indicated by 'Has output schema: true'), so return values are presumably documented. The description covers disambiguation behavior, resolution requirements, and the execute flag. It does not address edge cases like rate limits or authentication, but annotations cover safety, and the description is sufficient for an agent to call this correctly in most scenarios.

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% (all 30 parameters have descriptions), so the baseline is 3. However, the description goes far beyond the schema by explaining resolution rules (industry accepts ids or names, region needs account_id), boolean operators, exclusion object structure, and the account_id requirement for name-based resolution and execute=true. This is significant added value that the schema alone does not convey.

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 precise verb-object pair: 'Build a Sales Navigator people-search URL from structured lead-search filters.' It also distinguishes itself by listing the filters and the resolution behavior, making it clear this is the URL builder among the sibling tools (none of which construct search URLs).

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

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

The description does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions. It implies usage by describing the build and optional execute behavior, but it never points to sibling tools like salesnav_typeahead or salesnav_resolve_industry as prerequisites or alternatives. This is a gap for an agent deciding between search-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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds valuable behavioral context: the Sales Navigator subscription requirement and the pagination mechanism (passing next_page_starts_at as page_starts_at). This goes beyond what annotations provide, though it doesn't discuss rate limits or auth specifics, which is acceptable for a read-only tool.

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

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

Two sentences with no verbosity, front-loaded with the purpose, then requirement, return contents, and pagination. Every sentence adds essential information, and the structure is logical and efficient.

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

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

Given the tool's simplicity, presence of an output schema, and full parameter descriptions in the schema, the description covers the key aspects: purpose, requirement, return type, and pagination. It doesn't mention the filter options or count parameter, but those are already well-documented in the schema. It is complete enough for correct invocation; a 4 reflects minor gaps like not mentioning that it returns threads for the given account only.

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 parameters are already documented. The description reinforces pagination semantics ('Paginate by passing next_page_starts_at from the previous response as page_starts_at'), but this largely mirrors the schema's own description for page_starts_at. It does not add new meaning for count or filter, 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?

The description clearly states the tool's function: listing Sales Navigator messaging threads, with the internal resource name (salesApiMessagingThreads) and return contents (threads with messages and participant profiles). This distinguishes it from sibling tools like list_conversations (regular LinkedIn messaging) and salesnav_list_thread_messages (messages within a thread), even though alternatives are not explicitly named.

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

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

The description provides a prerequisite (Sales Navigator subscription) and pagination instructions, but does not explicitly state when to use this tool over alternatives like list_conversations or salesnav_list_thread_messages. The Sales Navigator scope is implied by the name, but no explicit 'when not to use' or alternative routing is given.

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 read-only safety. The description adds useful behavioral detail: subscription requirement, most-recent message selection via message_count, and the total_message_count comparison for detecting that more messages exist. It does not detail pagination mechanics or error handling, but it is informative for typical use.

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

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

The description is compact and each sentence adds a distinct piece of information: what is fetched, subscription requirement, where the ID comes from, and how message_count behaves. No filler or redundancy.

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

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

Covers the key prerequisites, parameter source, return contents, and message_count semantics. It does not explain pagination or failure modes, but for a read-only fetch tool this is not critical. The 'all its messages' phrase undercuts precision but the subsequent message_count/total_message_count explanation compensates.

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

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

The schema already documents all three parameters (account_id, thread_id, message_count), so the baseline is 3. The description adds real value by specifying where thread_id comes from and clarifying that message_count limits the most recent messages and can be compared against total_message_count. This goes beyond simple schema descriptions.

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 identifies a specific fetch operation, the resource type (Sales Navigator thread), what it returns (messages and participant profiles), and names the endpoint(salesApiMessagingThreads/{id}). It also distinguishes the operation from send/list tools. Slight inconsistency: it says 'all its messages' but then explains message_count limits the number of returned messages.

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 states a clear prerequisite (Sales Navigator subscription), gives the provenance of thread_id (from salesnav_list_messaging_threads), and explains message_count behavior. It does not explicitly compare to a sibling alternative (e.g., when to use another listing tool), but the invocation path is clear enough.

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 behavior, but the description adds offline execution, no LinkedIn call, bundled taxonomy, ranked candidates, and disambiguation guidance. This is substantial context beyond the structured annotations and does not contradict them.

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

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

Three sentences with no filler: core action, offline constraint, output summary, downstream usage, and call guidance. Every sentence earns its place and the key 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 an output schema present and annotations covering side effects, the description supplies the remaining operational context: offline behavior, downstream integration, call cadence, and candidate disambiguation. Nothing necessary 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%, so the baseline is 3. The description adds 'any language' to query and indicates results are ranked candidates, but the schema already provides solid descriptions for both query and limit.

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

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

The description uses a specific verb and resource: 'Resolve an industry name (any language) to its LinkedIn Industry Code(s)'. It names the bundled taxonomy, output fields, and the exact downstream user (salesnav_build_search_url's industry filter), clearly differentiating it from sibling tools.

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

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

The description explicitly says when to call it ('Call once per industry term') and how to handle ambiguous results by picking via the hierarchy path. It also identifies the integration point with salesnav_build_search_url, but it does not name explicit alternatives or state when not to use this tool.

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

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

Annotations already carry readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to restate them. The description adds a useful precondition, the Sales Navigator subscription requirement, and clarifies that it acts on an existing thread. It does not expand on side effects such as recipient delivery, CRM copying beyond the schema, or irreversibility, so coverage is adequate but not rich.

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

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

Two short sentences: the first immediately states what the tool does and the second gives the two key usage conditions. It is front-loaded and contains no filler or irrelevant detail.

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

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

Given the complete parameter schema, existing output schema, and non-contradictory annotations, the description covers the essential preconditions and source of the thread ID. It is slightly thin on explicit exclusions and side-effect context, but nothing needed to make a correct call is clearly missing.

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

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

The input schema already documents all 5 parameters with 100% description coverage, so the description does not need to carry the full parameter burden. It adds value by instructing where to get the thread_id from, but it does not add meaning to the other parameters like text, account_id, copy_to_crm, or idempotency_key beyond what the schema already provides.

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

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

The description states a specific verb and resource: send a message in an existing Sales Navigator thread. It also includes the internal action name and makes clear this is the Sales Navigator messaging path rather than generic LinkedIn messaging, so it is distinguishable from its siblings.

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

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

It clearly gives context for when this tool is usable: an existing Sales Navigator thread, an account with a Sales Navigator subscription, and the thread ID from salesnav_list_messaging_threads. It does not explicitly enumerate exclusions or direct users to a generic alternative like send_message, but the necessary usage context is clear.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, so the bar for extra disclosure is lower. The description adds useful context: the tool is 'Live', 'Requires a connected account', and returns '[{id, displayValue, headline}]'. It does not discuss rate limits or latency, but those are not essential here.

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 three dense sentences with no wasted words. The purpose is front-loaded, followed by the most important usage caveat (geo resolves to REGION id), the return shape, and the downstream tool. 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?

It covers purpose, type-specific guidance, output format, downstream integration, and account requirement. The main gap is that it highlights 'company' / 'school' / 'title' but not 'group' or 'industry', even though the schema allows them; still, the rich schema, output schema, and annotations keep the context complete enough 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 description coverage is 100%, so the baseline is 3. The description adds real semantic value beyond the schema by explaining the meaning of type values, especially the geo-to-REGION mapping and the fact that these ids are not enumerable. It does not add meaning for count or account_id, but their schema descriptions already suffice.

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: 'Live Sales Navigator autocomplete for facets whose ids are dynamic.' It also clarifies the unique purpose of geo type by explaining that it resolves a location to its REGION id, which distinguishes it from the consuming tool salesnav_build_search_url.

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

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

The description gives explicit when-to-use instructions: use type='geo' for locations, and type='company' / 'school' / 'title' for entity facets. It also tells the agent where the output goes next ('Feed the chosen id into salesnav_build_search_url'), effectively explaining its role among sibling tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, signaling a safe read operation. The description adds that it processes recent posts with a time window, but does not disclose rate limits, pagination, or what happens if no posts are found. It doesn't contradict annotations, but adds limited behavioral 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?

The description is concise (two sentences) and front-loaded with the core purpose. It avoids redundancy with the schema, mentioning only the key parameter context. Every sentence earns its place, though it could be slightly more explicit about usage scenarios.

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

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

The description is complete given the tool's moderate complexity, the 100% schema coverage, and the presence of an output schema. It covers the essential purpose and the key parameter (since_hours) that affects behavior. The annotations cover safety, so no additional safety disclosure is needed. Nothing critical is missing for an agent to call the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds the meaning of 'account_id' (the LinkedIn account to act on from list_accounts) and clarifies that 'since_hours' limits to posts in the last N hours, which adds value beyond the schema's terse descriptions. However, this is marginal since the schema already covers most semantics.

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

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

The description clearly states the tool fetches likers and/or commenters for the account's own recent posts, distinguishing it from the sibling 'user_posts' which likely lists posts, and 'scrape_post' which likely scrapes a single post. The specific resource ('account's own recent posts') and actions (fetch likers/commenters) are well defined.

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

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

The description explains the function and the 'since_hours' parameter for limiting recency, but it doesn't explicitly state when to use this over alternatives like 'scrape_post' or 'user_posts'. It implies use for engagement analysis on own posts, but lacks explicit 'when not to use' or named alternatives. However, the clarity of 'own recent posts' helps differentiate.

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, and destructiveHint=false, so the safety profile is covered. The description adds that it fetches likers and/or commenters, which is a useful behavioral detail, but it does not disclose things like pagination, rate limits, or what happens when both flags are false. With annotations covering the core behavior, 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 with zero waste. The core action and the two key parameters are front-loaded, and the instruction to pass URL or slug is direct. 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?

The tool has an output schema, so return values need not be explained. The description covers the input format and the two modes. It does not mention what happens if both liked and comments are false, but the schema defaults make that inferable. For a read-only fetch tool with full schema coverage, this 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%, so the schema already documents all four parameters. The description adds the relationship between liked/comments and the fetch modes, but it does not add meaning beyond what the schema provides. Baseline 3 is correct 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 ('Fetch') and resource ('likers and/or commenters for a LinkedIn post'), and distinguishes it from siblings like scrape_profile and scrape_search. It also clarifies the two modes (liked/comments), so an agent can tell it apart from other scrape tools 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?

The description gives clear context on what to pass (full post URL or slug) and how to select output (liked=true and/or comments=true). It does not explicitly state when not to use it or name alternatives, but the sibling list and the specific resource make the usage context clear enough.

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 openWorldHint. The description adds extra behavioral context beyond annotations: it uses SalesNav API when available for richer data, implying data richness may vary by source. This sets accurate expectations, though it does not cover error cases 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?

Two concise sentences: the first states the purpose and output content, the second explains input formats and the SalesNav API nuance. 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 an output schema present and annotations carrying the read-only safety profile, the description provides everything needed to invoke the tool correctly: what it returns, how to target a profile, and the variable-data nuance. 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 already well documented in the schema. The description largely restates the linkedin_id_or_url param semantics (URL, vanity, SalesNav URL, member ID) and adds no new information about account_id or parameter behavior. 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 uses a specific verb + resource ('Fetch a complete LinkedIn profile') and lists data fields (name, headline, company, experience, skills…), clearly distinguishing it from sibling scrapers like scrape_post and scrape_search that target different resource types. It also enumerates accepted identifier forms, leaving no ambiguity about what the tool operates on.

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

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

The description provides a clear use case (fetching a complete profile) and explains how to specify the target (URL, vanity name, member ID, SalesNav URL). It does not explicitly name alternative tools or exclusions, but the context is sufficient to decide when to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it runs exactly one page, returns normalized rows, and has platform-specific pagination behavior (count ignored for standard LinkedIn, fixed ~10/page). This goes beyond the annotations without contradicting them.

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

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

Three sentences with zero waste. The core action and input are front-loaded, and the pagination caveat is stated compactly. 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?

The description is complete for a read-only, idempotent pagination tool. It explains the input, the pagination behavior, and the output shape. The only minor gap is that it doesn't describe the exact structure of the normalized profile rows, but an output schema exists, so that burden is already carried by structured data.

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 four parameters. The description adds the pagination semantics (start+count, count ignored for standard LinkedIn) and clarifies that account_id comes from list_accounts, but the schema already covers the basics. 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 ('Run'), a specific resource ('one page of a LinkedIn, Sales Navigator, or Recruiter search'), and the output ('normalized profile rows'). It also names the input ('full search URL'), which distinguishes it from sibling tools like salesnav_build_search_url (which builds URLs) and scrape_profile (which scrapes a single profile).

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

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

The description explicitly says to pass the full search URL and explains pagination with start+count, including the caveat that count is ignored for standard LinkedIn. This gives clear when-to-use guidance and distinguishes it from URL-building and profile-scraping siblings.

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

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

Annotations indicate no read-only, no idempotency, not destructive; description adds key behavioral details: uses an internal API (createMessage), and the idempotency_key parameter (though in schema) is described to clarify retry semantics. Does not mention rate limits or error behavior, but the description covers the mutation nature implicitly.

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

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

The description is a single, information-dense sentence that front-loads the core purpose and routing rules. It wastes no words and is immediately actionable.

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 a comprehensive schema and a clear description, the tool is well-covered. A minor gap is lack of explicit mention of limitations (e.g., character limits) or when salesnav_send_message is preferred, but given the rich schema and annotations, this is acceptable.

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

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

Schema coverage is 100%, so parameters are well-documented. The description adds critical guidance on how to choose between recipient_linkedin_id and conversation_linkedin_id, and clarifies that in_mail_premium requires recipient id. This goes beyond the schema descriptions and is essential for correct usage.

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?

Description clearly states the verb (send), resource (LinkedIn DM), and mechanism (Voyager createMessage), distinguishing between new DMs and replies. It does not explicitly differentiate from the sibling salesnav_send_message, but the internal routing (conversation vs recipient IDs) is clear.

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

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

The description explains the two modes of usage (existing thread vs new DM) and which parameter to use for each. It does not explicitly mention when not to use this tool (e.g., for sales navigator messaging), but the context provided is sufficient for most cases.

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 readOnly (false), destructive (false), and idempotent (true). The description adds the detail about the default behavior (star=true) and the idempotency key's role, but doesn't add much beyond annotations. Since annotations cover the safety profile, 3 is baseline.

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 wasted words. It front-loads the action and the toggle condition, then immediately defines the key parameter. Perfectly concise for the tool's complexity.

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

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

Given the tool's simplicity and the rich annotations (idempotentHint, openWorldHint, output schema present), the description is sufficient. It covers the essential usage details, though it could mention that the action is reversible (star toggling), but that's implied.

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 documents all parameters. The description reinforces the meaning of conversation_linkedin_id and the star toggle, but the schema already does this. It adds slight value by specifying that star=false removes the star, which matches schema default.

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

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

The description clearly states the verb 'star or unstar' and the resource 'LinkedIn conversation', exactly matching the tool name. It also distinguishes the two actions and references the specific ID needed, making the purpose 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?

The description provides clear context on how to use the tool: set star=false to remove the star, and identifies the conversation ID source. It doesn't explicitly compare to siblings like archive_conversation or delete_conversation, but the purpose is distinct enough that an agent would know when to use it.

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

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

Annotations already provide the safety profile (readOnly, idempotent, not destructive), and the description adds meaningful behavioral context: it sends a signed ping and reports the HTTP status returned. This goes beyond what the annotations alone convey, and it does not contradict them.

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

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

One sentence, front-loaded with the action, and no filler. Every word contributes to understanding what the tool does.

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

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

For a single-parameter tool with annotations, a fully described schema, and an output schema present, the description is complete. An agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, and the schema already describes endpoint_id as 'Webhook endpoint id, from list_webhook_endpoints.' The description adds no parameter-specific detail beyond what the schema provides, so the baseline score 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 states a specific verb ('send'), a specific resource ('webhook endpoint'), and precise mechanics ('signed ping event', 'report the HTTP status'). It is immediately distinguishable from sibling tools like create_webhook_endpoint, update_webhook_endpoint, and delete_webhook_endpoint.

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

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

The purpose is clear: use this to test an existing webhook endpoint immediately. It does not explicitly name alternatives or exclusions, but the 'right now' and 'test' framing gives enough contextual guidance for an agent to route correctly.

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 annotation set includes `readOnlyHint: false` and `idempotentHint: true`, which already tells the agent this is a mutating, idempotent operation. The description adds one meaningful behavioral detail: 'Only provided fields are updated,' clarifying partial-update semantics. However, it does not explain what happens to unprovided fields (they remain unchanged), nor the idempotency-key mechanism already described in the schema. It adds modest value beyond annotations.

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

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

The description is a single, information-dense sentence with no filler. It is front-loaded, immediately stating the action and scope. Every word earns its place, and the 'only provided fields' clause is an efficient behavioral qualifier.

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 presence of a fully descriptive schema (11 params, 100% coverage) and a dedicated output schema, the description covers the core intent adequately. The partial-update behavior is stated, and idempotency is already implied by the annotation and detailed in the parameter schema. It does not mention potential errors or prerequisites, but those are not critical for a straightforward update operation with an idempotency key. Missing guidance on when not to use the tool slightly lowers this score.

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

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

Schema description coverage is 100%, so every parameter (including `idempotency_key` and each `daily_*_conf` field) already has a detailed description in the schema. The tool description adds no additional parameter-specific meaning beyond the phrase 'one or more quota configuration fields,' which merely restates the existence of optional parameters. The baseline of 3 applies because the schema fully carries the semantic load.

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

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

The description states a clear verb ('Update') and a specific resource ('quota configuration fields for a LinkedIn account'), which is unambiguous. However, it does not explicitly differentiate from the read counterpart `get_account_quotas` or any other update tool, so a sibling-aware agent might need to infer the distinction from the name alone.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., the account must exist), nor does it state when a different tool like `get_account_quotas` would be more appropriate. The agent is left to infer usage context entirely from the name and parameter schema.