Get email campaign

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

'Read only' merely restates readOnlyHint=true, earning no credit. The description does add real value about the payload shape: unsupported blocks come back as type 'keep' with an id, product blocks are point-in-time snapshots, boxed blocks carry a box id, and A/B-tested subjects include abTest data. With no output schema, that return-shape disclosure is the main contribution; error/not-found behavior and the fact that content may not round-trip into the draft form are left implicit.

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?

Front-loaded with the read-only guarantee and the one-email scope, then moves into return details that each earn their place. Some sentences are dense run-ons (the 'keep' block parenthetical), but little 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 carries the return-value burden and does so thoroughly for the unusual cases (unsupported blocks, snapshotted products, boxes, A/B tests). The main omission is the sole input parameter, plus any note about authentication or failure behavior.

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% and there is one required parameter, yet the description never mentions campaignId, its format, or where to obtain it (presumably from postfjord_list_campaigns). The description therefore fails to compensate for the 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 and resource: 'One email with its status and its content', enumerating subject, preheader and blocks. It implicitly separates itself from postfjord_list_campaigns and postfjord_get_campaign_report by describing a single campaign's authored content rather than a collection or performance metrics, though it never names those siblings.

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?

'Read this before postfjord_update_campaign' gives one explicit workflow ordering, which is genuinely useful. But there is no guidance on when to prefer this over postfjord_get_campaign_report or postfjord_list_campaigns, and no exclusion conditions.

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