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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description still adds real behavioral context: it bundles three kinds of data that 'would otherwise take several calls' and is scoped to group conversations only, not DMs. It does not mention pagination or result limits, but recent_message_count's 1-100 bound is in the 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?

Three short sentences, no filler. The primary capability is front-loaded and the routing guidance follows immediately after. 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 not be explained, and the description still summarizes what comes back (metadata, members, recent messages). Combined with 100% schema coverage and full annotation coverage, an agent has everything needed to select and invoke this tool 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% and each parameter is documented in the schema, including the concise/detailed enum semantics and the 1-100 message bound. The description adds no parameter-level detail beyond what the schema already provides, 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 and resource (get one group's metadata, member list, recent messages) plus the key scope constraint that it does it 'in one call'. This distinguishes it clearly from read_messages and list_conversations without needing to open either 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?

Explicitly names the situation to use it ('orient yourself in a group before reading further or replying') and the situations not to ('direct-message chats', 'paging deeper into history'), routing the agent to the named alternative read_messages. When/when-not/alternative are all present.

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?

Beyond the annotations (readOnly, idempotent, openWorld), the description discloses a real data-scope limitation — the member summary covers only leaderboard messages, not full history — and an error behavior: the undocumented endpoint fails with guidance rather than guessing. These are exactly the traits annotations cannot express.

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?

Three compact movements — what it does, when to use it, and the caveats — front-loaded with the core purpose and no filler sentences. Every clause adds information.

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 formatting need not be explained, yet the description still previews contents (sender, like count, text preview) and covers the scope limitation and failure mode. Nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with enums documented for period and response_format, so the schema carries parameter semantics. The description adds little beyond 'the period's top-liked messages,' which merely restates the period parameter.

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 ('summarize') and resource ('what mattered in a group: its most-liked recent messages'), and distinguishes itself from read_messages by framing the tool as catching up 'without reading everything.' An agent can tell what this returns without opening the 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?

'Use this to catch up on a busy group without reading everything' gives clear context for when to reach for it, and implicitly contrasts with read_messages/search_messages. It stops short of naming an explicit alternative or stating when NOT to use 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 readOnly/idempotent/destructive=false, so safety is covered. The description adds genuine behavioral context beyond that: the recency sort order, merged group/DM listing, last-message previews, member counts, and the fact that each entry carries the ids other tools need.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core action, then the routing rationale. No filler, no repetition of the title or schema.

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 and annotations covering the safety profile, the description is nearly complete; it even sketches the return shape. Missing only pagination/truncation behavior given the 1-100 limit parameter, 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%, so 'kind', 'limit', and 'response_format' are already fully documented with defaults and enums. The description adds no param-level meaning (e.g., no guidance on which kind to pick), 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 and resource ('List the user's GroupMe conversations') plus the ordering ('most recently active first') and scope ('merges groups and direct-message chats into one recency-sorted list'). An agent can distinguish this from siblings like search_messages or read_messages immediately.

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 'Use this first, whenever you need to find a conversation or the ids the other tools take,' naming the downstream consumers (read_messages, get_conversation_context). This gives a clear when-to-use condition and routes the agent to the correct 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 idempotentHint=true, destructiveHint=false, readOnlyHint=false, openWorldHint=true. The description earns credit by spelling out what idempotency concretely means ('liking an already-liked message ... leaves it in the requested state') and by noting the action is on the authenticated user's behalf. It does not mention rate limits or failure behavior, but the annotation bar is already met.

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 the usage context and id-sourcing details. Every sentence carries information; the RST double-backtick artifacts and slight redundancy around message_id are the only minor drag.

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. Combined with annotations, the description covers the action semantics, idempotency, auth scope, and how to source the required ids — everything needed to invoke 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 coverage is 100%, so the baseline is 3. The description adds genuine meaning beyond the schema by explaining where the ids originate (read_messages with response_format='detailed') and warning that conversation_id may be a group id or a composite direct-chat id like '123+456'.

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 opening sentence gives a specific verb+resource ('Like a GroupMe message, or remove your like from one') and the scope is unambiguous. It is clearly distinguishable from send_message because the follow-up states the purpose is 'acknowledging something without posting a reply.'

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 clear positive context ('react to a specific message on the authenticated user's behalf') and implicitly routes away from send_message by noting no reply is posted. It also tells the agent where to obtain ids. It never explicitly names an alternative tool or states a when-not-to-use condition, so it stops short of a 5.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: sender names are resolved, attachments are normalized into image URLs and reply/mention summaries, and an empty page is explicitly a normal answer rather than an error.

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?

Three short sentences, front-loaded with the verb and scope, then usage, then normalization and empty-page semantics. Every sentence carries information an agent needs and nothing is repeated from the schema.

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. The description covers the remaining agent-facing concerns for this tool: how to obtain the conversation id, how paging works, what normalization to expect, and how to interpret an empty result.

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 limit, since_id, before_id, conversation and response_format are already fully documented in the schema, including the mutual exclusivity of before_id and since_id. The description adds no syntax or format detail beyond the schema, so the baseline 3 is correct.

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 ('Read messages from one GroupMe conversation') plus a scoping detail ('oldest first') that an agent can act on. It also anchors the tool to the list_conversations sibling for obtaining the conversation id, distinguishing it from search_messages and get_conversation_context.

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 clear context: use it to read or page through one conversation's history once the id is known from list_conversations, and notes that empty pages are normal. It does not explicitly state when to prefer search_messages or get_highlights instead, so it falls short of a full when/when-not/alternative statement.

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 only cover safety (readOnly/idempotent/non-destructive/openWorld); the description adds substantial mechanics the annotations cannot: no native search API, backward scan from newest, case-insensitive substring matching, the three termination conditions, and the caveat to inspect oldest_message_reached and note before concluding a message was never sent. This is exactly the kind of result-interpretation context an agent needs.

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 purpose, then usage, then mechanics, in three tight paragraphs with no filler. Slightly dense and longer than strictly necessary, but nearly every clause carries operational information.

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?

Covers the full picture for a six-parameter search tool: what it does, when to prefer it, how matching and scanning terminate, and how to read the result fields. An output schema exists, so the description correctly stops short of enumerating return structure while still flagging the fields that change interpretation.

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 baseline is 3. The description goes beyond it by explaining that query matches message text and sender_name matches sender names, both as case-insensitive substrings, and by framing limit and max_messages_scanned as scan-stopping conditions rather than just numeric bounds.

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 (search), a bounded resource (one conversation's message history), and the match target, which cleanly separates it from read_messages and get_conversation_context. The scope word 'one conversation' prevents the agent from assuming a global search.

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 routes the agent: use this to find specific messages instead of paging manually with read_messages, backed by concrete example queries. The when-to-use condition and the alternative it replaces are both named.

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, idempotentHint=false, openWorldHint=true, so the safety profile is covered. The description reinforces non-idempotency in plain language ('calling twice posts twice') and notes it posts 'as the authenticated user', adding auth context, but says nothing about failure modes, rate limits, or the open-world/external nature beyond the annotation.

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?

Three short sentences/paragraphs, front-loaded with purpose, then prerequisites, then the reply variant. No filler and no repetition of schema details.

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. For a non-idempotent send tool, the description covers target-dependent ids, the double-send hazard, and the reply option — everything an agent needs to invoke 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 four parameters are already documented, including the conversation oneOf shape and the image_url restriction. The description only restates the reply_to_message_id usage and id provenance, adding little beyond the schema's own text; 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 ('send') and resource ('a message to a GroupMe group or direct-message chat'), covering both target types. An agent can immediately distinguish it from siblings like read_messages or list_conversations, which are only mentioned as id sources.

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 ('once you know where to send', ids from list_conversations), warns that each call posts a new message, and names the alternative path for replies ('to reply to a specific message, pass its id'). Prerequisite ordering and the reply use-case are both spelled out.

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