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

With no annotations, the description carries the transparency burden and discloses key behaviors: date-range requirement, ISO 8601 format, and the 200-post cap. It does not explain what happens past the cap (truncation vs. error) or the return structure, but the core behavioral traits are clearly conveyed.

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?

Four short sentences, each earning its place: scope, exclusion, example use cases, date format, and limit. The primary action is front-loaded in the first sentence, and there is zero filler.

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 list tool with no output schema, the description gives enough for an agent to call it correctly: required date range, format, cap, and the semantic distinction from published posts. The only real gap is the 'platform' parameter and post-cap behavior, which are secondary for basic 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 coverage is 0%, so the description must compensate. It adds essential format semantics for fromDate/toDate via 'Pass ISO 8601 dates,' but the optional 'platform' parameter is never explained, leaving the agent to guess its purpose. This makes the description only partially effective for parameter understanding.

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?

Description uses a specific verb and resource ('Get scheduler-side posts') with a clear date-range scope, immediately distinguishing it from platform-published media tools. Example natural-language queries reinforce intent. The explicit 'Scheduler-side, not platform-published' contrast prevents confusion with sibling tools like list_published_media.

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 states when to use it ('Use for...') with concrete query examples and gives a clear when-not boundary ('not platform-published'). However, it does not name specific alternative sibling tools, relying on the sibling list context instead, so it falls just short of fully explicit routing.

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