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

No annotations exist, so the description carries the full behavioral burden. It does disclose one genuinely useful trait — that acknowledging under an active lease requires a valid lease token — but it never says what ack does to the message (finalize? delete? transition state?), whether it is reversible, or what state values are legal.

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?

A single front-loaded sentence with no filler; the prerequisite clause is tacked on efficiently. It errs toward under-specification rather than verbosity, but structurally it wastes nothing.

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?

An output schema exists, so return values need not be explained. Still, for a state-mutating queue operation with zero annotation coverage, zero parameter descriptions, and eleven sibling tools, the description omits what ack changes, valid state values, and how it relates to claim/release — and it is written in Czech while the tool and sibling names are English.

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% across 4 parameters, so the description must compensate. It only touches lease_token (and obliquely state); message_id and error receive no meaning at all, leaving most parameters undocumented in both places.

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?

"Potvrdí stav vlastního doručení" gives a verb (confirms) and a resource (its own delivery), so the general intent is readable. However, "its own delivery state" is abstract without queue context, and nothing distinguishes it from siblings like claim, release, retry, or cancel.

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 second clause states a precondition (an active lease requires the correct token), which is partial usage guidance. But there is no when-to-use, no when-not-to-use, and no routing to alternatives such as release, retry, or cancel in this crowded queue toolset.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does add one important trait beyond the schema — cancelling does not erase the delivery's history — but it is silent on permissions, reversibility, and any side effects on the recipient, which a mutation tool should disclose.

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?

A single front-loaded sentence with zero filler; the operation and its non-destructive caveat are stated immediately with nothing redundant.

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?

An output schema exists, so return values need not be explained, but this is a state-mutating tool with no annotations, two completely undocumented parameters, and no prerequisites. The single sentence leaves the agent without enough to invoke it confidently.

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% for two required parameters (recipient, message_id), and the description adds no meaning: it never clarifies whether recipient is a name, address, or identifier, nor what format message_id takes. Because coverage is low, the description was expected to compensate and does not.

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 gives a specific verb+resource: it cancels an unfinished delivery, and adds the key qualifier that the delivery's history is preserved. This clearly separates it from a delete-style operation and from the 'history' sibling, but it never names an alternative tool, so distinction from the rest of the queue siblings is left to inference.

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?

Usage is implied by the scope constraint ('nedokončené' = unfinished), telling the agent this applies only while a delivery is still in flight. There is no explicit when-to-use/when-not guidance and no named alternative such as retry or release, so the agent must infer the boundary.

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

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

With no annotations, the description carries the full burden and does well: all-or-nothing atomicity, self-expiring TTL so a crashed agent cannot deadlock the repo, directory leases being recursive, and holder+duration returned on conflict. It omits re-entrancy/idempotency (what happens if you re-claim a path you already hold) and any permission requirements, which keeps it short of a 5.

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?

Front-loaded with the core action, then behavior, then the conflict path, then the 'this is for pre-reservation' clarification. Four short paragraphs with little waste, though the final paragraph re-states ground already covered by the hook note.

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 3-param mutation-style tool with no annotations, the description covers atomicity, expiry, conflict reporting, and recursion semantics; the conflict return shape is even described despite an output schema existing. Nothing an agent needs to invoke it correctly is missing, aside from the undocumented `purpose` field.

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 implicitly explains `paths` (files or directories, recursively covered) and `ttl_seconds` (lease expires on its own; holder's remaining duration is reported), but the `purpose` parameter is never addressed and nothing maps the text onto the named fields.

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+resource: taking a lease ('nájem') on files or directories you intend to change, with clear scope (directory leases cover contained files). It is distinguishable from siblings like `release` (the counterpart) and `say` (the escalation channel) without opening any schema.

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?

Explicit when-to-use: reserve ahead when a script will touch many files at once, not for single-file edits since the hook auto-claims those. It also gives the conflict playbook — wait, pick up other work, or reach out via `say` — so the agent knows both the trigger and the fallback.

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

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

No annotations are provided, so the description carries the disclosure burden. It does reveal the nature of the returned records (claims, rejections, blocked edits), which is genuinely useful behavioral context, but says nothing about permissions, scoping, ordering, or pagination limits.

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 the core purpose front-loaded and the use-case immediately after; no filler. It is efficient, though the phrasing is idiomatic enough that a non-Czech-reading agent may find it slightly harder to parse than plain declarative prose.

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?

An output schema exists, so return values need not be explained, and the description covers what the tool is for and when to reach for it. However, with no annotations and zero parameter documentation for a 2-parameter tool, an agent still lacks what it needs to call it precisely.

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% for both path and limit, so the description is the only place semantics could be added – yet neither parameter is mentioned. 'Who touched what' implies a path-scoped query, but the meaning of path (exact file? prefix?), the default, and what limit controls are all left unstated.

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 what the tool returns: a log of who touched what and how it turned out, enumerating outcomes (claim, rejection, blocked edit). That is a specific enough resource-level characterization to separate it from siblings like claim, release, and owner, even though it is phrased conversationally rather than as a clean verb+noun.

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?

It gives an explicit trigger condition: use this after a collision, when asking 'why was my edit blocked and who touched it.' That is clear when-to-use context. It does not name alternative tools (e.g. owner) for related questions, so it stops short of full routing guidance.

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

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.

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

With no annotations, the description carries the full behavioral burden, and it discloses only that a delivery state is returned. It says nothing about whether it is a safe read, whether it is paginated, filtered by ownership, or what a job entry contains, leaving key traits unstated.

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?

It is a single short, front-loaded sentence with no wasted words, which is structurally clean. The terseness here reflects under-specification rather than tight editing, so it does not merit a 4-5.

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?

An output schema exists, so return values need not be explained, but this is one of 13 sibling tools in a job/queue domain and the description provides neither usage routing nor parameter meaning. For a tool competing with claim/release/ack/retry/inbox, the definition is not complete enough to call correctly with confidence.

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 explain 'limit' and 'recipient' but does not mention either. The adjective 'adresované' loosely gestures at a recipient scope, but with no mapping to the recipient parameter or default/pagination semantics, the gap remains substantially unfilled.

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 Czech phrase 'Adresované položky a jejich aktuální stav doručení' identifies the resource (addressed items/jobs) and its content (current delivery status), so the agent can guess it returns job entries. However, there is no verb (list/get) and no differentiation from the many job-lifecycle siblings (claim, release, ack, retry, cancel, next_task), so it stays at minimum-viable.

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?

There is no when-to-use guidance at all: nothing says whether this is the entry point for viewing jobs versus inbox/history/next_task, nor any preconditions. The agent must infer invocation context entirely from the sibling list.

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

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

With no annotations, the description carries the full burden. It does disclose a genuine behavioral trait — the operation is atomic, which matters for concurrent agents — but it omits what happens when no task is ready, whether the task becomes locked/invisible to others, and what the lease guarantees.

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?

One compact sentence with the key mechanism (atomic take of the oldest ready task) front-loaded and zero wasted words.

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?

An output schema exists, so return values need not be described, but for a task-dequeuing tool the description should still cover the empty-queue behavior and lease implications. It is minimally adequate but leaves real operational questions open.

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% and the single parameter lease_seconds is never mentioned in the description, so the agent gets no explanation of what the lease controls or the consequence of its 60-second default. The description does not compensate for the schema 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 gives a specific verb and resource ("atomicky převezme nejstarší připravený task pro tohoto agenta") — atomically takes the oldest ready task for this agent — which is far more informative than the bare name next_task. However, it does not distinguish itself from the sibling "claim", which likely overlaps in purpose, leaving the agent to guess which one applies.

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?

There is no explicit when-to-use guidance, no exclusions, and no mention of the near-synonym sibling "claim" versus this tool. The worker-pull pattern is only implied by the wording, not stated.

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

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

No annotations are provided, so the description carries the full disclosure burden, and it omits permissions, error behavior, and whether the lookup is read-only or blocking. It does, however, disclose a genuinely non-obvious semantic: ownership is reported even when a lease exists on a parent directory, which tells the agent the result accounts for inherited/ancestor state. That single insight is useful but insufficient on its own.

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?

A single short, front-loaded line with zero filler; the scoping nuance is packed into the parenthetical. It is efficient, though arguably too terse to be self-explanatory.

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?

With an output schema present, return values need not be explained, and the tool takes only one required parameter. Still, with no annotations and no usage guidance, an agent lacks context on error cases (e.g., unknown path) and on the relationship to the claim/release siblings, leaving the definition minimally viable.

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 only refers to 'tuhle cestu' (this path) without specifying format — absolute vs. relative, trailing separator handling, or symlink behavior. The parameter's meaning is guessable from its name but not clarified beyond the schema.

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 reads as a question ('Who holds this path...?') rather than a verb+resource statement, so the operation (query ownership/lease holder) must be inferred. The resource — a path — is named clearly, and the parenthetical distinguishes it from a naive ownership check. It does not name the sibling tools (claim/release) that would make the distinction unambiguous.

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?

There is no guidance on when to call this versus the sibling tools, and no prerequisites or exclusions are stated. The 'even despite a lease on the directory above' clause hints at a resolution rule but not at when an agent should reach for this tool. An agent must infer its role from the name and sibling set.

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

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

With no annotations the description carries the full burden. It discloses the omitted-parameter behavior (releases everything you hold) and the consequence of not releasing (blocks other holders), but says nothing about permissions, idempotency, error behavior, or what a partial-path release does.

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, front-loaded with the imperative action and followed by the scoping detail. No filler; the only minor cost is the informal quote styling in the second sentence.

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?

An output schema exists, so return values need not be described. For a single-optional-parameter tool with no annotations, the description covers the core action, timing, and default behavior; remaining gaps (permissions, error cases) are modest.

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% and the sole 'paths' parameter has no schema description, so the description must compensate. It does explain the default case ('without paths releases everything'), but does not clarify the format or meaning of the path values themselves, leaving half the parameter's semantics implicit.

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 and resource ('Vrať nájem' = return the lease) and clarifies the scope ('bez paths vrátí všechno tvoje'). An agent can identify this as the counterpart to the sibling 'claim', though the description never names that sibling explicitly, so it is clear but not fully differentiated from its 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?

Explicitly says when to use it ('jakmile jsi hotový' = as soon as you are done) and adds a when-not-to motive ('holding the lease just in case blocks the other'), which effectively warns against hoarding. It stops short of naming an alternative tool or listing prerequisites.

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

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

No annotations are provided, so the description carries the full burden and largely fails it. It implies a state mutation (delivery moves out of failed/needs_review/dead_letter into pending) but says nothing about required permissions, whether the retry is idempotent, what happens to an already-pending delivery, or side effects such as counters or dead-letter audit records.

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?

A single short sentence with no filler, front-loading the core action and the accepted source states. Nothing could be removed without losing meaning.

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?

An output schema exists, so return values need not be explained, but the rest is thin: a mutation tool with no annotations, zero parameter documentation, and no timing/permission caveats. An agent could guess the intent but not reliably construct a valid call.

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% and three parameters exist, so the description must compensate for that gap and does not. It never mentions recipient, message_id, or not_before, leaving an agent with no clue how to identify a specific delivery to retry or what the not_before delay controls.

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 names a specific action (returning deliveries to the pending queue) and the exact source states it acts on (failed/needs_review/dead_letter), so the agent can tell this is a retry/re-queue operation rather than a cancel or ack. It does not explicitly contrast itself against any sibling tool, so it falls short of a 5.

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?

Usage is only implied: the listed statuses signal that this tool is for recovering deliveries stuck in terminal failure states. There is no explicit 'use this when / do not use this when' guidance, nor any named alternative (e.g. cancel or send) for the opposite case.

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

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

With no annotations, the description must carry the behavioral burden, and it does disclose one non-obvious trait: passing `status` also broadcasts what you are working on, so a nominally read-like call has a publish side effect. It says nothing about permissions, cost, or freshness of the returned state, leaving meaningful gaps for a coordination tool.

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, front-loaded with the one-call status summary and then the calling cadence plus the side effect. Nothing is redundant, though the telegraphic style leaves some clauses under-specified rather than fully self-contained.

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?

An output schema exists so return values need not be spelled out, and the description still usefully previews the three payload categories, the invocation cadence, and the status announcement side effect. For a single-optional-parameter tool it is close to sufficient, missing only how the reported 'locked' state relates to the claim/release siblings.

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% and the lone `status` parameter has only a default of '', so the description must supply the meaning — and it does explain that `status` is where you declare your current work and that others will see it. It stops short of format, length, or whether an empty value clears the announcement.

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 concrete verb and resource — fetch 'room status in one call' — and enumerates the payload (who is present, what is locked, what is new), which is far more informative than the opaque name 'room'. It does not, however, explicitly distinguish itself from near-neighbours such as 'owner' or 'inbox', so an agent must still infer the boundary.

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?

It gives an explicit temporal trigger: 'call at the start of work and after completing a step', which is actionable guidance rather than vague context. It names no alternatives or when-not conditions, so the routing value is partial but the usage window is clearly stated.

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

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

With no annotations provided, the description carries the full behavioral burden, and it does add genuine value: it discloses that this is not a live chat and that MCP is a pull model where the counterparty only reads the message when it polls `room` or `inbox`. Authorization, delivery guarantees, and visibility scope (public to room vs. targeted) are still unstated.

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 plus a prominent warning, front-loaded with the purpose and immediately followed by the critical caveat. Every sentence earns its place.

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?

An output schema exists, so return values need no explanation, and the description covers the async delivery model that an agent most needs to know. It is nearly complete, missing only targeting semantics (whether the message can be addressed to a specific agent) and any precondition such as identifying the sender.

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?

There is one parameter (`text`) with 0% schema description coverage, so the description must compensate. It implicitly conveys that the payload is the message body, but adds no format, length, or addressing details for the parameter itself.

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 action on a specific resource: posting a message to the room, addressed to both another agent and Michal. It clearly frames the tool as a message-post rather than a chat, but it never distinguishes itself from the sibling tool `send`, which an agent could easily confuse with it.

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?

It gives real usage context by naming `room` and `inbox` as the read-side counterparts and warning against expecting an immediate reply, which implies when to use it. However, it never says when to choose `say` over the sibling `send`, so selection guidance is incomplete.

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

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

With no annotations, the description carries the full load, and it does disclose one meaningful behavior: chat alone does not launch work, which matters for an agent deciding how to dispatch effort. It omits permissions, delivery semantics, idempotency (despite a dedupe_key parameter), and any rate or failure behavior.

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?

A single compact sentence with no filler, and the key routing caveat about 'chat' is placed at the end as an emphasis point. It is efficiently sized, though the extreme brevity contributes to its under-specification.

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 5-parameter tool with zero schema descriptions and several undocumented fields, the description is far too thin; the presence of an output schema excuses explaining return values but not the missing parameter and usage detail.

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% across 5 parameters, so the description must compensate and does not. It loosely references the kind values ('chat'/'task') and the addressed nature of 'to', but 'reply_to' and 'dedupe_key' remain entirely unexplained.

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 names the resource ('Adresovaná chat zpráva nebo trvalý task') but supplies no verb, so the action (sending/creating) must be inferred from the tool name. It also fails to differentiate itself from close siblings such as 'say' or 'ack'.

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 clause '`chat` samo nespouští práci' hints that a chat message will not trigger work, implying a task mode would, which is useful directional guidance. However, it never states when to choose this tool over 'say' or 'ack', nor the concrete condition that selects the task mode.

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