linkedin_execute_action

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.