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

With no annotations, the description takes on the full burden. It discloses returned fields (mediaId, mediaType, truncated caption at 200 chars, permalink, thumbnail, postedAt), recency sorting, and the platform-published vs. scheduler distinction. It does not cover auth, rate limits, or pagination behavior, but the core behavioral traits an agent would need are clearly present.

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 is dense but every sentence adds value: purpose, intent qualifier, return fields, sibling differentiators, and platform scope. It front-loads the main purpose and uses bolded cues ('Browse intent only', 'Platform-published') to highlight key distinctions. No filler or redundancy.

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?

Given no output schema and no annotations, the description covers the essential aspects: return fields, sorting, truncation, platform scope, and alternative routing. It omits pagination and error behavior, but for a list tool with optional filters and a clear sibling set, the provided context is nearly sufficient for correct invocation.

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%, so the description must compensate for the three parameters (limit, accountId, mediaType). It does not explain that limit controls the count, accountId selects an account, or mediaType filters by post/reel/story/carousel. The parameter names are somewhat self-explanatory, but the description adds no semantic value beyond the bare schema, leaving a notable 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?

The description states a specific verb and resource ('List recent media on the user's connected platform'), explicitly scopes to browse intent, and immediately distinguishes itself from siblings like get_latest_published_media, get_published_media, search_published_media, and list_scheduled_posts. An agent can reliably select this tool versus alternatives.

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?

Provides explicit when-to-use guidance with concrete examples ('show my recent reels'), plus clear exclusion criteria for singular intent, known mediaId, caption search, and scheduler-side items. This is model guidance for routing between the closely related list/get/search tools.

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