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

Beyond the sparse annotations (readOnlyHint=false, idempotentHint=false), the description discloses rich behavior: campaigns are created inactive until user activation, the tool returns the new campaign_id, placeholders are 'cleaned up after AI', default behavior for use_ai, and the subtle distinction that {firma} resolves to the sender company while {{company}}/[Firma] resolve to the lead's company. This is substantial value added beyond structured fields.

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 behavior, required inputs, return value, and next-step routing are compressed into the first three sentences, with the placeholder reference material clearly separated afterward. The placeholder section is lengthy but earns its place given the Czech-vocative complexity and alias variants; it is organized with headers and examples rather than padded prose.

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 complex 6-parameter tool with nested step objects and no output schema, the description covers everything an agent needs: draft behavior, step action enum values, returns campaign_id, AI/template defaults, placeholder semantics, sender_context usage, and the follow-up tool. Minor omissions like daily_limit semantics are adequately covered by the 100%-coverage schema.

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?

Although schema coverage is 100%, the description adds critical meaning the schema lacks: the full placeholder syntax and aliases ([Jméno], [Firma], {oslovení}), which placeholders apply to message vs. connect steps, the semantics of delay_hours, and how sender_context feeds AI generation. Without this section, an agent could not correctly compose ai_template values.

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 opens with a specific verb and resource ('Create a NEW campaign') and immediately clarifies the key scope-defining behavior: it is saved as 'draft' and does NOT start sending until activated. This also differentiates it from siblings like start_campaign, since the draft-state note makes clear this tool only creates, not launches.

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 names the next workflow step ('Use add_contacts_to_campaign next to add leads') and states the draft/activation model, which implies start_campaign comes later. It gives clear contextual sequencing but does not explicitly enumerate when to prefer alternatives like update_campaign_settings or start_campaign.

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