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

With no annotations, the description carries the full burden and discloses very little. It doesn't say whether adding the same reaction twice errors or is idempotent, whether the caller needs channel membership or permissions, or whether the reaction is visible to others — all meaningful for a mutation 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?

A single efficient sentence with the verb and target front-loaded and no filler. It is not padded, though the terseness is what leaves the behavioral and format gaps open.

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 operation is simple and atomic with only two fully-described parameters and no output schema to explain, so the essentials are present. However, for a mutation tool with zero annotations, the missing emoji-format convention and duplicate/permission behavior are real gaps an agent would hit in practice.

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 parameters are already documented in the schema, making 3 the baseline. The description adds no syntax detail — critically, whether emoji_name expects a shortcode like 'thumbsup' or a literal emoji character like '👍' is left unresolved in both schema and description.

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 ('Add') and resource ('reaction emoji') against a clearly identified target ('kChat message'), which is unambiguous. It is naturally distinct from the sibling tools (posting, reading history, user lookups), though the description itself does no explicit differentiating work.

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 use this versus alternatives, no prerequisites (e.g. must the caller already be able to see the message?), and no mention that the message must already exist. The agent must infer all usage conditions from the tool name alone.

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 exist, so the description carries the entire behavioral burden, and it discloses almost nothing: 'recent' is undefined, message ordering is unknown, pagination semantics are unstated, and no permission or privacy constraints are mentioned. For a read tool with zero annotation coverage this leaves significant gaps.

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 the resource front-loaded and no filler. It is efficiently worded, though its brevity is partly the source of the missing guidance rather than pure economy.

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 annotations, no output schema, and an unstated ordering/pagination model, the description is too thin for a tool whose behavior an agent must predict. An agent cannot tell whether messages arrive newest-first, whether 'recent' is bounded by time, or what a returned page looks like.

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%, with page, limit, and channel_id all documented in the schema including defaults and bounds. The description adds no meaning beyond that, so the baseline 3 is 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 ('Get') and resource ('recent messages from a kChat channel'), so the agent knows exactly what is returned. It does not explicitly distinguish itself from the nearby kchat_get_thread_replies sibling, so it stops 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?

The description offers no when-to-use guidance, no prerequisites, and never names an alternative such as kchat_get_thread_replies for threaded content. The only hint is the word 'recent', which is left for the agent to interpret.

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 whole burden and discloses almost nothing. It does not say whether replies are ordered, whether the parent message is included, whether there is pagination or a result cap, or what access is required to read a thread.

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 is lean to the point of under-specification, but nothing in it is wasted or buried.

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 tool with no output schema, the core intent is conveyed, but the return shape and completeness of results ('all replies') are left unexplained and no annotations fill the gap. Adequate minimum, with real gaps for an agent deciding whether it needs pagination or ordering guarantees.

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% and the single thread_id is already documented as 'The parent message ID', so the description adds no meaning beyond the schema. Baseline 3 applies; it does not clarify that the UUID must be the parent rather than an individual reply's ID.

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: retrieve all replies belonging to a kChat message thread. The word 'replies' cleanly separates it from the write-side sibling kchat_reply_to_thread, though the description never explicitly names that or any other sibling.

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 reach for this versus kchat_get_channel_history or kchat_get_user_profile, and no stated prerequisites. The agent must infer from the name alone that this is the read path for a thread once it already has a thread ID.

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 says only 'Get'. It does not confirm the operation is read-only, whether any permissions or visibility rules apply to viewing another user's profile, or what 'detailed' encompasses. That leaves the agent guessing on behavior for a people-data lookup.

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. It is appropriately sized for a one-parameter read tool, though the terseness is also the source of its gaps.

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 single-param read call this is close to sufficient, and no output schema exists so return values needn't be documented. However, with zero annotations the description should at least confirm safety and clarify what profile fields come back; 'detailed profile information' is vague about scope.

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 user_id parameter is fully typed with UUID format and pattern, so the schema does the heavy lifting. The description adds no meaning beyond it — no hint on where to obtain a valid user_id or that IDs come from kchat_get_users.

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 (Get) and resource (detailed profile information) scoped to 'a specific kChat user', which implicitly separates it from the plural kchat_get_users sibling. It stops short of naming that sibling, but an agent can still tell the single-user lookup apart from the list 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?

Usage is only implied: an agent infers it should call this when it already has a user identifier and needs profile detail. No explicit when/when-not guidance or named alternatives (e.g., kchat_get_users for discovery) are provided.

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 discloses that the call is a read returning 'basic profile information', which tells the agent what to expect, but says nothing about pagination limits, total counts, or whether results are filtered by visibility/permissions.

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 verb and resource come first and the return payload is appended compactly.

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, parameter-light read tool with no output schema, the description covers the operation and the shape of the result adequately. It falls slightly short on pagination expectations and scope caveats, which matter for a 'get all users' call with a hard 100-result cap.

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% (page and limit are documented with defaults and bounds), so the schema already does this work. The description adds no pagination or limit guidance, 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 ('Get') and resource ('list of all users') and adds what is returned ('basic profile information'). The word 'all' implicitly separates it from the single-user sibling kchat_get_user_profile, though that sibling is never named.

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 by 'all users' — an agent can infer this is the bulk-listing call versus kchat_get_user_profile, but the description never states when to choose one over the other or any preconditions (e.g. permissions, whether bot accounts are included).

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 exist, so the description carries the full behavioral burden. It discloses scope ('public channels', i.e. no private/DMs) and pagination, but says nothing about auth requirements, ordering, total counts, or whether only channels the caller belongs to are returned.

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 the scope qualifier and the pagination hint; nothing is wasted. It is efficient rather than padded, though the brevity also means little substance.

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 two-optional-parameter read listing with no output schema, the description covers the essential scope and pagination concept. It stops short of describing the returned channel shape or ordering, which an agent building on results would benefit from.

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% — page and limit are fully documented with defaults and bounds — so the description only needs to not contradict them. 'With pagination' merely echoes the schema and adds no format or interaction detail.

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 ('List kChat public channels') and adds the pagination aspect. It is implicitly distinct from siblings, which are all message-, reaction-, or user-oriented, but the description never names a sibling or explicitly contrasts with listing variants.

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 'with pagination' hints at how to page through results, and 'public channels' scopes what is returned. There is no explicit when-to-use / when-not guidance or mention of alternatives (e.g. get_channel_history for message content), leaving the agent to infer.

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 for a write operation. It says nothing about required permissions, rate limits, whether the message triggers notifications, whether the response returns the created message, or any failure modes — only that a message is posted.

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 redundancy, but it is arguably under-specified rather than optimally concise for a mutation tool with no annotations.

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 tool itself is simple (two required string parameters, fully documented, no nested objects, no output schema), so minimal prose is defensible. Still, for a write tool with no annotations, the absence of any permission or return-value context leaves a real 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% with both parameters documented (including a UUID format/pattern for channel_id), so the schema does the heavy lifting. The description adds no meaning beyond it, which is the baseline 3 case.

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 and resource (post a new message to a channel), and the word 'channel' implicitly separates it from kchat_send_direct_message and kchat_reply_to_thread. However, it never names those siblings or explicitly excludes them, so the differentiation is left for the agent to infer.

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 use this versus kchat_reply_to_thread or kchat_send_direct_message, and no stated prerequisites such as channel membership or bot permissions. The agent must guess which posting tool is correct in ambiguous cases.

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 implies a write action but does not mention permissions, whether the thread must already exist, rate limits, or what the tool returns.

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 the action front-loaded and no wasted words. It is efficient, though it is brief enough that the missing behavioral detail is noticeable.

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 two-parameter tool with a fully described schema and no output schema, the description is minimally adequate. However, the lack of annotations leaves the agent without confirmation of write behavior or side effects.

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 are already documented in the schema. The description adds no meaning beyond the schema, which matches the baseline score of 3.

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 and resource ('Reply to a specific message thread in kChat'), which is enough to distinguish it from read-oriented siblings like kchat_get_thread_replies. It does not explicitly contrast with kchat_post_message, so sibling differentiation is only implied.

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 use this tool versus kchat_post_message or kchat_get_thread_replies. The agent must infer that 'reply' means posting into an existing thread rather than starting a new message.

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, yet it discloses nothing about permissions, rate limits, failure modes for unknown usernames, or what the call returns on success. For a write/send operation with zero annotation coverage this is a substantial 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?

A single front-loaded sentence with no filler; the action and target are established immediately. It is efficient but arguably too terse given what it omits.

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 two-parameter tool with fully covered schema and no output schema, the description is minimally sufficient to select and invoke it. It still leaves the agent guessing about delivery confirmation, error behavior, and coexistence with kchat_post_message.

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 both parameters are documented there, so the baseline is 3. The phrase 'by username' merely restates the schema and adds no format, casing, or lookup semantics beyond it.

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 (send) plus resource (direct message) plus targeting mechanism (by username). The word 'direct' implicitly separates it from kchat_post_message, but the description never names or contrasts that sibling explicitly.

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: an agent can infer this is the DM path versus channel posting, but the description states no when-to-use conditions, no prerequisites (e.g. must the user exist, must you share a workspace), and no explicit alternative routing.

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