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

With no annotations provided, the description carries the full behavioral burden, and 'Read-only' is its only disclosure — useful but minimal. It says nothing about permission requirements, behavior for an unknown or archived id, payload size, or whether 'today's sends' is computed live versus cached, which matters for a supposedly comprehensive snapshot.

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?

One tight sentence that front-loads the completeness claim ('Full campaign') before enumerating contents, with zero filler. It is telegraphic to the point of being cryptic in places ('channel paused flags' immediately followed by 'channelStatuses'), 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?

Missing output schema makes the return-value enumeration the most valuable part of this description, and it does list the major top-level fields an agent needs to plan a follow-up call. Gaps remain in nesting and in field semantics (what a channelStatus differs from a paused flag), but for a single-parameter read tool this is close to sufficient.

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?

There is exactly one parameter with 100% schema description coverage ('Campaign id (UUID) from list_campaigns'), so the schema does all the work and the baseline of 3 applies. The description adds nothing about the id beyond what the schema already documents.

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 enum of returned fields (status, settings, sequence, channelStatuses, today's sends, stats.totalContacts) makes clear this returns the whole campaign configuration object rather than a slice of it. However, it never names any of the near-identical siblings such as get_campaign_analytics or get_campaign_live_status, so the boundary between 'full campaign' and 'campaign metrics' must be inferred from field names alone.

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?

No sentence says when to use this tool, what preconditions exist (an existing campaign id produced by list_campaigns), or which alternative to pick for activity/analytics/live-status data. An agent reading only the description has no routing rule; the only hint lives in the schema's 'from list_campaigns' note.

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