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

Beyond what annotations state, it discloses the webhook validation mechanism: LinkedIn challenges Hermoso's own webhook with the app secret every ~2 hours, which no CRM/Zapier/Make endpoint can answer — the key reason a customer URL must never be promised. It also discloses reply semantics ('The reply is read back from LinkedIn, not from the 201') and post-conditions (events stay in Hermoso when forwardTo is omitted; leads remain readable either way). None of this contradicts the annotations; idempotentHint=true and destructiveHint=false are consistent with a non-destructive subscription action.

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 core purpose is front-loaded, and the critical webhook constraint is CAPS-flagged so an agent cannot miss it. Each subsequent sentence covers one distinct fact: forwardTo behavior, reply semantics, persistence of leads, and cost. It is dense — the webhook sentence packs substantial information — but no sentence is wasted.

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

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

With no output schema, the description compensates by covering the call's effect, the hard webhook constraint, forwardTo behavior, reply semantics, and post-conditions. Minor gaps: it does not point to list_linkedin_lead_subscriptions or delete_linkedin_lead_subscription for managing the subscription afterward, nor does it describe failure/validation 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 description coverage is 100%, so the baseline is 3; the description adds meaning by explaining forwardTo's behavioral consequence — 'leave it off to keep events in Hermoso only' — and clarifying that forwardTo is a relay target, not the LinkedIn webhook. pageId, leadType, and adAccountId gain no new semantics beyond their schema descriptions, which already document defaults and source ownership.

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

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

The opening sentence states a specific action and resource: 'Have LinkedIn push every new lead to Hermoso the moment it is submitted' — a clear verb+resource+trigger semantics. The title 'Turn on real-time LinkedIn lead delivery' matches, and the description distinguishes this creation action from siblings like list_linkedin_lead_events and list_linkedin_lead_subscriptions, which read or manage events/subscriptions rather than create the push.

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 context: forwardTo on/off selects relay-to-CRM versus Hermoso-only, and it cross-references list_linkedin_lead_events for the Hermoso-only case and list_linkedin_leads as the persistent read path 'either way.' It also contains an explicit when-not ('never promise a customer URL as the LinkedIn webhook'). It stops short of fully enumerating sibling selection — e.g., when to use list_linkedin_lead_subscriptions or delete_linkedin_lead_subscription to manage an existing subscription.

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