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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by clarifying scope: the cancellation is irreversible for pending items but does NOT touch anything already published, which prevents an agent from assuming it retracts live content.

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, zero filler, with the core action front-loaded and the scope caveat immediately following. Every clause earns its place.

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

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

For a single-parameter cancel tool whose annotations cover the safety profile and which has no output schema, the description supplies the essential behavioral context. It omits error/edge behavior (e.g. cancelling an already-executed proposal) but nothing critical to correct invocation is missing.

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

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

Schema description coverage is 0% for the single parameter, so the description carries the burden and it says nothing about proposal_id. The name is largely self-evident and the 32-char length constraint hints at an opaque ID, so it remains minimally viable but uncompensated.

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 (cancel) and resource (pending proposal) and adds the operative effect ('so it can never be executed'). This clearly separates it from linkedin_execute_action and linkedin_prepare_action without needing to open any 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 phrase 'pending proposal' implies the applicable state and the description scopes the outcome, but it never states when to prefer this over alternatives (e.g. how it relates to linkedin_status or linkedin_list_actions) or what preconditions must hold. Usage is inferable 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 declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-redundant behavior: exactly-once execution semantics, the server-driven confirmation prompt when the client supports it, and a specific no-retry rule for unknown results. It does not describe what a successful execution returns or the observable side effects, keeping it below 5.

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

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

Three sentences, front-loaded with the core action and cardinality, then preconditions, then the retry prohibition. No filler or restated schema 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?

For a destructive, non-idempotent, open-world write with no output schema, the description covers the prerequisite, approval gate, confirmation flow, and retry safety. What is missing is a sense of the observable effect of the action and any failure modes beyond 'unknown', which would round it out.

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

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

Schema description coverage is 0%, so the description must carry the burden. It tells the agent both parameters originate from linkedin_prepare_action, which is real added meaning, but it never explains that proposal_id is a 32-char and digest a 64-char token or what the digest binds to. Partial compensation for a total coverage gap.

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

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

States a specific verb (Perform) and resource (one prepared LinkedIn action) plus the cardinality constraint (exactly once) and the precondition (user approved its exact preview). This clearly distinguishes it from linkedin_prepare_action, linkedin_list_actions, and linkedin_cancel_action.

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

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

Gives an explicit precondition chain: values come from linkedin_prepare_action and the action must be called only after approval of the exact preview. It also gives a when-not rule ('Never call it again for a result reported as unknown'). It stops short of naming sibling alternatives for other flows, so 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=true and openWorldHint=false, so the agent knows this is a safe local read. The description adds the clarification 'Never writes to LinkedIn,' reinforcing the read-only nature, but doesn't describe rate limits, pagination, or what receipts entail.

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

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

Two short sentences, front-loaded with the purpose and its two modes, and a clear negative constraint. No waste.

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

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

For a read-only listing tool with annotations covering safety, the description is adequate but incomplete: it doesn't clarify output shape (no output schema), pagination, or how 'receipts' are represented. The 'which' enum values are described but not exhaustively mapped to behaviors.

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

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

Schema coverage is 0%, but there is only one enum parameter with default 'pending'. The description lists the two possible values' meanings ('pending proposals awaiting approval' and 'recent actions with final status and receipts'), which adds some semantic clarity. However, it doesn't explain the distinction between 'pending' and omitted default explicitly. Baseline for 1 param with good description is 3.

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

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

The description states a specific verb (List) and resource (pending proposals/recent actions), and clearly distinguishes the two modes. It doesn't explicitly name a sibling tool, but the 'never writes' clause helps distinguish it from linkedin_execute_action and linkedin_prepare_action.

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 each mode ('pending' vs 'recent') but doesn't explicitly say 'use this to check status before executing' or route to alternatives. The 'which' parameter semantics are implicit; no explicit exclusions or sibling comparisons are provided.

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

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

Annotations state readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the agent knows it's a non-read-only, non-destructive, closed-world operation. The description adds crucial behavioral context: it's a preparation step that returns a preview, proposal_id, and digest, and does not perform the action. However, it doesn't detail what happens if the preview is not shown or the consequences of skipping execution.

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, dense sentence followed by a critical instruction. It is front-loaded with the core purpose and then lists parameter specifics. However, the parameter enumeration is somewhat lengthy and could be slightly more structured for readability, but it remains efficient with no wasted words.

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

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

Given 8 parameters, no output schema, and 0% schema description coverage, the description provides essential completeness: it defines the kinds and associated parameters, and clarifies the non-execution behavior and required workflow. The only gap is that it doesn't specify the exact format of the returned preview or the digest, but that is arguably beyond the scope of a preparation tool.

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

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

Schema coverage is 0%, meaning the description must compensate. It extensively documents the parameters for each kind: for 'post', it lists text, optional visibility (PUBLIC|CONNECTIONS), optional link_url/link_title/link_description; for 'comment', post_url and text; for 'react', post_url and optional reaction; for 'delete_post', post_url. This adds significant meaning beyond the enum and string types in the schema, though it doesn't specify max lengths or default values already present in the schema.

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

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

The description explicitly states a specific verb ('Prepare (not perform)') and resource ('one LinkedIn action'), and clarifies the output is a preview, proposal_id, and digest. It clearly distinguishes itself from the sibling linkedin_execute_action by emphasizing non-execution and the need to preview first.

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 explicit when-to-use context: 'Always show the user the exact preview before calling linkedin_execute_action.' This directly names the alternative tool and the condition that selects it, leaving no ambiguity about the workflow.

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 and openWorldHint=false, and the description reinforces this with 'Never writes to LinkedIn.' It goes beyond the annotations by disclosing what can be observed (token expiry, today's write usage, approval mode) and that the tool itself defines the server's capability limits — useful behavioral context for a status probe.

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 enumerating outputs plus a four-word safety clause. Front-loaded with the resource being shown, zero filler, and the read-only guarantee is placed where it matters most.

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

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

With no output schema, the description carries the burden of describing return content, and it enumerates the key fields well. The phrase 'what this server can and cannot do' remains vague about the actual shape of that data, but for a zero-parameter read-only status tool this is close to complete.

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

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

The tool takes zero parameters, so the baseline expectation is a 4. The description appropriately does not invent parameter semantics and instead spends its words on output content, which is the relevant information for a no-arg status call.

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 ('Show') and enumerates the exact resources returned: connected member, token expiry, today's write usage, approval mode, and server capability boundaries. The closing 'Never writes to LinkedIn' implicitly distinguishes it from the write-oriented siblings linkedin_prepare_action and linkedin_execute_action.

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

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

Usage is only implied: an agent can infer this is the introspection call for connection/session state before invoking the action siblings, but the description never states when to call it versus linkedin_list_actions or the action tools, nor any prerequisites. Adequate but leaves routing to inference.

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