Enroll leads in a campaign

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

Annotations already declare destructiveHint=true, idempotentHint=false, openWorldHint=true, so the safety profile is known; the description still adds substantial non-redundant behavior: Idempotency-Key is required and server-generated if omitted, the call is hard-rejected without confirm: true, the write targets a live automation with real-world side effects, and workspace scoping can be overridden. It also lists the exact operation and scopes, none of which appear in 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?

Purpose is front-loaded in the first two sentences and the remainder is densely operational with no filler. It does, however, duplicate the confirm rationale already written verbatim in the confirm parameter's schema description, and the 'Luca operation' line is somewhat boilerplate.

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 need not be described, and the description covers scope, confirmation, idempotency, and workspace scoping — everything needed to invoke safely. It omits edge-case behavior (e.g., what happens if the lead is already enrolled, or if the campaign has no published version), which would be the last piece for a tool with this much state mutation.

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 67% and the two undocumented fields (id, body.leadId) are unlabeled beyond their UUID types; the description partially compensates by clarifying that confirm is a hard gate, idempotencyKey enables safe retries, and workspaceId/workspaceSlug override the environment default. It does not state what id refers to (campaign vs. version), which is the main remaining ambiguity.

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 sentence names a specific verb (enroll), the resource (a lead), and the target scope (the latest published campaign version), then adds the consequence: it triggers the live campaign's automation. That distinguishes it from luca_campaigns_enrollments_list (read), luca_campaigns_publish, and luca_broadcasts_launch without opening any schema. Minor mismatch in grammatical number between the name ('leads') and the description ('a lead') does not impair selection.

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 clear from context — call this when you want a specific lead to start the live campaign flow — and the description supplies real preconditions (confirm: true required, required OAuth scopes, optional workspace override). It does not, however, name an alternative or state when not to use it (e.g., drafting/simulating campaigns, or enrolling into an unpublished version), so it stays at clear-context without exclusions.

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