Accept Prepared LinkedIn Connection Invitation

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

Annotations already include readOnlyHint=false, destructiveHint=true, idempotentHint=true, openWorldHint=true. The description adds meaningful context: it emphasizes the server-side verification steps (payload hash, draft expiry, idempotency, exact profile identity, request controls) and the post-condition (verify controls absent and profile shows first-degree connection). This goes beyond simply repeating 'account-changing' and adds concrete behavioral expectations. It does not fully detail all side effects of rejecting or forcing execution, but the description meaningfully supplements 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 a single dense paragraph with front-loaded critical info ('Account-changing action. Invoke only when...'). Every sentence carries substantive guidance, but the phrasing is heavy and could be broken into clearer, more scannable sentences. It is not wasteful, but it lacks the crisp, two-sentence structure seen in the best examples.

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 6 required parameters, rich schema definitions (including ActionApprovalPreview with nested payload types), and a detailed output schema. The description explains the execution flow and safety checks, and it covers important context like draft expiry and idempotency verification. However, it does not explain what the output schema return values mean or what happens when verification fails (error behavior). Given the rich schema already exists, the description is mostly complete, but the absence of failure-mode context leaves a small 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?

The schema description coverage is 33% (2 of 6 parameters have descriptions: action_id and payload_hash, but those only say 'returned by the matching prepare tool'). The description adds context that the tool verifies a preview, payload hash, draft expiry, idempotency, profile identity, and request controls—which helps the agent understand what the parameters represent (context_id, request_id, approval_preview, idempotency_key). However, it does not map those concepts explicitly to each parameter name, so the agent still has to infer which field corresponds to 'preview' (approval_preview) and 'idempotency' (idempotency_key). This is a moderate supplement but not a full mapping.

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+resource: 'Accept exactly one immutable incoming-request draft...' and clearly distinguishes this execute tool from sibling tools (invitations.accept.prepare, invitations.send.execute, invitations.ignore.execute). The phrase 'Account-changing action' and 'Invoke only when...' pin down the exact operation and its scope.

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 'Invoke only when the MCP client's configured approval policy authorizes this exact execute tool' and contrast with 'Interactive confirmation is the safe default; an explicit durable per-tool approval may authorize unattended execution.' This directly guides when vs. when-not to use it, though it doesn't name an alternative tool by name, it clearly states the precondition and the safe default behavior.

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