Fetch a single content item by id. Errors if no content item with that id exists. This API is an early preview and can change without a deprecation period.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context: 'One request, no automatic pagination', 'provider errors are failures even with HTTP 200', and the preview stability warning. However, it doesn't describe authentication requirements or rate limits. With annotations doing heavy lifting, this is a moderate addition.

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 description repeats the title verbatim and includes an awkward double period. While it front-loads the core action, the preview warning is duplicated from the title. The added GraphQL/pagination/provider-error sentences are valuable but the overall structure wastes space on repetition.

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 read-only fetch tool with full parameter schema coverage and comprehensive annotations, the description adds a few useful behavioral notes (no pagination, provider error semantics, preview instability). However, it omits authentication context and doesn't explain how 'fields' relates to bounding data. Adequate but incomplete.

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 all five parameters are documented in the schema. The description's note about using upstream fields to bound data adds context beyond the schema, but doesn't explain the payload vs payload_file vs individual fields mutually exclusive pattern. Baseline 3 when schema carries the load.

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 states a clear verb+resource: 'Fetch a single content item by id.' It distinguishes single-item fetch from the sibling get_content_items, though the differentiation is implied rather than explicit. The error condition adds specificity.

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 guidance on when to use this tool vs alternatives. It doesn't mention get_content_items for listing or any other retrieval path. The agent is left to infer usage from the name alone.

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