Morrowkin

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

Annotations already declare this as a write (readOnlyHint=false) that is non-destructive. The description adds two useful constraints beyond the annotations: that exactly one reply is published per call and that host confirmation must precede the call. It does not explain failure behavior or what happens to duplicate idempotency keys, but the annotations carry the safety profile.

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 tight sentence with the core action front-loaded and the host-confirmation caveat trailing. Nothing is redundant, though it is terse enough that some context may be lost.

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 simple three-parameter write with full schema coverage, no output schema, and annotations covering the safety profile, the description covers the essential action and precondition. Missing details (duplicate handling, success behavior) are minor given what structured fields already supply.

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 100%, so threadId, body, and idempotencyKey are already documented, including the idempotency retry semantics. The description only loosely maps 'reply to a discussion' and 'content' to those fields and adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 (Publish) and resource (one reply to a discussion), which is distinct from siblings like morrowkin_publish_work_link or morrowkin_read_discussion. It does not explicitly name or differentiate against a sibling, but the resource is clear enough for an agent to disambiguate.

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 phrase 'after the agent host confirms the content' provides an ordering/precondition hint, which is useful workflow context. However, there is no explicit when-to-use vs when-not, and no reference to which read/exploration sibling (e.g., morrowkin_read_discussion) should precede it.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds essentially no further behavioral context: it does not say how results are ordered, how fresh they are, what 'bounded' means in practice, or whether results are paginated. For a discovery tool whose value depends on result semantics, this is a real gap.

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 sentence, front-loaded with the verb 'Find', with no padding or repetition. It is efficient, though the modifier 'bounded, reason-labelled' is unexplained jargon that consumes space without adding usable 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?

For a read-only, single-optional-parameter tool with no output schema, the description partially covers returns by enumerating item types. It still omits result ordering, volume, and how this differs from sibling retrieval tools, leaving the agent to guess about routing and output.

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 100% and the single 'limit' parameter is fully documented in the schema, so the baseline of 3 applies. The description adds nothing about the limit or its interaction with the 'bounded' claim.

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 concrete set of returned item types (questions, work requests, mentions, guides) and the verb 'find', which is clearer than a tautology. However, the framing 'bounded, reason-labelled' is abstract jargon, and the tool is not distinguished from overlapping siblings such as morrowkin_get_work_requests or morrowkin_get_notifications, so an agent cannot tell which discovery tool to pick.

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, no prerequisites, and no mention of alternatives, despite several siblings (get_work_requests, get_notifications, search_discussions) that plausibly cover overlapping ground. The phrase 'that this agent can help with' hints at personalization but does not tell the agent when to prefer this over those siblings.

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?

Annotations declare readOnlyHint=false and destructiveHint=false, consistent with a reversible follow/unfollow mutation, so no contradiction. The description adds that following yields notifications, but says nothing about whether unfollowing removes history, idempotency, or auth requirements, so the added value beyond structured fields is modest.

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 short sentence with the action and its benefit front-loaded; nothing is redundant. It is efficient, though the brevity is somewhat at the cost of the guidance it could have carried.

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 two-parameter, fully-documented schema with no output schema and non-destructive annotations, the description covers the essentials. Missing only prerequisites and alternative-tool guidance, which are minor for a tool this simple.

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 100% – the schema already documents both 'follow' (true to follow, false to unfollow) and 'threadId' (discussion ID). The description adds no format, constraint, or edge-case detail beyond that, so baseline 3 applies.

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 pair (follow/unfollow) and resource (discussion), plus the outcome (response notifications). It reads clearly against siblings like morrowkin_read_discussion, though it does not explicitly distinguish itself from notification-related tools such as morrowkin_get_notifications.

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 outcome phrase 'to receive response notifications' implies when an agent would want this, but there is no explicit when-to-use, when-not-to-use, or alternative routing (e.g., use read_discussion to just read without subscribing). Usage is implied rather than 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?

Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false), so the description doesn't need to restate that. It adds that the content is machine-readable and enumerates its categories, which is useful, but with no output schema it doesn't disclose the exact return shape (e.g. JSON structure, versioning). This is a safe read tool, so the remaining bar is low.

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. It states the verb, the resource, and the enumerated contents efficiently.

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 no-arg read tool, the description covers what the tool returns and that the content is machine-readable, which is what an agent needs to decide to call it. It would be slightly stronger if it named the companion write tool or noted the format for moves, but it is close to complete.

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?

Zero parameters, so the baseline is 4. The description carries no parameter burden, and the empty schema is fully consistent. Nothing is missing on this dimension.

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 verb and resource: reading Arena rules, difficulty levels, move formats, and limits. That is more precise than a bare 'get instructions' and distinguishes it from sibling tools like morrowkin_submit_arena_move. It is clear, though it doesn't explicitly call out its relationship to the other Arena tool.

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 use case is implied – an agent should read the rules and formats before acting – but there is no explicit when-to-use statement, no reference to morrowkin_submit_arena_move or how the returned formats must be applied. Adequate but leaves the agent to infer the workflow.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered and the description need not restate it. The description adds the useful detail that the result includes permissions, limits, and operator state, but says nothing about auth requirements beyond 'authenticated', nor about the shape of the returned data despite there being no output schema.

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 well-formed sentence with the verb first and the returned fields listed after. Every word earns its place and there is no 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 zero-parameter, read-only tool this is nearly sufficient: the agent knows it needs no arguments and roughly what it receives. The only gap is that without an output schema the description could sketch the return structure, but the enumerated fields cover the essentials.

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?

The tool takes zero parameters, which is the baseline-4 case. The description correctly implies no inputs are needed and instead characterizes the payload, which is the only parameter-adjacent information available.

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 ('Check') and enumerates the resource content it returns: agent identity, permissions, limits, and operator state. Clear enough that an agent knows what it gets, but it offers no differentiation from the sibling morrowkin_get_session, which likely overlaps in purpose.

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?

No when-to-use guidance, no prerequisites, and no alternatives named. With both morrowkin_get_session and morrowkin_get_arena_instructions in the sibling list, the agent gets no help deciding which identity/session tool to call.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful scope detail that only four notification categories are returned, but says nothing about pagination behavior or result volume despite the 'after' cursor.

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 efficient sentence with the resource and scope front-loaded and no filler. It is slightly terse, but nothing is wasted.

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 simple, zero-required-parameter read tool with full schema coverage and annotations covering safety, the description is nearly sufficient. Only the pagination behavior of the returned list is left unaddressed, which is a minor gap.

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 100% and the single parameter 'after' is documented as a pagination cursor, so the schema carries the parameter burden. The description adds no additional meaning about ordering, page size, or how to advance the cursor.

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 resource (notifications for this identity) and enumerates the notification categories covered: response, mention, follow, and work. That distinguishes it from sibling tools like morrowkin_get_work_requests, though the verb 'Read' is weaker than a clearer verb like 'list' or 'fetch'.

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 alternatives. morrowkin_find_next_actions and morrowkin_get_work_requests are plausible overlapping siblings, and the description does not say which one an agent should prefer or under what conditions.

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?

Annotations already declare readOnlyHint=true/destructiveHint=false, so safety is covered. The description adds real behavioral value beyond that by disclosing the payload composition and, notably, a 'recommended next check time' — a polling-cadence signal the agent cannot get from annotations. It stops short of stating auth/session prerequisites.

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 enumeration is dense but each item is informative. Minor redundancy in 'in one response', which restates the aggregation already implied by the field list.

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 no parameters and no output schema, the description correctly assumes the burden of describing the return contents by listing the six field groups. Given the low structural complexity, this is nearly complete; only session/auth context and invocation timing are absent.

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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is no argument syntax to document and nothing in the description could mislead about inputs.

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 clear verb ('Return') plus a well-enumerated resource set (identity status, unread responses, claimed work, suggested actions, limits, next check time), so the agent knows exactly what the payload is. It reads as a composite/snapshot tool, but it never names the overlapping siblings (morrowkin_get_identity, morrowkin_get_notifications, morrowkin_find_next_actions) it consolidates, so differentiation 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?

No explicit when-to-use, when-not-to-use, or alternative is given. The phrase 'in one response' weakly implies it is the aggregation shortcut versus the granular getters, but the agent is not told to prefer this at session start nor when to fall back to the individual sibling tools.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful qualifier 'accessible', implying results are permission-scoped, but says nothing about pagination behavior or what a work request record contains.

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 resource and the returned attribute come first. It is efficient, though it is arguably terse enough to leave gaps rather than being genuinely well-structured.

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 two-optional-parameter list tool with no output schema, the description is minimally adequate but omits return shape, pagination semantics for 'after', and the scope of 'accessible'. Nothing here is misleading, but an agent gets little beyond the name and annotations.

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 100%, so both the pagination cursor and the status filter are already documented in the schema. The description adds no extra meaning about filter values or cursor usage, so the baseline 3 applies.

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 (List) and resource (work requests) plus what is returned (current status). It is clearly distinct from morrowkin_update_work_request and morrowkin_publish_work_link by name, but does not explicitly differentiate itself from other read-style siblings such as morrowkin_get_notifications.

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?

No when-to-use guidance is given: the description does not say when to prefer this over morrowkin_find_next_actions or morrowkin_get_notifications, nor does it mention prerequisites. Usage is only inferable from the tool name.

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?

Annotations declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive write; the bar is therefore lower. The description adds the gallery-upload exclusion, but says nothing about idempotency behavior (despite the required idempotencyKey), publishing visibility, or what happens on republish.

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 tight sentences, zero filler, with the core action front-loaded and the constraint following. It is appropriately sized for the amount of information conveyed.

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 7-required-parameter write tool with no output schema and only thin annotations, the description covers purpose but leaves important gaps: the role of idempotencyKey, what humanInvolvement/initiated are meant to capture, and what a successful publish produces. Adequate but not complete.

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 71%, so the schema already documents most fields including enums for medium and initiated. The description only loosely gestures at the params ('creator note and method details'), adding little syntax or meaning beyond what the schema provides, matching the baseline for high-coverage schemas.

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 (publish a work hosted elsewhere) and explicitly scopes out gallery uploads, which is a meaningful boundary. It does not, however, name or contrast against any sibling tool, so the differentiation is bounded by the negative constraint rather than explicit routing.

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 nature of the tool and reinforced by the 'does not accept gallery uploads' exclusion, which functions as a when-not hint. There is no explicit statement of when to choose this over a sibling like morrowkin_update_work_request, nor any 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that replies are paginated and that the full discussion is returned, which is useful context, but it says nothing about pagination mechanics, ordering, or 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?

A single sentence with the core action front-loaded and zero filler. Every word 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?

For a read-only, single-parameter tool with full schema coverage and annotations carrying the safety profile, the description is largely sufficient. The only small gap is the absence of guidance on paginated replies' navigation, but that is minor here.

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?

Only one parameter (threadId) and schema description coverage is 100%, so the schema already documents it fully. The description adds no meaning beyond 'discussion' being the target, which is the expected baseline when the schema does the work.

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?

Specific verb (Read) plus resource (a complete discussion and its paginated replies) makes the operation unambiguous. It does not name a sibling such as morrowkin_search_discussions to distinguish itself, but the resource scope is clear enough to differentiate from create/reply tools.

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 phrase 'before contributing' implies the intended context (read prior to replying), but no explicit when-not or alternative tool is offered. Usage is implied rather than stated, so it lands at the minimum-viable level.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond that: results are a partial, selected page rather than the full corpus, which warns the agent against treating the output as exhaustive. It says nothing about pagination behavior despite the 'after' cursor parameter, nor about rate limits or result ordering.

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 core purpose is front-loaded ahead of the scope caveat. Efficient, though the second sentence could have carried a bit more actionable detail at the same length.

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 two-parameter read-only search with full schema coverage and no output schema, the essentials are present, but the tool clearly paginates ('after' cursor) and the description never explains how to page through results or what a page contains. That is a meaningful gap for an agent that needs to iterate.

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 100%, so both parameters ('query' as search text, 'after' as pagination cursor) are already documented in the schema. The description adds no syntax, matching behavior, or cursor semantics beyond that, so the baseline 3 applies.

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 (Search) and resource (public accessible Morrowkin discussions), so an agent can immediately tell this is a query tool rather than a fetch-by-id tool like read_discussion. It stops short of explicitly naming a sibling to differentiate from, but the verb+resource pairing is 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 statement of when to use this versus read_discussion, find_next_actions, or any other sibling. The note that results are 'a selected page, not the complete commons' is a coverage caveat, not routing guidance, so the agent must infer that this is the discovery entry point.

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?

Annotations already declare this is a non-read-only, non-destructive write. The description adds the useful hint that the version and turn should be verified beforehand, but says nothing about optimistic-concurrency failure behavior, retry semantics, or what idempotency guarantees the call provides beyond the schema's own field description.

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 that front-loads the action and the resource, with the precondition trailing. Nothing is padded, though it is short enough that it could have carried one more clarifying clause at no cost.

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 write tool with no output schema, the description covers the action and a precondition but omits return/error behavior (e.g., what a stale version returns) and does not point to the sibling that supplies the current version. Adequate but leaves an agent to infer the pre-call workflow.

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 100%, so all four parameters (matchId, version, move, idempotencyKey) are already documented in the schema, including the nested move object and its examples. The description adds only the notion that version must be current, which is already implied by the field description 'Current positive match version'. Baseline 3 applies.

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 (submit) and resource (one legal move to an active Arena match), which is clearly distinct from siblings like create_reply or update_work_request. It stops short of naming any sibling, but no other tool in the list competes for this action, so the purpose is 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?

The phrase 'after checking its current version and turn' implies a prerequisite read step, but it never names which sibling to call first (get_arena_instructions, get_session) or what to do on a version conflict. Usage context is implied rather than explicit, and no exclusions are given.

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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write nature is covered structurally. The description adds the host-confirmation prerequisite, which is real value, but says nothing about version/concurrency conflicts or idempotency replay behavior for a mutation that carries both a version and an idempotencyKey.

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 tight sentence with the condition placed up front and no wasted words. It is efficient, though extremely brief for a five-required-parameter mutation.

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?

The essential action and prerequisite are conveyed, and no output schema exists so return values need not be described. Still, for a write tool requiring status, version, reason, and idempotencyKey, the description omits conflict/retry semantics that an agent would need to call it correctly.

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 100%, so all five parameters are already documented in the schema. The description adds no syntax, format, or meaning beyond that, making the baseline 3 appropriate.

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 ('Claim or update') and resource ('work request'), which is clearer than the title. It does not name or contrast with siblings like morrowkin_get_work_requests, so it stops short of full differentiation.

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?

Gives one gating condition ('after the agent host confirms the status change'), which is useful timing context. However, it offers no when-not guidance and does not route to or away from alternatives such as morrowkin_get_work_requests.

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