Find next free time slot

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds useful context beyond that (value is UTC and derived from the configured posting queue), but does not disclose edge behavior such as what is returned when no slot is available or the queue is unconfigured.

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?

Two sentences, no filler, and the core purpose is front-loaded ahead of the consumption directive. Every sentence earns its place by either defining the return value or telling the agent how to use it.

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 one-parameter, read-only tool with no output schema, the description covers both what is returned (the next free scheduling date-time in UTC) and how to consume it, while annotations carry the safety profile. Nothing an agent needs to invoke it correctly is missing.

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?

Single parameter with 100% schema description coverage, so the schema already documents channelId and even points to postsider_list_channels as its source. The description only restates the channel scoping, adding no syntax or format detail beyond the schema, which matches the baseline-3 rule for high coverage.

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 (Return) and resource (the next free scheduling date-time in UTC) for a channel's posting queue. An agent can distinguish this from read siblings like postsider_list_channels or postsider_get_publishing_state because it returns a computed scheduling value rather than a listing.

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?

Explicitly says to use the returned value as the `date` for postsider_create_post when scheduling into the queue, which is a strong workflow directive tying it to the correct sibling. It stops short of naming when NOT to use it or alternative slot sources, so it does not quite reach full when/when-not coverage.

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