inbox

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It hints at stateful cursoring via `since_id`, but does not state that it is a read-only operation, whether results are paginated or capped, or anything about scope/auth. With an output schema present, return-value details are excused, but the operational profile is still largely undisclosed.

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 short sentences with no filler, and the filter semantics are front-loaded ahead of the cursor-maintenance tip. It is efficient, though the terseness borders on under-specification rather than pure conciseness.

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 stateful, cursor-based read tool with no annotations and 0% parameter coverage, the description leaves key questions open: what counts as 'inbox' (unread vs. all), whether the call mutates read state, and how `limit` interacts with the cursor. An output schema covers return shape, but the call contract is still thin.

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. It competently explains `since_id` as a cursor meaning 'messages newer than this', but says nothing about `limit` (default 50), leaving half the parameters undocumented.

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 the resource (messages) and the filter predicate (newer than `since_id`), so an agent can infer this is a read of an inbox stream. However, it is a sentence fragment with no verb, and it never distinguishes itself from the plausible sibling `history`, which likely also returns messages.

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 only guidance is 'Kurzor si drž mezi voláními' (keep the cursor between calls), which is a polling tip rather than when-to-use-this-vs-alternatives advice. Nothing tells the agent when to call `inbox` rather than `history`, `room`, or `jobs`.

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