Omnicord - Discord server management MCP for AI agents

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.3.0
Disambiguation4/5
Most tools have clearly distinct purposes, and descriptions often cross-reference similar tools (e.g., list_events vs list_scheduled_messages vs subscribe_events). A few clusters like get_server_overview/preview/widget or get_member/search_members/list_members could cause hesitation, but descriptions resolve them. The sheer volume increases misselection risk.
Naming Consistency5/5
All tools follow a consistent verb_noun snake_case pattern (list_, create_, delete_, update_, get_, send_, etc.). Variations like read_messages and search_messages fit the same logical pattern, with no mixing of naming conventions.
Tool Count1/5
155 tools is far beyond the typical well-scoped range (3-15) and even exceeds the 50+ extreme threshold. While the breadth matches Discord's API surface, this is an overwhelming number for an agent to navigate, making the tool set unwieldy and hard to reason about as a coherent set.
Completeness5/5
The set covers nearly the entire Discord server management domain: channels, roles, members, messages, threads, forums, events, voice, automod, permissions, blueprints, templates, and more. There are no obvious dead ends; even niche features like soundboard sounds and onboarding are included.
Average 4/5 across 155 of 155 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 52 commits in the last 12 weeks
- Last stable release on August 12, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Elastic License 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond the readOnlyHint annotation; it does not disclose return format, pagination, or server scope behavior. With the annotation present, the description still fails to add useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified rather than concise. A single noun phrase does not earn its place, as it omits critical action and context information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what the tool returns, but it only identifies the resource. For a list operation, it is incomplete and provides minimal contextual value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'guild' parameter, so the baseline is 3. The description adds no additional meaning beyond the schema's own parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Custom stickers in the server' identifies the resource but lacks a verb like 'lists' or 'returns', essentially restating the tool name/title. It does not distinguish this tool from siblings like list_emojis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, which covers safety. The description adds minimal context about rules being server-side and includes 'what they do', but does not disclose behavior like output format, pagination, or whether default guild is used when omitted. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no fluff, but it is under-specified. It does not clearly state the tool's action, making it less useful while still being brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description should clarify what is returned. 'what they do' hints at content but does not explicitly say the tool returns a list of rules. It is incomplete for guiding an agent on expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with a clear description for the only parameter 'guild'. The tool description does not add parameter details, but the schema already fully documents it, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Server-side automatic moderation rules and what they do' explains what the resource is but does not explicitly state the action 'list'. The tool name implies listing, but the description lacks a verb and does not differentiate from sibling tools like create/update/delete_automod_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of viewing rules before creating or updating them, nor any comparison with sibling automod tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation, but the description adds no additional behavioral context such as what is returned, whether all custom sounds are listed, or how the optional 'guild' parameter affects behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, but it is a noun phrase fragment rather than a complete sentence. It is not verbose, but the brevity comes at the cost of clarity, making it under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema and minimal annotations, the description should explicitly state that it returns the custom soundboard sounds or lists them. It does not, leaving the behavior and return value ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional parameter 'guild', which already explains its purpose. The description adds no further parameter-related meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Custom soundboard sounds in the server.' identifies the resource but lacks an explicit verb such as 'list' or 'retrieve'. It is not a complete sentence and relies on the name/title to convey the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool or how it differs from sibling tools like create_soundboard_sound, update_soundboard_sound, or delete_soundboard_sound. The intended usage is only implied by the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already covers safety. The description adds the qualifier 'when configured,' hinting the resource may be absent, but doesn't clarify behavior in that case. This adds some context beyond the annotation but remains minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no fluff, but it's under-specified and reads as a fragment. It could be more informative while still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description should state what is returned and how to handle the 'when configured' case. It doesn't mention return value or the relationship to update_onboarding, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'guild' is fully described in the schema with usage and default behavior. The tool description adds no parameter information, so the schema carries the full burden. Baseline 3 applies due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (new-member onboarding flow) but lacks an explicit verb like 'retrieves' or 'returns'. It distinguishes from the sibling 'update_onboarding' only through the tool name, not the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention being the read counterpart to update_onboarding, nor does it specify scenarios like checking if onboarding is configured.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which covers the safety profile. The description adds useful nuance that 'attendees' are self-declared interested members, not necessarily confirmed attendees. However, it doesn't disclose other behavioral traits like pagination behavior or whether the result is sorted, but the annotation lowers the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using six words. It doesn't waste space, but it is a fragment that lacks a main verb, making it less effective than a complete sentence like 'Lists members who marked themselves interested in an event.' Despite the grammatical incompleteness, it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with 3 parameters and no output schema, the description is minimal. It explains the core concept but doesn't mention that it returns a list, how 'interested' is different from 'attending', or how to use it with event vs. guild parameters. Sibling differentiation is absent, which is a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (event, guild, limit) having descriptive text. The description's phrase 'marked themselves interested' adds nothing directly about the parameters, so the baseline of 3 applies given the schema's heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase ('Members who marked themselves interested in an event.') rather than an explicit verb phrase. It clarifies what 'attendees' means, but doesn't explicitly say the tool 'gets' or 'lists' them. The title provides the verb, so it's not tautological, but the description alone is vague about the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives like list_events or get_event. No mention of use cases, prerequisites, or exclusions. The description only defines the concept, leaving the agent to infer when the tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond the readOnlyHint annotation. It does not disclose response shape, pagination behavior, or behavior for invalid roles, which would help the agent understand the tool's semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short clause that is immediately clear. However, it reads as a fragment rather than a complete sentence, which slightly reduces its structure quality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with a well-documented schema, the description is minimally viable but lacks context about return values and edge cases (e.g., empty role). Given no output schema, the description could do slightly more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters with descriptions at 100% coverage, so the description does not need to elaborate. It provides no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'The members who currently hold a given role' clearly identifies the resource (role members) and scope (current holders), distinguishing it from sibling tools like list_members and get_member. However, it lacks an explicit verb, relying on the title 'Get role members' to convey the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_members or search_members. It simply states what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already declares the read-only nature. The description adds no additional behavioral context such as pagination, permission requirements, or the distinction between thread members who can view vs. have joined. It simply restates the title in question form without new information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, achieving high conciseness. However, it is so minimal that it borders on under-specification, but it does not repeat the tool name exactly and is efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a simple list operation, readOnlyHint, and full schema coverage, the description provides the minimum viable context. It lacks alternative tool references and output details, but for a straightforward read-only list, this may be adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for both 'guild' and 'thread', so the baseline is 3. The description adds no parameter-specific semantics, so the score remains at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Who is in a thread' clearly conveys that the tool lists members of a thread, distinguishing it from sibling tools like list_members (guild members) and get_role_members (role members). However, it uses a question format rather than an explicit imperative verb like 'list', which slightly reduces specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternative member-listing tools such as list_members or get_role_members. The description only states what it does, not the appropriate context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond the readOnlyHint annotation: it specifies the digest content, oldest-first ordering, and paging. However, the reference to 'next_before' is inconsistent with the actual parameter 'before', which could mislead an agent about the API contract.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences that front-load the core purpose and include useful digest details. The incorrect parameter name is a content issue rather than a structural one, so conciseness itself is handled well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return shape (author, time, content, attachments, reactions, reply references) and clarifies ordering and paging. However, the incorrect paging parameter name and lack of fallback guidance leave the description incomplete for a tool with no output schema and no error handling notes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so a baseline of 3 is warranted. However, the description not only adds no meaningful parameter semantics but incorrectly mentions 'next_before' instead of the actual 'before' parameter, potentially confusing the agent. This negative contribution lowers the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads recent messages from a channel and provides a digest with fields like author, time, content, and reactions. It distinguishes itself from get_message (singular) but doesn't explicitly differentiate from search_messages, though 'recent messages' and 'digest' imply a list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a paging hint ('Use next_before to page further back') but provides no guidance on when to choose this tool over siblings like search_messages or get_message. There is no mention of use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states that the tool will 'discard a subscription's buffer', which is a destructive action. However, the annotations set destructiveHint to false, directly contradicting the description. This is a clear annotation contradiction, so the description fails to provide transparent behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler words. It is appropriately concise for a simple operation. However, it is slightly too terse given the lack of parameter and behavioral details, so it does not fully earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's low complexity (one parameter, no output schema), the description is incomplete due to the annotation contradiction and missing parameter semantics. It does not explain side effects like whether the subscription record itself is deleted, what happens to the buffer, or whether the operation is idempotent. This leaves notable gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'subscription_id' parameter at all. It does not explain what the parameter refers to, its format, or any constraints. With zero coverage, the description must compensate, but it completely ignores the parameter, leaving the agent without guidance on how to populate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('stop recording') and the resource ('a subscription's buffer'), distinguishing it from sibling tools like subscribe_events and list_event_subscriptions. The phrase 'discard a subscription's buffer' gives a specific, unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use this tool to stop recording events and discard the associated buffer. It clearly indicates the action, but it does not explicitly mention alternatives or when not to use it. Since the purpose is obvious from the verb and resource, this is a clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds no further behavioral context—such as what the tallies look like, whether polls must be active, or error behavior—so it contributes nothing 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the core concept with no unnecessary words. It is appropriately sized for a simple read-only tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and only a read-only annotation, the description is minimally complete for this simple tool. It states the purpose but omits information about return structure, permissions, or conditions under which it might fail, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes guild and channel but leaves message_id without a description. The description's reference to 'poll message' implies that message_id must belong to a poll, addressing the schema gap. However, it offers no additional detail on format or constraints for the other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving current vote tallies for a poll message. It is specific to polls, distinguishing it from sibling tools like get_reactions or read_messages, though it lacks an explicit verb and doesn't compare itself to alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description simply states what it does, with no mention of prerequisites, exclusions, or related tools that might serve similar purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds minimal behavioral context beyond the locative 'in the local store'. No mention of ordering, pagination, or output format, which would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (four words), which is concise but lacks structure and completeness. A full sentence or brief paragraph would better convey the tool's behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain what a 'blueprint' is or what the list contains (e.g., IDs, names, dates). Without an output schema, the description should fill this gap to aid the agent in using the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the baseline is 4. The description does not add parameter semantics, but none are needed. No credit lost for missing param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Saved blueprints in the local store,' which combined with the name 'list_blueprints' clearly indicates the tool retrieves saved blueprints. It distinguishes from related tools like 'get_blueprint' (single) and 'save_blueprint' (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'get_blueprint' or 'diff_blueprint'. There is no mention of context or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already discloses safe read-only behavior. The description adds that the output includes usage syntax, which is useful context, but does not detail return format or pagination. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, front-loading the core purpose (custom emojis) and an output characteristic (usage syntax). It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one optional parameter and no output schema, the description adequately conveys that it returns custom emojis and their usage syntax. It does not explicitly mention the optional guild parameter, but the schema covers that, and the description is otherwise sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the sole parameter 'guild' is fully described ('Guild (server) name or ID. Omit to use the default guild'). The description adds no additional parameter meaning 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Custom emojis in the server, with usage syntax' clearly states a list operation for custom emojis, distinguishing it from mutating emoji siblings like create_emoji/update_emoji/delete_emoji. The verb 'list' is implied by the title and reinforced by the phrase 'Custom emojis in the server'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives. The description does not mention use cases, exclusions, or when to prefer listing over creating/updating/deleting emojis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only and not destructive. The description adds no further behavioral context, such as required permissions or side effects. It merely restates the action in colloquial terms without going beyond what annotations already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently communicates the tool's core purpose, earning its place without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with full schema coverage and no output schema, the description adequately conveys purpose and parameter usage. However, it lacks any context about when to use it, related alternatives, or restrictions, making it minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all three parameters (guild, member, thread) with clear meanings ('name or ID', 'omit to use default guild'). The description itself adds no parameter-specific information, but with 100% schema coverage, the schema carries the semantic burden adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Pull a member into a thread' uses a specific verb (pull) and identifies both resources (member, thread). It clearly distinguishes from the sibling remove_thread_member by being the add operation, and from other thread tools by focusing on membership.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as remove_thread_member, nor does it mention prerequisites or limitations. Usage is only implied by the name and description, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a read-only operation, so the description adds modest value by specifying what is retrieved: 'settings, state, and counts.' However, it does not disclose any additional behavioral traits such as permission requirements, the meaning of 'state,' or whether the response includes only summary data. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that directly states the tool's output. Every word contributes meaning, and it is front-loaded with the core idea. No padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has full parameter documentation, but without an output schema the description carries more responsibility for explaining return shape. It mentions 'settings, state, and counts' but leaves the specifics (e.g., which settings, what state values, what counts) undefined. For a one-required-parameter getter, this is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters: 'Guild (server) name or ID. Omit to use the default guild.' and 'Thread name or ID.' The description adds no parameter-level information beyond the schema, so it meets the baseline for high schema coverage without adding extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as a single thread and enumerates the aspects returned: 'settings, state, and counts.' Although it lacks an explicit verb like 'get' or 'retrieve,' the title 'Get thread' supplies the action. It distinguishes from list_threads (which returns multiple threads) and update_thread/delete_thread.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as list_threads or get_channel. It does not mention exclusions, prerequisites, or scenarios where a sibling would be more appropriate. The intended use is only implied by the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds the conditional 'when the server has one,' implying a possible null/empty return. This adds some context but does not describe the return format or behavior when no welcome screen exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 10-word sentence that directly states the essential information. No fluff or redundancy; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one optional parameter and a read-only annotation, the description is adequate but incomplete. It does not explain the return value structure or error behavior when no welcome screen exists, and there is no output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single optional parameter 'guild' with a description, achieving 100% coverage. The description adds no further meaning to the parameter beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (Community welcome screen) and implies retrieval through the tool name and title, minimally differentiating it from update_welcome_screen. However, it lacks an explicit verb and scope beyond the conditional 'when the server has one.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as update_welcome_screen or get_onboarding. Usage is only implied by the tool name and resource, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds beyond the readOnlyHint annotation by specifying that buffer sizes are included. However, it does not elaborate on other behavioral aspects like the scope (e.g., bot-level subscriptions) or what constitutes 'active.' The annotation already covers the read-only nature, so the description provides moderate additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of a single phrase. It is front-loaded with the key information, though slightly lacking in structure (e.g., no sentence). Still, it is efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, read-only annotation), the description is reasonably complete. However, it does not explain what 'buffer sizes' means or provide any details about the output format. Without an output schema, this missing context reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is effectively 100%. The description does not need to add parameter semantics, and the baseline score of 4 for zero parameters is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists active event subscriptions and their buffer sizes. It effectively conveys the verb (list) and the resource (event subscriptions). While it does not explicitly differentiate from siblings like subscribe_events, the distinct purpose is understandable given the verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as subscribe_events or unsubscribe_events. There is no mention of prerequisites or context where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and not destructive. The description adds no extra behavioral context (e.g., permission requirements, whether replies are appended in order, or if editing a reply is possible). No contradiction with annotations, but no added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary wording. It is immediately understandable and front-loaded with the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple action tool, the description combined with the schema is minimally adequate. However, it does not mention prerequisites like needing an existing post, the meaning of 'post' (title or ID), or any return behavior, even though no output schema exists. It gets the job done but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, and the schema already documents the purpose of each parameter (post, guild, embeds, content). The description itself adds nothing about parameters, so it neither helps nor hinders beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a reply inside a forum post.' uses a specific verb ('Add') and a clear resource ('reply inside a forum post'). It distinguishes well from sibling tools like create_forum_post, update_forum_post, and delete_forum_post by focusing on adding a reply to an existing post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention that create_forum_post should be used for new posts, or that update_forum_post is for editing the post itself. Usage is only implied by the tool name and title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is destructive (destructiveHint=true). The description adds no additional behavioral context beyond the purpose, such as side effects, permission requirements, or whether the action is reversible. Thus it adds little beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no fluff, and front-loads the action. Perfectly efficient for its simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 complete schema documentation and annotations describing it as destructive, the description is adequate. It could mention return values or prerequisites, but the core action is clear and the structured data covers the rest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, with clear explanations for 'guild' and 'channel'. The description itself does not add further parameter guidance, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('End') and resource ('live stage on a stage channel'), clearly distinguishing it from sibling tools like 'start_stage' and 'update_stage'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, prerequisites (e.g., the stage must be live), or any conditions for invocation. The description only states the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true, so the read-only nature is already known. The description adds the scope constraint that only templates created from this server are returned, which is useful context beyond the annotation, but no additional behavioral details are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at six words, front-loaded with the core resource. It contains no filler or repetition, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter, no output schema) and the read-only annotation, the description sufficiently defines the tool's scope. It could specify the return representation (e.g., template objects/codes) but that is not strictly necessary for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the 'guild' parameter (name or ID, omit for default guild), so the description does not need to add parameter details. The description does not mention the parameter at all, but with 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (Discord templates) and the scope (created from this server), making the tool's purpose clear from the name. However, it is a noun phrase without an explicit verb, which slightly reduces clarity but is still understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool or when to prefer other template tools (create_server_template, sync_server_template, delete_server_template). The description only defines the resource, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates safety, and the description adds the behavioral filter 'currently have a live stage running.' However, it does not disclose return format, pagination, or ordering behavior, so it provides only modest added transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight phrase with no redundant words. It is front-loaded and communicates the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one documented parameter and a clear readOnlyHint annotation, the description is largely sufficient. It identifies what is returned (stage channels with live stages), though it could benefit from noting output shape or limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter (guild) with a clear description, including the default behavior when omitted. The tool description adds no additional parameter meaning, but with 100% schema coverage the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (stage channels) and the filter (currently have a live stage running), and the title 'List live stages' reinforces the action. It is distinct from siblings like start_stage/end_stage, though it lacks an explicit verb in the description phrase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_channels or start_stage/end_stage. The description implies a read-only listing use case but does not state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a mutating but non-destructive operation. The description adds that it copies permissions, color, and settings, but it does not disclose behavior such as what happens if new_name is omitted, whether members are copied, or any return value. This adds some context but leaves notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action verb, and contains no extraneous information. It earns its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with no output schema, the description provides the core action but omits details about optional new_name behavior (e.g., default naming if omitted) and return value. Annotations add minimal safety context. The description is functional but leaves some gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, with role and guild described, but new_name has no schema description. The tool description does not mention any parameters or explain new_name, so it fails to compensate for the missing documentation. Listing 'permissions, color, settings' refers to the source role's properties, not the parameters, so the description adds no parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Copy') and clearly identifies the resource (a role) and the action scope (into a new role). It distinguishes clone_role from siblings like create_role and update_role by explicitly stating it copies permissions, color, and settings into a new role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to duplicate an existing role's properties into a new role, but it does not explicitly state when to use this tool versus alternatives like create_role or update_role. There are no exclusions or mentions of alternatives, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the read-only nature is already covered. The description adds value by explaining the output is resolved into plain language per role and member, but it does not disclose additional behavioral details like rate limits or required permissions. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero filler. It is front-loaded and directly communicates the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two well-documented parameters and no output schema, the description provides sufficient context about the return value (plain language permission overwrites per role/member). It could be more complete by clarifying what 'permission overwrites' are or how to interpret the result, but it is adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The description adds minimal extra meaning, only relating 'channel' to permission overwrites, but does not elaborate on the 'guild' parameter or provide additional format context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description describes what the tool does: resolves channel permission overwrites into plain language per role and member. It distinguishes from siblings like get_member_permissions by focusing on channel and covering both roles and members. However, it lacks a direct verb like 'Gets' or 'Retrieves', making the purpose slightly less explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: to get channel permissions in a human-readable format. It does not explicitly state when to use this tool versus alternatives like get_member_permissions or explain_permissions, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the specific fields returned (enabled state, invite channel) beyond the readOnlyHint annotation. It doesn't disclose additional behaviors like default guild handling or error cases, but the annotation already covers the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Seven words, zero filler, front-loaded. Extremely concise while conveying the key output fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one optional parameter and no output schema, the description adequately conveys what data is returned. It could mention the response shape, but the tool is straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'guild' is fully described in the schema (name or ID, omit for default). The description adds no additional parameter semantics, but schema coverage is 100%, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the resource (server widget) and the exact settings returned (enabled state and invite channel). The 'get' verb is in the name, and the sibling tool 'update_server_widget' clearly distinguishes this as the read counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for reading existing widget settings without modifying them. No explicit when-to-use or comparison to alternatives is provided, but the name and sibling update tool make the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description does not contradict this. The description adds minimal behavioral context beyond the annotation—only mentioning tag filtering and archived inclusion, which are parameter semantics rather than behavioral traits like pagination or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no filler. It front-loads the core concept and is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema, the description covers the main function and optional filters, but it omits details like pagination, sorting, or the return payload structure. It is minimally adequate but leaves the agent to infer behavior from the schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover forum, guild, and tag; the description adds meaning for 'tag' (filterable) and 'include_archived' (optionally archived too), which is useful since include_archived has no schema description. Forum and guild are already documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Posts in a forum, filterable by tag, optionally archived too' clearly indicates the tool retrieves forum posts, and the title reinforces this with 'List forum posts'. It is specific to forum posts and distinguishes from siblings like create_forum_post or list_threads, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys that this tool is for viewing forum posts, especially with tag filtering and archived inclusion, but it offers no explicit guidance on when to prefer it over related tools like list_threads or read_messages. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description does not contradict this. It adds context by enumerating what counts as an integration (bots, Twitch, YouTube links), but provides no detail about return format, pagination, or default-guild behavior beyond what the schema implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that front-loads the key information. No filler or repetition; every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one optional parameter, a read-only annotation, and no output schema, the description is adequate. It defines the resource scope but could optionally mention what is returned or that it lists all integrations for the guild. Still, it is complete enough for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of the single parameter with a clear description. The tool description adds no extra meaning about the 'guild' parameter, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('list') and specifies the resource ('installed integrations') with concrete examples (bots, Twitch and YouTube links). This distinguishes it from sibling delete_integration, though it doesn't explicitly state 'all' or mention global scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are provided. The intended use is implied by the title and description, but it does not call out related tools like delete_integration or contrast with other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The read-only annotation already declares this is a safe read operation. The description adds the ordering behavior ('newest pin first'), which is useful context beyond the annotation. No other behavioral traits (e.g., pagination, limits) are disclosed, so it provides some value but not extensive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It efficiently conveys the core purpose and an important detail (ordering). Excellent structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with a read-only annotation and a clear schema, the description is mostly complete. It covers the essential scope and ordering. There is no output schema, but the return value (a list of pinned messages) is implicit. It might benefit from mentioning pagination or required permissions, but this is not critical for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameters with descriptions, so the baseline is 3. The description mentions 'channel' but adds no new meaning beyond the schema. The 'guild' parameter is not referenced in the description, but the schema already explains it. Thus the description does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the resource (pinned messages) and scope (in a channel), and adds ordering information ('newest pin first'). It lacks an explicit verb, but the title 'List pinned messages' and context make the action clear. It distinguishes from sibling tools like pin_message and read_messages by focusing specifically on pinned messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: use this tool to retrieve pinned messages in a channel. However, it does not explicitly compare to alternatives like read_messages or search_messages, nor does it mention when not to use this tool. The guidance is minimal but the purpose is straightforward enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a non-read-only, non-destructive operation. The description adds that it syncs to the server's structure, but does not disclose whether it overwrites local changes, requires permissions, or is reversible. It meets the baseline but lacks extra behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action and purpose. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema) and the presence of annotations, the description is mostly complete. It lacks details on side effects or what 'sync' entails, but this is a minor gap for such a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'code' and 'guild' having clear descriptions. The tool description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'update' and the resource 'template', with the purpose 'to match the server's current structure'. This distinguishes it from sibling tools like create_server_template and delete_server_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It only states the action without context about typical scenarios or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint=false and destructiveHint=false, so the bar for added behavioral context is lower. The description adds value by explaining the effect of status start/end, but it does not disclose other behavioral traits such as partial update semantics, validation rules, or what happens to existing fields when omitted. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It packs both the editing purpose and lifecycle nuance efficiently, with every phrase contributing to understanding. The structure is clean and immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters and no output schema, the description covers the core functionality adequately by mentioning both detail editing and lifecycle statuses. However, it omits details about required event identification, behavior on success/failure, and any side effects, leaving gaps for an agent to infer. The annotations (readOnly destructive) partially mitigate but do not complete the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (event and guild), leaving six parameters undocumented. The description adds meaning for one parameter (status values start/end) but does not clarify formats or semantics for start_time, end_time, location, description, or name. It fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Edit') and resource ('scheduled event's details'), and explicitly differentiates the lifecycle functionality (status start/end) from sibling tools like create_event and cancel_event. The phrasing 'move it through its lifecycle' adds distinctive scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for editing existing events but does not explicitly mention alternatives (e.g., create_event for new events, cancel_event for deletion) or when not to use it. The lifecycle explanation provides some guidance for status transitions, but overall the usage context 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description is not required to state that it mutates data. It adds that the tool modifies 'name' and 'volume', but does not disclose potential edge cases like whether both fields must be provided, what happens if the sound does not exist, or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is immediately clear and front-loaded with the action. It contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool, the description covers the core operation, but it lacks guidance on important invocation details, such as the requirement to specify a target sound (though 'sound' is in the schema) or that name/volume are optional updates. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'guild' and 'sound' have descriptions). The description mentions 'name' and 'volume' as the mutable fields but adds no further meaning about constraints, requiredness, or the fact that at least one of them should be provided. It does not compensate for the gap in schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool renames a soundboard sound or changes its volume, which clearly identifies the action and target resource. This distinguishes it from sibling tools like create_soundboard_sound, delete_soundboard_sound, and list_soundboard_sounds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you need to rename or adjust the volume of an existing soundboard sound. However, it does not explicitly mention when not to use it or point to alternatives like create or delete tools, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description adds modest value by specifying the exact fields that change (name, description, tags). However, it does not disclose any side effects, permission requirements, or behavior when fields are omitted. The update operation is clearly a mutation, which aligns with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's purpose without filler. Every word earns its place, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with a clear schema and annotations, the description is sufficient for an agent to understand the core behavior. The schema fills in the parameter details, and the description covers the main use cases. It does not explain the return value or error scenarios, but with no output schema, that burden is limited. Overall, it is adequately complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 5 parameters with descriptions for 'guild' and 'sticker', but only 40% coverage overall. The description helps by mapping 'rename' to the 'name' parameter and explicitly listing 'description' and 'tags', which adds meaning beyond the raw schema. However, it does not clarify optionality or relationships between parameters beyond what the schema already provides, and the 'sticker' and 'guild' parameters are left to schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Rename' / 'change') and names the target resource ('sticker') and the mutable attributes (description, tags). This clearly distinguishes it from sibling tools like create_sticker, delete_sticker, and list_stickers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when to choose update_sticker over create/delete, or any distinction from other update tools. The intended usage is only implied by the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description aligns with that by describing a read operation. However, the description does not disclose additional behavioral traits such as pagination, response format, or permissions. With annotations present, the lack of extra disclosure is acceptable but not outstanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence that directly conveys the tool's function without redundant words. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and no output schema, the single-sentence description covers only the core purpose. It does not describe return values or further behavior, but the schema provides parameter details. For a simple read operation, it is minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for guild, limit, and channel (60% coverage), but emoji and message_id lack descriptions. The description's phrase 'given emoji' adds minimal meaning to the emoji parameter but does not specify format or usage. Overall, the description adds marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('reacted') with a clear resource ('message') and scope ('given emoji'), clearly distinguishing it from reaction mutation tools like add_reactions or remove_reaction. It states exactly what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read-only lookup for reactions but does not explicitly state when to use this tool versus alternatives like add_reactions or clear_reactions. No direct exclusion or alternative guidance is provided, leaving only the inferred context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-readonly, non-destructive write operation. The description adds useful behavioral context: mentions are suppressed and display name/avatar overrides are optional. However, it does not disclose permission requirements or other side effects beyond these features.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action, with no redundant wording. Every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and moderate complexity, the description covers the core function and key features but omits return behavior, permission requirements, and explicit usage prerequisites. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, and the description partially compensates by explaining username_override and avatar_url_override as display name and avatar override, while also implying content carries mentions. Yet parameters like content and embeds remain largely dependent on schema descriptions, which are minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Post through a webhook') and the resource (webhook message), and distinguishes it from sibling tools like send_message by noting webhook-specific overrides (display name, avatar) and mention suppression. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus send_message, send_dm, or other messaging tools. Usage is implied by the webhook context, but exclusions or alternative tools are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating (not read-only) and non-destructive operation. The description adds minimal context by specifying the stage must be live, which is a behavioral constraint not captured by annotations or schema. However, it does not disclose other potential effects or requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the purpose without unnecessary words or redundant information. It is as concise as possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update operation with no output schema, the description is adequate but minimal. It does not explain return values, error conditions, or special cases, but the low complexity and good annotations/schema partially compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (guild and channel have descriptions, topic does not). The description clarifies that the 'topic' parameter is being changed, adding some meaning. Since coverage is high, the schema carries most of the explanation, so the description adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Change the topic of a live stage' clearly identifies the specific verb and resource, and distinguishes it from sibling tools like start_stage and end_stage. It is precise about what action is performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you have a live stage and want to change its topic, but it does not explicitly state when to use it versus alternatives or mention any prerequisites. There is no guidance on exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive operation. The description adds that it modifies the description and channel cards, but does not disclose whether omitted fields are preserved or reset, the role of the `enabled` parameter, or any other side effects. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose without any fluff. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and moderate complexity, the description covers the main functionality but leaves gaps: it does not explain the `enabled` parameter, whether updates are partial or full, or the return value. The existence of get_welcome_screen helps, but more detail would be needed for complete guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema coverage is only 25% (guild is documented). The description clarifies that `channels` refers to 'channel cards' with a maximum of five (aligning with maxItems), and mentions the `description` field. However, the `enabled` parameter is left unexplained, and the description does not fully compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Edit') and resource ('Community welcome screen'), and clearly distinguishes what can be edited: the description and up to five channel cards. This sets it apart from the read-only sibling get_welcome_screen and other update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what it edits (welcome screen settings) and implicitly positions it as the update counterpart to get_welcome_screen. However, it does not explicitly mention alternatives, prerequisites, or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a non-read-only operation. The description adds that only pending messages can be canceled, which narrows the scope, but it does not disclose potential errors, irreversibility, or permission requirements. Minimal extra context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that immediately states the action and object, with no filler words or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple cancel operation with two parameters and no output schema, the description provides enough context about the action and its prerequisite (pending message id). The lack of output schema is acceptable for a fire-and-forget cancellation, though it could mention behavior for nonexistent or already-sent IDs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents 'guild' with a description, but 'schedule_id' has only a type. The description's 'by its id' clarifies the role of schedule_id but adds little beyond the schema. The 50% schema coverage is not fully compensated, though the simple nature of the parameter makes it adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'cancel' and identifies the resource as a 'pending scheduled message' with the required identifier. This clearly distinguishes it from sibling tools like schedule_message and list_scheduled_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for canceling messages that have not yet been sent and that an ID is required, but it does not explicitly reference list_scheduled_messages for obtaining the ID or state when not to use. Guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, consistent with a create operation. The description adds context about webhook behavior (display name/avatar) but does not disclose additional caveats like required permissions or the returned webhook object. The added context is useful but modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action ('Create an incoming webhook on a channel'), and every word earns its place. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation, the description plus schema covers the essential context: purpose, channel, name, avatar, and guild. It lacks explicit return value info, but given the annotations and simplicity, this is acceptable. The description is nearly complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for 3 of 4 parameters (75% coverage), with only 'name' lacking a description. The description's mention of 'display name and avatar' gives conceptual meaning to the name and avatar_url parameters, but it does not add detailed parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create an incoming webhook on a channel' – a specific verb and resource. This distinguishes it from sibling tools like update_webhook, delete_webhook, and send_webhook_message, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case by explaining webhooks post with any display name and avatar, which is how messages 'as someone' work legitimately. However, it does not explicitly mention when to use this tool versus alternatives like send_webhook_message, nor does it state prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation, so the description need not repeat that. It adds minor context by noting 'in full,' but does not disclose behaviors like error handling or exact return format. This is adequate given the annotation, but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action ('One saved blueprint') and immediately provides the selection criteria ('by name or ID'). Every word carries meaning, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and a read-only annotation, the description is nearly sufficient. It states the object and identifier, but omits what 'in full' concretely returns (e.g., whether it includes all nested fields). However, given the sibling context and schema, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter with a description ('Blueprint name or ID'), and the tool description echoes that same meaning. With 100% schema coverage, the description adds no additional semantic value beyond confirming the lookup key.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving a single saved blueprint, either by name or ID. It distinguishes itself from sibling tools like list_blueprints (which lists all) and diff_blueprint, making the purpose immediately unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to fetch exactly one blueprint), but it does not explicitly mention alternatives or when not to use it. Users are left to infer that list_blueprints is for multiple results, which is reasonable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation. The description adds the 'active' qualifier, implying expired/revoked invites are excluded, and clarifies scope. No additional behavioral details like pagination or rate limits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase that is front-loaded and contains no redundant content. It effectively communicates the tool's purpose in minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with readOnly annotation and fully documented parameters, the description covers the essential purpose and scope. However, without an output schema, it does not describe the return format or fields of the invite objects, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both `guild` and `channel` with descriptions, achieving 100% coverage. The tool description does not add any parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Active invites for the server or one channel,' clearly indicating a list operation on invites with explicit scoping. It distinguishes from the sibling get_invite (single invite) and create/delete_invite by its verb and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing active invites at server or channel level but does not explicitly mention alternatives like get_invite for a specific invite, nor does it state when not to use it. The context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a read-safe operation, and the description adds valuable behavioral context by guaranteeing that tokens are never included. It also clarifies the scoping behavior (server vs. channel), which goes beyond the bare annotation and gives the agent important security-relevant details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. It front-loads the core scope information and a critical security detail, earning every word. It is appropriately sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, a readOnly annotation, and a minimal schema with two optional parameters, the description provides sufficient context. It addresses the main ambiguity of scope and explicitly notes the absence of tokens, though it does not mention pagination, result ordering, or the exact output shape, which are likely not essential for this type of list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema includes descriptions for only one of two parameters (guild), leaving channel undocumented. The description adds that channel scopes to 'one channel,' which provides some semantic meaning, but it does not explain the relationship between guild and channel (e.g., whether channel requires guild) or behavior when both are omitted. This is partial compensation for the 50% coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (webhooks) and scopes it to a server or single channel, effectively distinguishing it from sibling tools like create_webhook or delete_webhook. Although the verb 'list' is not explicitly repeated, the title and context make the action obvious, so it is specific without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the intended use case (listing webhooks across a server or filtered to one channel), but it does not explicitly state when to choose this tool over alternatives or provide exclusion criteria. There is no mention of when not to use it, such as when needing webhook tokens or handling integrations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, non-destructive mutation. The description adds useful context about batching ('in one call') and optional category reassignment, but does not disclose further behavioral traits like permission requirements, atomicity, or how positions are interpreted relative to existing channels.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. It efficiently communicates the main action and key qualifier ('optionally into a different category').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality (multiple moves, positions, category reassignment) and the schema and annotations provide supporting details. No output schema exists, but return values are not essential for this tool. Minor missing context like whether positions are absolute or relative, but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; the 'moves' parameter itself lacks a top-level description, but its items' fields (channel, category, position) are documented. The description's mention of moving channels to new positions and categories aligns with the schema but does not add deeper meaning beyond what is already in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Move') and resource ('channels'), and clearly states the scope: reordering positions and optionally moving to a different category. This distinguishes it from sibling tools like reorder_roles and update_channel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool ('Move channels to new positions... in one call') but does not explicitly contrast with alternatives such as update_channel or reorder_roles. It provides no exclusion criteria or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only state the tool is not read-only and not destructive; the description adds that it persists to a local store and that names are unique, which are useful behavioral details. However, it does not disclose what happens on duplicate names (error vs. overwrite) or what the response contains, leaving some ambiguity for a mutation tool with sparse annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with front-loaded purpose and no filler. The uniqueness note is compact and the mention of downstream tools is valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested blueprint object and lack of output schema and rich annotations, the description covers the core action and uniqueness but omits conflict handling and return value, leaving some gaps for an agent deciding whether saving will overwrite or fail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The top-level schema has 0% description coverage, so the description must compensate. It adds a uniqueness constraint for the `name` parameter, but provides no additional meaning for `blueprint` or `description` beyond what the schema structure implies, leaving the agent to infer that blueprint is a full server configuration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves a blueprint to a local store for reuse, using specific verbs and referencing downstream tools (execute_build_plan, diff_blueprint) that distinguish it from sibling blueprint tools like list, get, delete, and export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the purpose is reuse, pointing to execute_build_plan and diff_blueprint as follow-up uses, giving the agent a clear context for when to invoke save_blueprint. It does not explicitly state when not to use it or compare to export_server_blueprint, but the guidance is sufficient for basic selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read-only, non-destructive operation. The description adds the conceptual detail of 'explicitly allowed and denied' permissions, but does not disclose important behavioral traits such as whether it overwrites existing overwrites, whether it requires manage_permissions, or what the success/failure response looks like. This leaves some ambiguity 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. The first sentence states the action and target, the second gives a concrete example of accepted values. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description plus schema and annotations are mostly adequate. It lacks return-value information and prerequisites, but the core behavior is clear and the tool is well-differentiated from siblings. Slightly more detail on side effects would make it a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with descriptions, so the baseline is 3. The description adds minimal extra value: it clarifies that allow/deny are explicit lists and provides example permission names, but the schema already conveys the meaning. No new parameter semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set a permission overwrite on a channel for one role or member' and distinguishes it from get/clear/lock/unlock permission tools by specifying it sets allowed/denied permissions. The verb 'set' and resource 'channel permission overwrite' are specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you want to set a permission overwrite), but does not explicitly state when to use it versus alternatives like clear_channel_permissions, lock_channel, or explain_permissions. There is no mention of prerequisites or conditions that would rule it in or out, though the purpose is clear enough for basic selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false. The description adds the behavioral note that the message content is not affected, which aligns with destructiveHint=false. However, it does not disclose any additional behaviors such as permissions needed, error conditions, or whether the message must already be pinned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences, conveying the core action and a key clarification without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple unpin operation, the description is mostly adequate but lacks context about required message_id semantics, the need for the message to be pinned, and any permission requirements. The tool's input schema and annotations are limited, so more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only guild and channel have descriptions). The description contains no parameter information, leaving message_id and reason unexplained. The agent must infer that message_id identifies the pinned message and reason is for audit logging, which is not clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Unpin a message') and the resource ('message'), and explicitly differentiates from deletion with 'The message itself is untouched.' This distinguishes it from delete_message and clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not name alternative tools or explicit when/when-not conditions, but the phrase 'message itself is untouched' gives contextual guidance that this tool is for removing a pin without deleting content. It implies use when the goal is to reverse a pin, but no exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the safe-to-modify nature is known. The description adds that it renames, which is consistent. However, it does not disclose any additional behavioral details like permission requirements, whether the old name is freed, or any side effects. The bar is lower given annotations, but no extra context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is direct and front-loaded. Every word earns its place. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with no output schema, the description conveys the core action. However, it could mention prerequisite conditions (e.g., emoji must exist, guild context) or side effects, but the schema covers the guild parameter. Overall, it is nearly complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%: the emoji and guild parameters have descriptions, but the 'name' parameter (the new name) does not. The description 'Rename a custom emoji' adds no meaning beyond the verb itself. It does not compensate for the undocumented 'name' parameter, but the schema pattern hints at its format. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Rename a custom emoji.' This is a specific verb (rename) and resource (custom emoji), and it differentiates from sibling tools like create_emoji, delete_emoji, and list_emojis. 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by the verb 'rename' but gives no explicit guidance on when to use this tool vs alternatives. It does not mention exclusions or prerequisites, such as needing the emoji to already exist. With sibling tools present, a clearer note about 'use this to modify an existing emoji' would help, but the intent is inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint false) and non-destructive (destructiveHint false). The description adds a meaningful behavioral detail beyond these annotations: 'One template per server', which signals a potential failure or constraint if a template already exists. It also uses 'Snapshot' to suggest it captures the current state without altering the server. However, it does not specify what happens when the constraint is violated (e.g., error, overwrite) or mention any side effects on existing templates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loads the primary action ('Snapshot this server's structure'.) Every word contributes meaning: it states the purpose, the target resource, the output, and a key constraint. There is no redundancy or filler. This is a model of conciseness for a clear, single-purpose tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 params, no output schema, minimal annotations), the description covers the core action and an important constraint. It is reasonably complete for an agent to understand what the tool does. However, it leaves out details about the return format (e.g., does it return the template code?) and error behavior when the one-template-per-server limit is reached. These would enhance completeness but are not strictly required for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (only 33%, with 'guild' described but 'name' and 'description' not explained). The tool description does not compensate for this gap; it does not describe the purpose or behavior of any parameters. The description 'this server's structure' implicitly relates to the 'guild' parameter, but it provides no guidance on how 'name' or 'description' are used. The agent would have to infer the semantics from context, which is insufficient for a 3-parameter tool with one required param.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Snapshot') and clearly identifies the resource ('this server's structure') and the outcome (a Discord template others can use). It distinguishes well from sibling template tools like list_server_templates, sync_server_template, and delete_server_template by focusing on creation. The additional constraint 'One template per server' further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('when you want to snapshot the server structure') and states the one-template-per-server constraint, but it does not explicitly guide when to use this tool versus alternatives (e.g., sync_server_template for updating an existing template) or mention scenarios where one should avoid using it. No explicit exclusions are provided, leaving the usage guidance somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only readOnlyHint=false and destructiveHint=false, so the description adds valuable context by specifying file type requirements (png, apng, gif), dimensions (320x320), size limit (512 KB), and server slot constraints. This goes beyond the structured data, though it does not mention error behavior or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences convey the core purpose and key constraints without fluff. The information is front-loaded and every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema, and the description covers the creation purpose and critical constraints. However, it omits return value expectations, permission prerequisites, and failure modes, which are relevant for a create operation. Still, it is adequate for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes tags, guild, and description (60% coverage). The description adds meaning for image_url by stating it is the image source and giving format constraints, but it does not clarify the 'name' parameter beyond the general creation context. Overall, the description supplements but does not fully compensate for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Upload a custom sticker from an image URL.' It clearly identifies the tool's function and differentiates it from sibling tools like update_sticker and delete_sticker by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to create a sticker) and adds context about format and slot limits, but it does not explicitly mention alternatives like update_sticker for modifying existing stickers or list_stickers for viewing. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, meaning the tool may have side effects but is not destructive. The description adds useful behavioral context: it explains the permission decompilation logic (private_to and read_only with warnings) and the optional save_as behavior that writes to the store. It does not contradict annotations and provides nuance beyond the basic 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the primary action and then provides necessary details. It avoids unnecessary fluff and every clause adds meaningful information about the tool's behavior and optional parameters. While it could be split into two sentences for readability, it remains concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (permission decompilation, optional save) and lack of an output schema, the description provides a solid overview. It mentions key aspects like the transformation of permission overwrites and the optional storage behavior, but it does not explicitly describe the return value or handling of existing blueprints with the same name. However, these gaps are partially mitigated by the detailed parameter schema and the clear snapshot intent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (guild and save_as) are already well-documented in the schema. The description adds minimal extra meaning, only mentioning that save_as writes 'straight to the store,' which is slightly more descriptive than the schema's 'Save the export under this blueprint name.' Since the schema carries the load, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Snapshot a live server's structure into a blueprint' and lists the included components (roles, categories, channels, visibility) and the permission decompilation behavior. This distinguishes it from sibling tools like save_blueprint (which saves an existing blueprint) and diff_blueprint (which compares blueprints). The verb 'snapshot' and resource 'live server' make it specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for capturing a live server's structure, but it does not explicitly state when to use it over alternatives or provide exclusions. While the sibling context suggests it is distinct from create_server_template and save_blueprint, the description itself offers no direct guidance on selection criteria. This is an implied usage case, not explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint already declaring the safe read-only nature, the description adds meaningful behavioral context by listing the exact data returned and the discoverability constraint. This goes beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose and followed by a necessary access caveat. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description adequately covers what is returned and under what conditions the tool works. No critical information appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional 'guild' parameter, so the schema already documents it fully. The description does not add extra parameter details, but the baseline of 3 applies because the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies what the tool returns: a server preview with name, description, and approximate member counts. However, it does not explicitly differentiate itself from sibling tools like get_server_overview or get_server_widget.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context about when the tool works ('servers the bot is in; other servers need to be discoverable'), but it does not mention alternatives or when to prefer this over similar server-info tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, signaling a mutation that is not destructive. The description adds the permission requirement but does not disclose other behavioral details such as reversibility or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no unnecessary words. It front-loads the core action and includes a relevant permission note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema is complete, but the description omits any mention of return values or potential side effects. Annotations provide some safety context, making it moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptions in the schema, giving 100% coverage. The description does not add any further meaning about the parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Remove a member from a thread,' identifying both the action and the resource. This unambiguously distinguishes it from sibling tools like add_thread_member and list_thread_members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes the prerequisite 'Needs Manage Threads,' providing context on when the tool can be used. However, it does not explicitly mention alternatives or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-readOnly and non-destructive, and the description adds a temporal qualifier ('early') but does not mention permission requirements or behavior when no timeout exists. It adds some value beyond annotations but lacks depth expected for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single eight-word sentence, front-loaded with the action ('Lift'), with zero fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter mutation tool with annotations, the essential purpose is clear. It does not address edge cases (e.g., no active timeout) but those are not critical given the tool's simplicity and the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers guild and member with descriptions, but reason is undocumented (67% coverage). The description provides no parameter-specific guidance and does not compensate for the missing reason parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Lift' and clearly identifies the resource ('active timeout') and target ('member'). It unambiguously distinguishes this from timeout_member, which sets a timeout, and from other moderation actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an active timeout needs to be ended early. It does not explicitly name alternatives or exclusion cases, but the contrast with timeout_member is implicit from the verb 'lift' and the sibling toolset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is mutating but not destructive. The description adds context by specifying what can be changed (e.g., "lock or unlock replies", "pin or unpin"), which goes beyond the annotations. However, it does not disclose side effects, permissions, reversibility of archiving, or behavior when fields are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that lists all key actions without any filler. Every phrase conveys meaningful information about what the tool does, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and low schema coverage, the description provides a useful overview of the tool's operations but lacks some essential details. It does not explain how fields interact (e.g., whether omitted fields remain unchanged), the exact meaning of 'archive' beyond the verb, or the need to specify the post identifier (which is covered by the schema's description). Enough to get started, but not fully complete for complex update scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 43%, so the description must compensate. It clarifies title, tags, pin/unpin, lock/unlock, and archive, adding meaning to the boolean parameters. However, it misses the required 'post' parameter and 'guild' parameter (though these are already described in the schema), and it does not explicitly explain that tags replace the existing set. Partial compensation for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb "Edit" and names the resource "forum post", then enumerates the exact editable aspects (title, tags, pin, lock, archive). This clearly distinguishes it from siblings like reply_to_forum_post, delete_forum_post, or create_forum_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use context clear by listing the operations, so an agent knows to use this when modifying a forum post's title, tags, pin state, lock state, or archive status. It does not explicitly mention when not to use it or name alternatives, but the context is strong enough to avoid confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate that the tool is mutable but non-destructive. The description adds that it can rename or change the moderated flag, but it does not disclose side effects, error conditions, or whether both fields can be updated simultaneously. It provides minimal additional behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, scannable sentence that states the two primary use cases without any fluff. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description is brief but covers the core operations. It does not specify return values, error behavior, or prerequisites like tag existence or permission requirements. It is minimally complete but leaves several operational questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover tag, forum, and guild, but 'name' and 'moderated' lack descriptions. The description clarifies that 'name' is the new tag name and 'moderated' is the flag to set, which compensates for the missing schema descriptions. However, it does not explain parameter interactions or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renames an existing forum tag or toggles its moderated flag. It uses specific verbs and explicitly names the resource (forum tag), distinguishing it from create_forum_tag and delete_forum_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for modifying an existing forum tag, but it does not explicitly contrast with create_forum_tag or delete_forum_tag, nor mention when to choose this over alternatives. The sibling list provides context, but the description itself lacks direct usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the agent knows it's a write but non-destructive operation. The description adds that it accepts unicode or custom emoji by name and supports multiple emojis. However, it doesn't disclose potential side effects, required permissions, or behavior for duplicate reactions, so it only partially exceeds annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the action and key detail (single call). No wasted words; it is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple tool with annotations and a 75% schema coverage, the description provides enough context to understand the tool's core behavior. It misses minor details like rate limits or permission requirements, but these are not essential for basic usage and are partly covered by annotations. Overall, it is sufficiently complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some value by clarifying that emojis can be unicode or custom names, but the schema already covers emojis ('like a pasted emoji or a custom emoji name'). With 75% schema description coverage, the description does not significantly enhance understanding of the guild, channel, or message_id parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Add one or more reactions to a message in a single call.' It specifies the action (add), the target (message), and the batch capability, distinguishing it from sibling tools like remove_reaction, clear_reactions, and get_reactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (adding reactions) and adds the batching guidance 'in a single call.' It doesn't explicitly mention alternatives or when not to use it, but the context and sibling tool names make the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds valuable behavioral context: it removes only the specific overwrite and restores inheritance from the category and roles, which clarifies the outcome beyond the annotations. It does not contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action ('Remove a role's or member's permission overwrite') and then explains the resulting effect. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with two required parameters and no output schema, the description sufficiently explains what it does and the outcome. However, it does not mention edge cases like what happens if the target has no overwrite, or whether specific permissions are needed on the channel. Still, given the simplicity and good schema/annotations, the description is complete enough for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for all three parameters (channel, target, guild), with 100% schema coverage. The description does not add additional parameter-specific details, so the baseline of 3 applies where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: removing a role's or member's permission overwrite from a channel, and it explicitly mentions the effect of restoring inheritance. This distinguishes it from sibling tools like set_channel_permissions (which updates overwrites) and get_channel_permissions (which reads them), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: use this tool when you want to remove a permission overwrite and restore inheritance. However, it does not explicitly name alternatives or state when not to use it, so the guidance is implied rather than direct. It could have mentioned that to change overwrites, use set_channel_permissions instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool copies settings and permission overwrites and places the new channel in the same category, which adds detail beyond the annotations. It does not contradict annotations (readOnlyHint=false, destructiveHint=false). However, it does not mention whether the original channel is modified or if messages are copied, though 'copy' implies non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action and resource, with no filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple clone operation with annotations present. It specifies the input, output (new channel), and constraint (same category). It does not cover edge cases or return values, but given the schema and annotations, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the schema (100% coverage), so the description does not need to add parameter details. It adds marginal context by mentioning 'settings and permission overwrites' which maps to the channel parameter, but the schema already handles it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Copy' and identifies the resource ('a channel's settings and permission overwrites') and the outcome ('into a new channel in the same category'). It clearly differentiates from sibling tools like create_channel and update_channel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use guidance or comparison with alternatives like create_channel or clone_role. The usage context is implied by the purpose, but no exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description adds targeting context but no additional behavioral details such as permission requirements, rate limits, or failure scenarios. This is acceptable given annotations, but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no filler. It is front-loaded with the verb and immediately communicates the action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with a clear purpose and no output schema. The description completely explains the action and target. It could mention prerequisites like the need for the channel to be an announcement channel, but that is already embedded in the phrase 'announcement channel', making it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (channel and guild are described, message_id is not). The description does not add parameter-specific details, but the missing message_id is self-explanatory from context. The description provides marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Publish' with a clear resource ('a message in an announcement channel') and target ('every server that follows it'). This clearly distinguishes the tool from siblings like send_message or forward_message, which operate on regular channels or direct targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use it: when you want to broadcast a message from an announcement channel to all following servers. However, it does not explicitly name alternatives or state when not to use it, so it falls slightly short of explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers safety. The description adds behavioral context by explaining that results are derived through the role and overwrite chain and that the actor can be the bot or a member, going beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with the core purpose front-loaded. The second sentence is a concise metaphor that adds value without fluff, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description conveys the basic result ('Answer whether' and 'explain the result') but does not specify the exact return format. Given the tool's simplicity and strong schema coverage, it is adequate but not fully explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 reinforces the meanings of 'actor', 'channel', and permission context but does not add new syntax or format details beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool answers whether an actor has a given permission and explains the result via the role and overwrite chain. It specifies a distinct verb ('Answer') and resource (permission check), differentiating it from siblings like get_member_permissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'preflight engine, made directly askable' metaphor implies use for preflight permission checks, but it does not explicitly compare to alternative tools like get_member_permissions or get_channel_permissions, nor provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating (readOnlyHint=false) but not destructive operation. The description adds the behavioral effect of crossposted messages appearing in the target, which is useful context. However, it does not disclose potential side effects like duplicate subscriptions, permission requirements, or irreversibility, which would be valuable for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. It front-loads the action and clearly states the purpose without any redundant words. Every word earns its place, making it highly concise and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description adequately explains the operation and its outcome. Given that there is no output schema, the description focuses on the effect rather than return values, which is appropriate. It could mention prerequisites like the source being an announcement channel, but this is implied by the parameter descriptions and the sibling tool context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: all three parameters (guild, source, target) have clear descriptions in the input schema. The description does not add extra parameter-level detail beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Subscribe a channel to an announcement channel') and the effect ('crossposted messages from the source appear in the target'). It uses a specific verb and resource, and this tool is distinct from siblings like crosspost_message or send_message, which handle one-off messages rather than persistent subscriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you want to set up automatic crossposting from an announcement channel to another channel. It does not explicitly mention alternatives or exclusion criteria, but the use case is unambiguous from the sibling toolset (e.g., crosspost_message is for individual posts, while this is for ongoing subscription).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already establishes this as a safe read operation. The description adds no behavioral detail beyond the purpose, such as what 'detail' includes, error handling, or prerequisites. Since annotations cover the safety profile, a neutral score is appropriate—there is no contradiction, but no extra transparency either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'One scheduled event in detail.' Every word contributes meaning, with no filler. It is extremely concise while still conveying the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with two parameters and no output schema, the description provides adequate context: it fetches one scheduled event with detail. It does not explain what 'detail' encompasses, but the purpose is clear. Given the tool's simplicity and the schema's completeness, this is sufficient, though a bit more about return contents could slightly enhance it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('event' and 'guild') having descriptions. The tool description adds nothing about parameters. Per the rubric baseline, when the schema fully documents parameters, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'One scheduled event in detail' clearly states the action (get), the resource (scheduled event), and the scope (one, in detail). It distinguishes this tool from list_events (which lists events) and get_event_attendees (which fetches attendees), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: you need a single event's detailed information. It provides clear context but does not explicitly mention alternatives or exclusions (e.g., 'use list_events for a summary'). Given the obvious sibling differentiation and straightforward nature, the usage context is clear enough to guide selection, but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already indicating a safe read operation, the description adds meaningful context by specifying exactly what is inspected (destination and usage). This goes beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that delivers complete information without fluff. No wasted words, and the structure immediately states the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description provides a clear picture of the tool's behavior. It could go slightly further by explicitly stating the return value format, but the current content ('where it leads and how used it is') sufficiently covers the expected output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter documentation, including formatting details ('with or without discord.gg/'). The description adds no extra parameter semantics beyond indicating the code is the thing being inspected, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Inspect' and clearly identifies the resource ('an invite code') and what it does ('where it leads and how used it is'). This distinguishes it from sibling tools like list_invites (listing all invites), create_invite, and delete_invite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a single invite code, but it does not provide explicit guidance on when to choose this over list_invites or other alternatives. No exclusion criteria or alternative tool names are mentioned, leaving the distinction implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation covers the safety profile. The description adds useful behavioral context: it resolves roles and overwrites, and returns results 'in plain language.' This goes beyond the annotation to describe what the tool actually computes and the nature of its output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and includes key scoping details. Every phrase adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the readOnly annotation, and full schema coverage, the description is adequately complete. It explains the core behavior and output style ('plain language'), though it does not detail the exact response shape, which is acceptable given the absence of an output schema and the tool's readability-focused purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description mentions the channel scope and server-wide behavior, which aligns with the channel parameter, but it does not add extra meaning beyond the schema's own parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning the effective permissions for a member, with the important distinction that it accounts for role and overwrite resolution. The scope options (server-wide or specific channel) are stated, and this distinguishes it from sibling tools like get_channel_permissions or explain_permissions, though it relies on the title for the verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: when you need effective member permissions after permission resolution, either server-wide or in a channel. It does not explicitly mention alternatives or exclusions, but the context is sufficient to infer its purpose relative to other permission-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true, the safety profile is covered. The description adds the grouping and filter behavior but does not mention pagination, rate limits, or other behavioral traits. This matches the bar where annotations cover the core safety and description adds some useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose and listing filter values. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two optional parameters, well-covered by the schema and read-only annotation. The description explains the return content (grouped by category, with type and topic) sufficiently for an agent to invoke it confidently. Minor gaps like pagination are not critical here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add meaning beyond the schema. The type filter is already fully described in the schema with an enum, and the guild parameter is documented in the schema. Description adds no new parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all channels in a server, grouped by category, with type and topic. This is a specific verb+resource and distinguishes from siblings like get_channel, create_channel, or list_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context that this lists all channels with optional type filtering, but does not explicitly contrast with alternatives like get_channel for a single channel or create_channel for adding channels. No explicit when-not-to-use, but the context is sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true, the safety profile is already exposed. The description adds useful behavioral context: messages are 'pending', 'timed', and returned 'soonest first'. It does not describe return format, pagination, or the effect of guild filtering, but for a simple read-only list tool this is acceptable. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the essential purpose, and includes a useful clarification about events. There is zero wasted text; every clause serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description sufficiently covers what the tool does and how it relates to schedule_message. It could explicitly mention the guild parameter's role, but since the schema already covers it, this is not a major gap. The mention of 'soonest first' conveys ordering behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter 'guild' is described in the schema as 'Guild (server) name or ID. Omit to use the default guild.' The tool description adds no additional meaning about this parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'pending timed messages waiting to send' and specifies ordering ('soonest first'), which precisely defines the tool's function. It also explicitly distinguishes from sibling 'list_events' by noting these are not Discord community events, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to view messages queued via schedule_message. It explicitly names the alternative list_events for community events, effectively telling the agent when not to use the tool. However, it does not cover all possible alternatives (e.g., list_messages for regular messages) or provide extensive usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context about hierarchy mechanics ('Higher positions sit higher in the list and outrank lower ones') beyond the annotations' readOnlyHint:false and destructiveHint:false. However, it does not disclose potential ambiguities, such as how multiple moves are applied (sequentially vs simultaneously) or what happens with conflicting positions. This leaves some behavioral gaps unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no redundant phrasing. It front-loads the primary action and quickly adds a semantic clarification, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description adequately covers the core purpose and key semantics. It explains the ordering logic and the 'one call' batching. It does not describe return values or error conditions, but given the simplicity of the tool and the annotations providing safety hints, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: 'guild' is described in the schema, and the nested 'role' and 'position' fields are also described, but the 'moves' array itself lacks a description. The description's statement about higher positions adds meaning to 'position', but it does not compensate fully for the missing top-level 'moves' description or explain the array structure beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Move roles to new hierarchy positions in one call', which is a specific verb ('move') plus resource ('roles') and scope ('hierarchy positions'). This clearly distinguishes it from sibling tools like update_role (editing role settings) or reorder_channels (reordering channels instead of roles).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when reordering roles in a server hierarchy. It says 'in one call', implying batch efficiency, but does not explicitly contrast with alternatives or mention exclusions like the need for specific permissions. No when-not-to-use guidance is given, so it stops short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a mutation (readOnlyHint false) and non-destructive behavior. The description adds the prerequisite of a gateway connection, which is useful context. However, it does not disclose potential side effects or what happens if the connection is lost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the verb 'Change'. No fluff or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with two parameters and no output schema, the description covers the essential purpose and a key requirement. It could mention the effect on existing presence, but the tool is straightforward enough that the description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes activity_text but not status. The description adds meaning by calling status a 'status dot' and activity_text 'custom status text', but it doesn't elaborate on the enum values. With 50% schema coverage, the description partially compensates but doesn't fully explain all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (change) and resource (bot's status dot and custom status text). It distinguishes itself from sibling tools like set_voice_channel_status by focusing specifically on bot presence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context by noting the gateway connection is maintained by default, implying the tool is ready to use without extra setup. No explicit alternatives or exclusions, but this is sufficient for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and not destructive. The description adds the behavioral outcome that the user 'can rejoin with an invite,' which is useful context beyond the annotations. However, it does not disclose permission requirements, what happens if the user is not banned, or audit-log implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action ('Lift a ban') and followed by the consequence. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple unban operation with a clear schema and annotations, the description is sufficient to understand the core functionality. It lacks some edge-case details (e.g., behavior when user is not banned, permission requirements), but these are not critical for a basic action of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, so the schema already explains most parameters. The description adds no additional parameter-level detail, but because the baseline is established by the schema, a score of 3 is appropriate. It does not clarify the 'guild' fallback or 'reason' usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lift a ban') and the resource/target ('the user'), making it obvious this tool reverses a ban. It naturally distinguishes from siblings like ban_member, kick_member, and timeout_member by focusing on the unban action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when a ban should be lifted so the user can rejoin. It does not explicitly mention alternatives or exclusions, but the purpose is straightforward enough that a user would not confuse it with other member-management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive write operation. The description adds some behavioral detail, such as that keywords are 'replaced' rather than appended, but does not disclose required permissions, rate limits, or any side effects beyond the immediate field changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that lists all operations without unnecessary filler. Every word adds value, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all key update actions and complements the schema and annotations well. It does not mention the return value (no output schema exists) or explicitly reference sibling tools, but the combination of description and schema is sufficient for a straightforward update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description maps clearly to the mutable parameters: 'Rename' to name, 'enable or disable' to enabled, and 'replace keyword list' to keywords. This adds meaning beyond the schema, which only describes rule, guild, and keywords explicitly. However, it does not clarify the semantics of the rule or guild parameters beyond their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Rename', 'enable or disable', 'replace') tied to the resource ('rule'), clearly distinguishing it from sibling tools like create_automod_rule and delete_automod_rule. It explicitly enumerates all supported update operations, making the tool's scope unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying an existing AutoMod rule, but does not explicitly state when to prefer this over create/delete alternatives. No exclusions or alternative tool mentions are provided, so the context is only implicit from the action verbs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a mutating but non-destructive operation. The description adds the useful constraint that tags must come from the forum's tag list, but does not mention permission requirements, error conditions, or the resulting post structure, relying on the annotations for safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single sentence that immediately states the verb and object, followed by the key components. It contains no redundant phrases or filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple creation tool, the description delivers the core purpose and key parameter distinctions. However, without an output schema, it doesn't describe what the tool returns, and it omits important operational details like permissions or whether tags are validated, making it slightly incomplete for an agent to fully understand the call's effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 60% of parameters with descriptions. The description provides additional semantics by explaining that 'content' is the opening message and 'tags' must be from the forum's tag list, filling gaps for title and content. The 'guild' parameter is not mentioned in the description but is adequately described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Start a post' in a 'forum channel', clearly identifying the action and resource. It also lists the components (title, opening message, optional tags), distinguishing it from sibling tools like reply_to_forum_post and update_forum_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the appropriate usage scenario: creating a new post in a forum channel with a title and initial content. It does not explicitly contrast this with replying, editing, or deleting posts, but the context is clear enough for the agent to select this tool when the intent is to start a new post.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false. The description adds meaningful behavioral context by clarifying that the member stays in the server and only the voice connection ends, which is not apparent from annotations alone. It could mention permission requirements or behavior if the member is not in voice, but the added value is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action verb 'Remove', and every word adds value. There is no redundancy or filler, making it highly scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two annotations and no output schema, the description covers the core behavior well. It omits edge cases like what happens if the member is not in a voice channel or required permissions, but the essential use case is fully clear. Given the simplicity, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (guild and member are described; reason is not). The description itself provides no parameter-specific guidance or clarifications, such as how defaults work or what 'member' formats are accepted. It does not compensate for the incomplete schema coverage, offering no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and resource ('member from whatever voice channel'), making the action unambiguous. The second sentence explicitly differentiates it from server removal, distinguishing it from sibling tools like kick_member and ban_member.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating the member remains in the server and only the voice connection ends, which implies when to use this tool versus more severe actions. However, it does not explicitly name alternative tools or state 'when not to use' it, though the boundary is well-implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the mutation nature is known. The description adds valuable behavioral context by explaining the platform constraint about only bot-authored messages being editable, which is not captured in annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the primary action in the first sentence and the crucial restriction in the second. Every word serves a purpose, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of rich sibling tools, the description covers the most important contextual constraint (bot-only editing). It does not discuss return values, but no output schema exists and the tool's behavior is straightforward enough that this is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter-level guidance. The schema covers 60% of parameters, leaving content and message_id undocumented. While these names are somewhat self-explanatory, the description could have clarified that content or embeds can be supplied as the replacement, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Edit a message the bot itself sent.' This clearly states the tool's action and target, and the added restriction distinguishes it from broader message tools like send_message or delete_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the key limitation: Discord does not allow editing anyone else's messages, regardless of permissions. This tells the agent when this tool can be used (only for bot-sent messages) and implicitly that alternatives must be considered for other messages. However, it does not name specific alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation. The description adds value by listing the exact fields returned (type, topic, category, slowmode, NSFW flag, permission overwrite count), which is useful. It does not disclose error behavior, rate limits, or permission requirements, but given the annotation coverage, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose ('Full detail for one channel') and then lists specific return fields. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-resource read tool, the description is complete: it states what the tool returns (detailed fields), which complements the readOnlyHint annotation and the well-documented parameters. No output schema is present, but the description effectively covers return value expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters (guild and channel) with descriptions, giving 100% coverage. The tool description does not add any additional meaning about parameter formats, defaults, or relationships beyond what the schema provides, so it stays at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving full detail for one channel, enumerating specific fields (type, topic, category, slowmode, NSFW flag, permission overwrite count). This makes the purpose unambiguous and distinguishes it from list_channels, which lists channels, and from get_channel_permissions, which focuses on permissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Full detail for one channel' provides clear context that this tool is for fetching details of a single channel, implying it is not for listing channels or for other channel-specific operations. However, it does not explicitly mention alternatives or when not to use it (e.g., 'use list_channels for summaries'), so it misses the explicit guidance level of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, covering the read-only nature. The description adds 'curated' and 'vetted' but no further behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded purpose. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does not explain what each list item contains (e.g., name, description). It mentions fetching one with get_reference_layout, implying identifiers, but lacks detail on return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description does not add parameter info but is not required. Baseline 4 for zero params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists curated server blueprints, distinguishing it from sibling tools like get_reference_layout (fetches one) and plan_server_build (stages). The verb 'list' and resource 'reference layouts' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage flow: list, fetch one with get_reference_layout, adapt, then stage with plan_server_build. It implicitly guides when to use this tool but does not explicitly state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the mutation nature is already implied. The description adds valuable behavior beyond annotations: only passed fields change, category 'none' removes the category, and dry_run is supported. This gives the agent important side-effect context. However, it doesn't disclose permission requirements or error behavior, which could be useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and each sentence contributes new information: the editable fields, the partial-update guarantee, and the dry_run capability. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and low schema coverage, the description covers the main purpose and partial-update behavior but omits details like permission requirements, return value, and exact dry_run semantics. It's adequate but not fully comprehensive for a mutation tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 38%, with no descriptions for name, topic, slowmode_seconds, nsfw, and dry_run. The description partially compensates by listing the editable fields and noting category 'none'. However, it doesn't explain dry_run's precise semantics or clarify value constraints beyond the schema. Thus it adds modest value but doesn't fully offset the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Edit a channel's name, topic, slowmode, NSFW flag, or category' with a specific verb (Edit) and resource (channel), and enumerates the editable fields. It clearly distinguishes from sibling tools like create_channel, delete_channel, and update_thread by targeting channel property edits. The partial-update qualification 'Only passed fields change' further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (to modify channel properties) and provides key usage guidance: only passed fields change, use category 'none' to remove the category, and dry_run support. It doesn't explicitly name alternative tools, but the resource scope is unambiguous. No exclusions or when-not-to-use are stated, so 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=false and destructiveHint=false. The description adds valuable behavioral context: it preflights the bot's role hierarchy to convert failures into explanations rather than 403 errors, and supports dry_run. This goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and every word earns its place. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key behavioral aspects (preflight, dry_run) and the schema fully documents parameters. With no output schema needed for a simple mutation tool, this is sufficiently complete, though it could mention prerequisites like member existing in the guild.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all five parameters, so the description does not need to add much. The mention of dry_run aligns with the schema but does not add extra meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Give a member a role' uses a specific verb ('give') and resource ('member a role'), clearly differentiating it from siblings like create_role, delete_role, and remove_role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is clear about the tool's purpose, implying when to use it (assigning a role to a member). However, it does not explicitly mention exclusions or alternatives, though the sibling list makes the context understandable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive operation. The description adds value by disclosing dry_run support and explicitly excluding permission overwrites via the 'later phase' note. It doesn't cover auth details or side effects on existing channels, but the key behavioral boundaries are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence front-loads the tool's purpose and enumerates supported types; the second adds a relevant caveat about permission overwrites and mentions dry_run. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter create tool with no output schema, the description gives essential conceptual context: channel types, category nesting, dry_run, and the permission-overwrite scope. The high-coverage schema handles parameter details. It doesn't explain the return value or permission prerequisites, but these are secondary for a create operation with these annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 88%, so the schema already documents most parameters with meaningful descriptions. The description's list of channel types mirrors the type enum, and 'optionally inside a category' restates the category parameter's purpose without adding new detail. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a text, voice, forum, stage, announcement, or category channel' – a specific verb+resource that enumerates all channel types and immediately distinguishes this from update_channel, delete_channel, and clone_channel. The option to nest inside a category further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states that permission overwrites are handled by separate permissions tools, so the agent knows this tool won't set overwrites. It also advertises dry_run for previewing. It doesn't explicitly compare to clone_channel or update_channel, but the primary 'create' use case is unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral constraints beyond the minimal annotations (readOnlyHint=false, destructiveHint=false) by specifying Discord's 256 KB file size limit and supported image formats (png, jpeg, gif, webp). It also implicitly communicates that this is a write operation via 'Upload', which is consistent with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the core action, and every word adds value. It avoids redundancy and provides essential constraints without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with no output schema, the description covers the core purpose, the source URL, and important technical limits. It lacks explicit return-value or permission details, but these are not critical for correct selection and invocation, especially given the sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% schema description coverage, the description compensates by clarifying that image_url is the source URL for the emoji. However, it does not add details for the 'name' parameter (though its purpose is obvious from the property name) or 'guild' (which already has a schema description). The description adds some meaning but not comprehensive coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Upload a custom emoji from an image URL' with a specific verb and resource, clearly distinguishing it from sibling tools like list_emojis, update_emoji, and delete_emoji. It also provides concrete context about file size and accepted formats, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for creating new emojis by uploading from a URL, and the sibling naming convention (list/update/delete emojis) reinforces when to use it. However, it does not explicitly state exclusions or name alternatives, though the context is sufficient for an AI agent to select it for emoji creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral constraint that moderated tags can only be applied by users with Manage Threads, which is not captured in the annotations (readOnlyHint=false, destructiveHint=false). It doesn't conflict with annotations and provides useful context about permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and a caveat. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and the key permission nuance for moderated tags. It doesn't explain return values, but for a simple create operation with no output schema, this is acceptable. Missing details about duplicates or default moderated behavior are minor given the schema already provides type constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has descriptions for only 2 of 4 parameters (forum and guild), leaving name and moderated undocumented. The description partially compensates by explaining that moderated tags require Manage Threads permission, giving meaning to the 'moderated' parameter, but it doesn't clarify the name parameter's semantics or format beyond schema constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Add' with a specific resource 'a tag to a forum's tag list,' clearly distinguishing from sibling tools like update_forum_tag and delete_forum_tag. It also scopes to the forum's tag list, making the action unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states that moderated tags require Manage Threads permission, giving a clear prerequisite for a subset of uses. However, it doesn't explicitly mention when to prefer this over update_forum_tag or delete_forum_tag, so it lacks explicit alternatives/exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only indicate readOnlyHint=false and destructiveHint=false, so the description carries some burden. It adds that the poll is a "native Discord poll" and specifies answer/duration limits, but it does not disclose potential side effects (e.g., message sent to channel, permission requirements, error conditions). This is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the verb "Post," and every word contributes meaning. It efficiently communicates the primary action and essential constraints without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (7 parameters, no output schema), the description captures the core purpose and key limits. It could mention the return value or permission requirements, but the schema and context cover most details. For a creation tool, the description is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 71% of parameters with descriptions. The description adds semantic meaning by clarifying the role of key parameters: the question is a poll question, answers are choices (2-10), and duration is capped at 32 days. This goes beyond the schema's raw constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: "Post a native Discord poll" with specific constraints on question, answers (2-10), and duration (up to 32 days). This distinguishes it from sibling tools like get_poll_results and end_poll, which handle retrieval and termination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context of when to use this tool is clear — to create and post a poll in Discord. However, it does not explicitly mention when not to use it or provide alternative tool names (e.g., send_message or create_event), so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint=false, destructiveHint=false) are minimal, so the description carries more weight. It adds valuable behavioral context such as supported formats, maximum size/duration, and server slot limits, which are not in the annotations. It does not disclose error handling or return format, but the provided details go beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and contains no fluff. Every sentence provides useful information: the first states the purpose and constraints, the second addresses capacity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with no output schema, the description covers core usage and constraints well. It could have mentioned the return value or the default guild behavior more explicitly, but the schema covers the guild default and the overall guidance is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60%. The description adds specific semantics for sound_url (formats, size, duration limits), but does not elaborate on name, emoji, guild, or volume. The schema already provides descriptions for emoji, guild, and volume, so the description offers modest additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Upload' and clearly identifies the resource as a 'soundboard sound', differentiating it from sibling tools like list/update/delete_soundboard_sound. It also specifies the source (audio URL) and the action (creating a new sound).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (creating a sound from a URL) and includes important constraints (mp3/ogg, size/duration limits) and capacity guidance (eight slots, boosts add more). It does not explicitly mention alternatives or exclusions, but the context is sufficient for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations reveal that the tool is neither read-only (readOnlyHint: false) nor destructive (destructiveHint: false). The description adds behavioral context: 'early' indicates a timing nuance and 'finalize the results' implies votes stop being accepted and results are computed, which is not fully captured by annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence with the verb 'Close' front-loaded. Every word adds value, no redundancy, and the structure is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple state-changing action, the description covers the essential behavior. No output schema exists, but the result (finalized results) is implied. One minor gap: it doesn't mention permissions or that the action is irreversible, but the annotations and clarity of scope keep it adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific details. The input schema covers guild and channel descriptions but leaves message_id undefined. With 67% schema coverage, the baseline is 3, and the description does not compensate for the missing message_id explanation, though the parameter name is fairly intuitive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Close one of the bot's own polls early and finalize the results.' It identifies the resource (polls), the operation (close early, finalize), and a scope constraint (the bot's own polls), distinguishing it from create_poll and get_poll_results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: ending a poll before its natural conclusion. It also sets a constraint ('one of the bot's own polls') that helps exclude inappropriate usage. However, it does not explicitly mention alternatives or when not to use it, but the clarity of purpose compensates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint annotation already establishing safety, the description adds useful behavioral context: results are 'ranked candidates' and include IDs, and the search spans multiple entity types. It doesn't mention pagination or rate limits, but the annotation lowers the bar and the added context is meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the first states the core function, the second gives the use case. Everything earns its place; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with a clear input schema and read-only annotation. The description explains the output (ranked candidates with IDs) and the optional guild semantics are covered in the schema. It's complete enough for effective selection and invocation, though pagination or result limits are not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces the meaning of query as a 'name fragment' and types as channels/roles/members, but doesn't add significant new details beyond the schema. It's adequate but not additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly and specifically states what the tool does: a 'Universal name resolver' that takes a name fragment and returns ranked candidates across channels, roles, and members with IDs. This distinct verb and resource make it easy to differentiate from siblings like search_members or list_channels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when unsure what an entity is called or to grab an ID once and reuse it,' giving a clear trigger for when to invoke the tool. It doesn't explicitly state when not to use it or name alternatives, but the guidance is strong and immediately actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds valuable context by listing the return fields (identity, nickname, roles by name, join date, timeout state) and the input flexibility (user ID or name), going beyond the annotation. It does not contradict annotations, though it omits edge-case behavior like not-found errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, information-dense sentences. The first sentence front-loads the core purpose and return fields; the second covers input flexibility. There is no filler or repetition of schema/annotation data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description appropriately summarizes key return fields and input options, giving the agent a good understanding of what to expect. It could improve by noting behavior when the member is not found, but for a simple read-only getter with robust annotations, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters already well-described ('Member name or user ID' and 'Guild name or ID. Omit to use the default guild'). The description's 'Accepts a user ID or a name' merely reinforces the schema and adds no new meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'One member in detail' and enumerates the specific data returned (identity, nickname, roles by name, join date, timeout state), making the tool's purpose unambiguous. This distinguishes it from siblings like list_members (lists all members) and search_members (searches), and from get_role_members (fetches members of a role).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use the tool: when you need detailed information about a single member. It also states the input format ('Accepts a user ID or a name') which gives clear usage context. However, it does not explicitly name alternative tools or state when not to use it, so it doesn't fully satisfy the 'explicit when/when-not/alternatives' criterion for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds important behavioral detail: the tool clears buffered events after reading. This is a side effect not fully captured by annotations (readOnlyHint=false hints at mutation, but 'clear' specifies the exact mutation). Also discloses 'oldest first' ordering. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the main verb, no unnecessary words. It delivers the key information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers the primary behavior (read, clear, ordering). It could mention return format or pagination, but those are less critical given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes 'limit' (max 100, default 25) but not 'subscription_id'. The description adds slight context ('from a subscription') but does not fully compensate for the missing parameter description. Since coverage is only 50%, the description could do more to clarify parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States 'Read and clear buffered events from a subscription, oldest first.' This provides a specific verb ('read and clear'), the target resource ('buffered events from a subscription'), and ordering ('oldest first'). It clearly distinguishes from siblings like list_events or get_event by emphasizing the subscription buffer and the clearing behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when you need to consume events from a subscription and clear the buffer. It is clear about the scenario but does not explicitly contrast with alternatives like list_events or mention when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true, the annotation already covers safety, and the description adds valuable context about what the tool actually returns: the blueprint plus reasoning. It also gives a behavioral directive for using the output, which goes beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences: one states the tool's output, the other provides adaptation guidance. Every word earns its place, and the content is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only get tool with one parameter and no output schema, the description is sufficient. It tells the agent what content to expect (blueprint + reasoning) and how to apply it. It doesn't detail the exact structure of a reference layout, but that's not critical for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter layout_id with a clear source reference (from list_reference_layouts). The description does not add any additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool returns one full reference layout, including the blueprint and the reasoning behind its structure. This distinguishes it from list_reference_layouts (which lists layouts) and other get operations like get_blueprint, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear guidance on how to use the returned layout: adapt it rather than applying it verbatim, prioritizing user theme and wording. It doesn't explicitly mention when to use this tool versus alternatives, but the context of listing first is implied via the parameter description and sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds behavioral details: roles are sorted highest-first, and include color, position, and a permission digest, which helps the agent know what to expect beyond the read-only tag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with specific, useful details, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one optional parameter, the description captures the return contents and ordering. Since there's no output schema, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (guild) is fully documented in the schema with default behavior. The description doesn't add parameter-specific info, but schema coverage is 100%, so this is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List') and resource ('roles in a server'), along with sorting and included fields. It distinguishes from sibling role tools like create_role/update_role/delete_role and get_role_members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing role overviews with ordering and permission summaries, but does not explicitly mention alternatives or exclusions. It's clear enough context for a simple read tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals safety, and the description adds valuable behavioral detail about active vs. archived threads and the channel requirement for archived ones. It explains the server/channel scoping without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the main purpose and no filler. Every clause adds information about scope or archived behavior, making it compact and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three optional parameters and a read-only hint, the description covers the core usage scenario well. It doesn't describe return format or pagination, but the absence of an output schema makes that a minor gap for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all three parameters with descriptions (100% coverage), so the description adds little beyond restating the include_archived-channel relationship. The added value is minimal, but it reinforces the constraint that archived threads require a channel.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action with specific scope: 'Active threads across the server or one channel.' It also distinguishes itself from sibling tools like get_thread or list_thread_members by focusing on listing threads at server/channel level, and the archived-thread nuance adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: for active threads across a server or channel, and for archived threads when include_archived is set with a channel. It does not explicitly name alternatives or exclusions, but the use case is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only (readOnlyHint: false). The description adds useful behavioral context beyond annotations: the specific permission required and the channel's maximum pin count. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no redundancy. The first sentence is the core purpose, and the following sentences add relevant constraints (permission, pin limit). Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple pin operation, the description covers the essential context: purpose, permission requirement, and the 50-pin limit. It does not explain edge cases like duplicate pins or behavior when the limit is reached, but the tool is simple enough that this is acceptable given the annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with guild and channel described. The description does not add parameter-specific details for reason or message_id, but these are self-explanatory. The description adds minimal parameter semantics beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Pin a message in a channel,' which is a specific verb+resource construction. It clearly distinguishes from sibling tools like unpin_message and list_pinned_messages by focusing on the act of pinning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when the tool is applicable by stating the required permission and the 50-pin limit. It does not explicitly mention alternatives or when not to use it, but the sibling names make the distinction obvious, so no exclusions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the destructive annotation by disclosing the two-phase behavior: the first call only counts members and returns a token, while the second call actually prunes. This adds essential context not present in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the core action and then explain the safe two-step process. No wasted words; the description earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, no output schema), the description covers the key behavioral flow (preview-then-confirm) but does not specify the exact return format beyond mention of a count and token. Enough for a competent agent to operate correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40%, so the description must compensate. It explains the confirm_token flow and implies the days parameter, but it does not clarify the dry_run boolean's relationship to the token flow, nor does it explain the reason parameter. The description adds some meaning but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes members who are inactive for a given number of days and hold no roles. This precise verb-resource pair distinguishes it from sibling tools like kick_member or ban_member, which target specific members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool safely: the first call is a preview that returns a confirm_token, and the second call with the token performs the actual prune. It does not explicitly compare to alternatives, but the two-step flow is practical usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutation (readOnlyHint=false) but not destructive (destructiveHint=false). The description adds valuable context by disclosing the permission requirement (Manage Messages) and the default target (bot's own reaction), going beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 17 words, front-loaded with the action ('Remove a reaction'), and contains no redundant or extraneous information. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has annotations covering safety, and the description covers purpose, default behavior, and permissions. It does not explicitly mention what happens if the reaction does not exist or suggest when to use clear_reactions instead, but the absence of an output schema and the straightforward nature of the operation make this adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 60% of parameters (user, guild, channel), and the description essentially restates the 'user' parameter's default behavior already present in the schema. It does not add new meaning for emoji or message_id, which lack schema descriptions. Since coverage is moderate and the tool is straightforward, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Remove') and resource ('a reaction'), and includes the default behavior (bot's own) as well as the permission requirement for removing others' reactions. It distinguishes itself from sibling tools like add_reactions, clear_reactions, and get_reactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: for removing the bot's own reaction by default, and for removing another user's reaction if the bot has Manage Messages permission. However, it does not explicitly mention alternatives such as clear_reactions for bulk removal, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds behavioral context by stating it 'preflights the bot's role hierarchy so a failure is an explanation, not a 403,' which discloses a meaningful implementation detail that affects error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action and a concise behavioral note. Every word earns its place with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward role-removal tool with clear schema coverage and annotations, the description is sufficient. It covers the core function and an important behavioral detail; no output schema exists, so return values don't need explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% with descriptions for role, guild, and member; the description itself does not elaborate on parameter usage. The schema already explains names/IDs, and reason is self-explanatory, so the description adds no extra meaning but doesn't need to compensate significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'Take a role away from a member.' This clearly distinguishes it from sibling tools like assign_role (giving a role) and delete_role (deleting the role entirely).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool—whenever a role needs to be removed from a member—but does not explicitly name alternatives or exclusions. The preflight note adds context about error handling, which helps the agent understand expected behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only indicate readOnlyHint=false and destructiveHint=false, so the description carries part of the transparency burden. It adds useful context about mentions being suppressed by default and dry_run support, but does not disclose other behaviors such as permission requirements, rate limits, or response format. This is adequate but has gaps, warranting a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences. The first sentence states the primary action and optional features, the second efficiently lists alternatives, and the third provides a key behavioral warning about mentions. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's core purpose, key alternatives, and important behavioral details (mentions, dry_run). Given 8 parameters and no output schema, it provides enough context for an agent to select and invoke the tool correctly, though it could mention what the response contains or error conditions, but those are not essential for a send operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters well. The description adds only marginal value by restating mentions default and dry_run, which the schema also covers ('Which mention types may ping. Default none.' and 'Preview without sending.'). Since the schema carries the heavy lifting, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Send a message to a channel, optionally as a reply or with embeds.' It uses a specific verb (send) with a clear resource (message to a channel) and distinguishes from sibling tools by naming send_dm, send_webhook_message, and schedule_message as alternatives for different use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by naming alternatives: 'For a private message to one person use send_dm; to post under a custom name and avatar use send_webhook_message; to send later use schedule_message.' It also notes the default behavior for mentions and the existence of dry_run, giving clear context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a mutating, non-destructive action. The description adds a useful post-condition: 'Members can then be invited to speak.' This goes beyond annotations, though it does not disclose permissions or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. The first states the main action and prerequisite, the second adds a consequence. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description covers the core behavior and post-condition adequately. It omits explicit alternatives, but that is more a usage guideline issue than completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, with descriptions for guild, notify, and channel. The description reinforces the purpose of channel and topic but does not elaborate on guild or notify beyond the schema. Modest value added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Open' with resource 'live stage' and adds context about inviting members. This clearly distinguishes from sibling tools like end_stage and update_stage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for starting a new stage on a stage channel, but it does not explicitly state when not to use it or mention alternative tools. The context is clear, but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant context beyond annotations by disclosing that omitted fields are preserved and that options replacement is wholesale. This warns of potentially destructive behavior, which is not captured by readOnlyHint/destructiveHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the verb and resource. Each sentence provides essential information without redundancy, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity mutation tool with no output schema, the description covers purpose, partial updates, and the critical options-replacement caveat. It lacks return-value details but is otherwise sufficient given the rich schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 adds useful partial-update semantics ('Anything not passed is left as it is') that clarify behavior for both description and options parameters, going slightly beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Change') and the resource ('a registered command's description or options'). It distinguishes from siblings like register_app_command and delete_app_command by focusing on modification of existing commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating existing commands ('registered command') but does not explicitly mention alternatives or exclusions. It provides partial-update guidance but lacks a direct comparison with register_app_command or delete_app_command.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only flag readOnlyHint and destructiveHint as false; the description adds behavioral caveats such as voice changes requiring the member to be connected to voice. It doesn't mention permission requirements or reversibility, but the added context is meaningful beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, no redundant information. The structure is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's main purpose and key limitation (voice-only changes), and the schema fills in parameter details. For a mutation tool without output schema, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 57%, with guild, member, nickname, and move_to_voice described. The description adds clarity by grouping server_mute/server_deafen/move_to_voice as voice changes, but doesn't detail reason or boolean semantics beyond parameter names. Baseline 3 is appropriate as the description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Edit a member's nickname or voice state' with a specific verb and resource, and distinguishes from role changes by pointing to assign_role/remove_role. It is unambiguous and differentiates from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance that role changes belong in assign_role/remove_role, and notes voice changes only apply while connected, giving context for when the tool is applicable. However, it doesn't outline all scenarios or prerequisites beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds that only passed fields change, indicating a non-destructive partial update. It also notes that descriptions require a Community server, a useful prerequisite. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, information-dense sentences, with the main action first and no redundant text. The conditional about Community servers is placed at the end appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter update tool, the description covers the key behavior and a prerequisite, but it does not mention the dry_run parameter or what the tool returns. Given no output schema, a brief note on the return value would improve completeness, though the tool is still usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 55%, the description helps by mapping listed fields to parameters like name, description, afk_timeout_seconds, and verification_level. However, it omits dry_run and guild, and does not fully compensate for the undocumented parameters; schema descriptions cover some of these fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool edits server settings and enumerates specific settings (name, description, AFK behavior, channels, verification level). This distinguishes it from sibling tools like update_server_widget or update_onboarding by focusing on core server configuration fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for modifying general server settings and clarifies partial-update semantics ('Only passed fields change'). It does not explicitly discuss when not to use it or alternatives, but the context is clear enough for an agent to select it over other update tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive mutation. The description adds the specific operations (enable/disable, set invite channel) but does not disclose details like whether operations are mutually exclusive or what happens on partial updates. It meets the lower bar set by annotations but does not add rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the main purpose, and contains no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with no output schema and three optional parameters, the description covers the core functionality adequately. It does not explain return values or edge cases, but these are not critical for an update operation. The presence of annotations for safety covers the main contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (guild and channel have descriptions, enabled does not). The description compensates by explaining 'enabled' as 'enable or disable the widget' and 'channel' as 'point its invite channel', adding meaning beyond the schema. This improves parameter understanding, especially for the undocumented boolean.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Enable or disable the widget, or point its invite channel.' It uses specific verbs and the resource (server widget), distinguishing it from siblings like get_server_widget (read-only) and update_server (general server settings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for modifying the server widget specifically. However, it does not explicitly mention when to use this over other update tools or provide exclusions. The description implies its usage by naming the exact actions, so it provides clear context without explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false. The description adds value by enumerating what is updated (rename, archive status, lock status, slowmode, auto-archive window), which gives the agent a clear picture of the tool's behavior without needing to infer from schema. However, it does not disclose potential side effects or permission requirements, so it falls short of 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that lists all update types in a structured way. It contains no filler or redundant information, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and no output schema, the description covers the main capabilities but omits any mention of return values, prerequisites, or edge cases (e.g., whether locking affects archiving). The schema covers identifiers, and the description is sufficient for a moderate-complexity tool, but a note on when to use this versus thread-related siblings would have improved completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 29%, with only guild and thread having descriptions. The description compensates well by paraphrasing the remaining parameters: 'rename' maps to name, 'archive/unarchive' to archived, 'lock/unlock' to locked, 'slowmode' to slowmode_seconds, and 'auto-archive window' to auto_archive_minutes. This adds meaning beyond the sparse schema, though it does not explicitly mention guild or thread.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Rename' and enumerates concrete actions (archive/unarchive, lock/unlock, slowmode, auto-archive) on the 'thread' resource. This clearly distinguishes it from sibling tools like update_forum_post or update_channel by focusing on thread-specific settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying thread properties but provides no explicit context on when to choose this over alternatives like update_forum_post or when not to use it. There is no mention of exclusions or prerequisites, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the specific fields that can be changed but does not disclose whether the update is partial or full, nor any permission requirements. It adds some value beyond annotations but leaves room for behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core actions. It is information-dense with zero wasted words, and each element adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with five parameters and no output schema, the description covers the main use cases (rename, avatar, move channel). The schema handles the required 'webhook' parameter and guild default behavior. It lacks explicit mention of partial-update semantics, but the tool is straightforward enough that the description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description bridges the gap for parameters not covered by the schema: 'rename' maps to 'name', 'change avatar' maps to 'avatar_url', and 'move' maps to 'channel'. This compensates for the schema's 60% description coverage, making the parameters more meaningful than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('rename', 'change', 'move') tied to the resource ('webhook') and clearly distinguishes this tool from siblings like create_webhook, delete_webhook, and send_webhook_message by listing concrete update operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear this tool is for modifying an existing webhook, with no ambiguity about when to use it. It doesn't explicitly exclude other operations or name alternatives, but the context is strong enough that an agent would know to use it for renaming, changing avatars, or moving channels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that rules run on Discord's infrastructure, explains action limitations (timeout unavailable on spam/keyword_preset/member_profile), and clarifies that blocking on member_profile quarantines the member. Since annotations only indicate readOnlyHint=false and destructiveHint=false, the description carries the burden and does so well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but information-dense, covering multiple trigger types, actions, and constraints without repeating the schema verbatim. It is structured with clear sentences and semicolons, earning its length for a tool with 14 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 params, no output schema), the description covers operational context, trigger categories, action options, and usage preferences. It does not mention return values, but this is a minor gap for a creation tool where the outcome is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds semantic value beyond the schema by explaining why presets are useful ('Discord maintains the word list, so none needs to be written') and detailing how actions behave across trigger types. With 71% schema coverage, the description fills gaps and deepens understanding of parameter interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a server-side moderation rule, enumerates all trigger types (keyword, keyword_preset, spam, mention_spam, member_profile), and distinguishes it from sibling tools like update_automod_rule and delete_automod_rule by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'For slur or hate-speech filtering prefer trigger keyword_preset with the slurs preset' and notes that member_profile is for Community servers only. Also gives important constraints like timeout not being available on certain triggers, though it doesn't explicitly contrast with updating/deleting rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which covers the safe read-only nature, but the description adds valuable detail about the output categories: 'missing', 'changed (with the fields)', and 'extra (informational)'. This tells the agent what kind of data to expect, going beyond merely saying 'Compare'. It does not mention rate limits or error conditions, but the read-only annotation lowers the bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first packs all functional details, the second is a memorable tagline ('The drift detector for config-as-code workflows'). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by clearly enumerating the three result categories (missing, changed, extra) and their nature, which is the core of what the tool returns. Combined with the read-only annotation and full schema parameter coverage, this provides a complete and actionable tool definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions (guild: 'Guild (server) name or ID...' and blueprint: 'Saved blueprint name or ID.'), and schema coverage is 100%. The description adds no additional parameter semantics, which is acceptable given the schema already documents them; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Compare') and identifies the exact resources ('a saved blueprint against the live server'), then clarifies the comparison categories (missing, changed, extra). This clearly differentiates it from sibling blueprint management tools (list_blueprints, get_blueprint, save_blueprint, delete_blueprint, export_server_blueprint).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context—detecting drift in config-as-code workflows—and indicates the output is a comparison, implying when to use it (before syncing/applying). However, it does not explicitly name alternatives or exclusions, such as when to use sync_server_template or plan_server_build instead, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, and the description adds behavioral detail about what is returned (full message with specific components). This goes beyond the annotation by disclosing the output scope, which is helpful for the agent. No contradictions, and the read-only nature is consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action ('Fetch one message in full') and lists return fields concisely. No wasted words, and every element adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-message fetch with existing annotations and a schema, the description is complete. It specifies what is returned, and the absence of an output schema is mitigated by the explicit list of returned fields. No additional context is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 67% of parameters with descriptions for guild and channel. The description does not add any parameter-level semantics beyond what the schema provides; message_id is self-explanatory. Since coverage is not high (>80%), the description could have compensated, but it doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('one message') and enumerates the included fields (author, content, timestamps, attachments, embeds, reactions, reply reference). This clearly distinguishes it from sibling tools like read_messages (list) and search_messages (search) by focusing on a single message retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this to fetch a single message in full, as implied by 'one message' and the required message_id parameter. It does not explicitly name alternatives or state when not to use, but the sibling list and parameter requirements make the usage apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, and the description reinforces this with the word 'snapshot'. It adds value by detailing the exact data included, which the annotation does not cover. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the snapshot contents and followed by a single, practical usage recommendation. Every sentence contributes meaning with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description covers the return contents explicitly and also gives situational guidance. For a low-complexity tool with one optional parameter and a read-only annotation, this is complete and sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full description of the only parameter (`guild`), and the tool description adds no extra parameter semantics. Per the baseline rule, this is a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as a 'Structured snapshot of a server' and lists the specific contents (identity, member counts, boost status, channel outline, role count). This distinguishes it from sibling tools like get_server_preview or get_server_widget, which focus on narrower aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'The natural first call when starting work on a server' provides clear context for when to use the tool. However, it does not explicitly mention when not to use it or name alternatives, so it misses the full 'when/when-not/alternatives' criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this as a safe read operation. The description adds value by mentioning that results are paginated and include reasons, which are behavioral traits not covered by the annotation. This gives the agent useful expectations for the response shape without contradicting 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extraordinarily concise at only four words, yet it effectively communicates the tool's function, output content, and pagination behavior. Every word earns its place, with no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only listing tool with all-optional parameters and a full schema, the description covers the essential information: what is being listed (current bans), what is included (reasons), and how it is delivered (paged). No output schema exists, but the description gives enough context for the agent to know what to expect. The tool is simple enough that no further detail is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all three parameters (after, guild, limit) are documented in the input schema. The description's mention of 'paged' loosely aligns with the 'after' and 'limit' parameters, but it does not add any new semantic detail beyond what the schema already provides. Hence, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Current bans with reasons, paged.' clearly states the tool's purpose: listing active bans with their reasons and pagination. The verb 'list' plus resource 'bans' is specific and distinct from sibling tools like 'ban_member' or 'unban_member', which are actions. It avoids tautology by adding detail about content and pagination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Current bans' provides clear context that this tool is for viewing active bans (as opposed to audit logs or historical actions), and 'paged' indicates how to handle large result sets. While no explicit alternatives are named, the description implies the correct usage scenario without unnecessary exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint, and the description adds valuable context beyond that: it explains the data source (live gateway presence) and a freshness caveat (time since Omnicord connected). This extra information is not available in the annotations alone and helps set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the first sentence giving the core purpose and the second adding a critical behavioral caveat. Every word earns its place, and it is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with only two parameters, the description is sufficiently complete. It covers the purpose, the exact resource scope, and the freshness caveat. An output schema is absent, but the description implies return fields (members with mute/deafen state), which is enough for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for both guild and channel parameters (100% coverage). The tool description does not add further parameter-level details, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'list' and identifies the exact resource: members currently in a voice or stage channel. It includes the additional scope of mute/deafen state, which clearly distinguishes it from general member list tools like list_members or get_role_members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool (to check current voice/stage presence) and provides context that it reads live gateway presence reflecting time since connection. However, it does not explicitly name alternatives or state when not to use it, leaving some implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating but non-destructive operation. The description adds valuable context by revealing that existing role overwrites can still allow posting, meaning moderators may keep access. It does not cover auth requirements or rate limits, but for this simple mutation the added nuance is useful and goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, front-loaded with the core action, and every sentence earns its place. It efficiently states the purpose, the important caveat about overwrites, and the reverse operation without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with full annotations and a clear schema, the description is complete. It explains the effect, the critical exception (role overwrites), and how to undo it. No output schema exists, so return values are not required, and the description covers all necessary operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, so guild and channel parameters are sufficiently described in the schema. The description adds no parameter-level details and does not clarify the reason parameter, but the schema gap is minor since 'reason' is self-explanatory. Overall the description provides marginal added value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (lock a channel) and the mechanism (denying everyone the ability to send messages). It also distinguishes this tool from siblings like unlock_channel and set_channel_permissions by specifying the nuance that existing role overwrites still apply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to lock a channel) and explicitly mentions the reverse operation with unlock_channel, but it does not compare with alternative permission tools like set_channel_permissions or clear_channel_permissions. It gives clear context but no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only and non-destructive, and the description adds valuable context: it fails gracefully when the recipient has DMs closed, and the message always comes from the bot, never a user account. This goes beyond the structured annotations and clarifies important operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, followed by two concise behavioral notes. Every sentence adds value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple DM tool with annotations and partial schema documentation, the description covers purpose, recipient constraint, failure mode, and message source. No output schema exists, so return values need not be explained. The description is complete and sufficient for an agent to select and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (user and guild documented, content not). The description adds meaning by specifying the user must share a server with the bot, which reinforces the user parameter. Content is self-explanatory despite lacking schema documentation. Moderate value added, not fully compensating for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send a direct message') and specifies the recipient ('a member who shares a server with it') and source ('from the bot'), which distinguishes it from channel-sending tools like send_message. The verb+resource structure is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: for direct messages to a member sharing a server, and notes a prerequisite (shared server) and failure behavior (graceful when DMs closed). However, it does not explicitly mention alternatives or when not to use it, though the differentiation from send_message is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only and not destructive. The description adds context that starting a recording creates a buffer and that events are then read with get_recent_events. While it does not explicitly detail the subscription lifecycle (such as how to stop with unsubscribe_events), the behavioral overview is solid and does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a bit long with the event type list, but every sentence earns its place: it starts with a memorable hook, then states the action, buffer usage, exclusions, and enumerates available types. The structure is front-loaded and understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate parameter count, the description covers the core use case, the event types, and the interaction with get_recent_events. It does not discuss how to stop the subscription or buffer limits, but the sibling tool unsubscribe_events is present and the annotations cover safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all parameters with 100% description coverage, so the baseline is 3. The description repeats the event type enumeration and explains the buffer concept, but it does not add new parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('start recording real-time activity') and resource ('server live activity'), and distinguishes it from related tools by naming create_event and schedule_message as alternatives. It also links to the companion read tool get_recent_events, making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool ('Use this to observe what is going on now') and when not to ('It is not for scheduled community events (create_event) or timed messages (schedule_message)'). It also directs the user to the companion tool get_recent_events for reading the buffered events, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only and non-destructive. The description adds specific behavioral context by naming the exact permission overwrite modified (everyone overwrite) and the action (removing denial), which is valuable beyond annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence effectively explains the tool's purpose and action. Every word contributes value, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with clear annotations, the description fully covers the tool's behavior without needing an output schema. It states the exact change performed, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for 'guild' and 'channel' (67% coverage), and the description does not explain parameters further. 'reason' lacks a description, but the described action is simple enough that the schema covers most meaning. No additional parameter semantics are added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Reverse' with a clear resource ('lock_channel') and explains the mechanism ('removing the send-message denial from the everyone overwrite'). This unambiguously identifies the tool's function and differentiates it from siblings like 'lock_channel'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as the counterpart to 'lock_channel'—use when you need to undo a channel lock. It does not explicitly exclude cases or mention alternatives, but the context is clear and sufficient for the tool's simple scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals a critical two-phase behavior (preview with confirm_token, then execution) that is not visible in the schema or annotations. It also discloses that it reports per-ban success/failure, going well beyond the destructiveHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no redundancy, front-loaded with the core purpose. The safety preview behavior is explained in a compact, highly readable way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior, limits, and output. It could additionally mention edge cases like invalid IDs or rate limits, but for the tool's complexity, the provided information is sufficient to call it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%), so the description must compensate. It clarifies the confirm_token flow and the 200-user limit, but it does not explain optional parameters like reason or delete_message_seconds, leaving some semantics to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Ban'), resource ('users'), scope ('up to 200, by ID'), and context ('raid cleanup'). This clearly distinguishes it from sibling tools like ban_member and prune_members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('raid cleanup') and explains the safe two-step invocation pattern. However, it does not explicitly name alternatives or state when not to use it, so it falls 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses the two-phase commit (first returns count and confirm_token, second applies) and the 3000-member cap with reporting. These behavioral details go far beyond the annotations, explaining why the destructive action is 'safe to call directly' and how it handles large member sets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose. Each sentence adds unique value: the operation, the safety mechanism, and the cap/limit. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 params, nested filter, no output schema), the description covers the core operation, safety flow, and limit. It reports the affected count and token return. It could mention dry_run or error behavior, but the essentials are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains confirm_token's role and the member cap, adding meaning beyond the schema. However, it does not elaborate on filter, dry_run, or action semantics. With schema description coverage at 33%, the description partially compensates but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add or remove a role across every member matching a filter,' identifying the specific verb, resource, and scope. It distinguishes from sibling single-member tools like assign_role and remove_role by emphasizing the bulk operation across filtered members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for bulk role changes on a filtered member set. It provides guidance on how to call safely via the two-phase token process. However, it does not explicitly name alternatives or state when not to use, though the bulk scope is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description explains that the first call changes nothing and returns a preview and confirm_token, with cancellation only happening on the second call. It also discloses the impact on interested members. This is rich behavioral context that matches and expands on the destructive hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant phrasing. The first sentence states the action and consequence; the second explains the important safety flow. Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core workflow, the two-step confirmation, and the main consequence. It does not address error cases (e.g., invalid token, nonexistent event) or permissions, but for a destructive tool with confirmation, the essential context is present. Given the absence of an output schema, the mention of preview and confirm_token is valuable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (event and guild have descriptions). The tool description clarifies the confirm_token parameter by explaining its role in the second call, and implies preview behavior. However, dry_run remains undocumented in both schema and description, leaving its exact relationship to the preview unclear. Partial compensation but with a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action: 'Cancel and remove a scheduled event.' It clearly identifies the resource (scheduled event) and the verb (cancel/remove), distinguishing it from update_event or other event tools. The consequence 'Interested members lose the listing' reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance through the two-step confirmation flow: first call returns a preview and confirm_token, second call with token cancels. It also states 'Safe to call directly' to set expectations. It does not name alternatives, but given the sibling list lacks a delete_event, this is clearly the cancellation tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only mark the tool as non-readOnly and non-destructive. The description adds useful behavioral context: defaults are deliberate, invites expire in 24 hours, are unlimited by default, and max_age_seconds 0 is required for never-expiring invites. It doesn't cover permissions or return format, but it provides meaningful detail beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence states the purpose, and the second highlights the key defaults and parameter behavior, so every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with a fully described schema, this description is sufficient: it tells the agent what the tool produces (an invite link) and the important defaults. It doesn't specify the exact response payload, but no output schema exists and the purpose clearly implies the returned resource.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all 5 parameters with 100% coverage, so the baseline is 3. The description adds value by emphasizing the deliberate defaults and explicitly instructing that max_age_seconds 0 is needed for never-expiring invites, which clarifies intent beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' and resource 'invite link for a channel', immediately establishing what the tool does. It also states key defaults, distinguishing it from sibling invite tools like list_invites, get_invite, and delete_invite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool — to create an invite link for a channel — and explains the deliberate default lifetime and use limits, including how to request a never-expiring invite. It doesn't explicitly mention when not to use it or compare to alternatives, but no true alternative creation tool exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive operation. The description adds meaningful behavioral context: the admin permission is never granted via preset and must be explicitly included, and dry_run enables previewing without creation. This goes beyond the structured fields and alerts the agent to a non-obvious security nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each carrying essential information: the creation mechanism, the admin exception, and dry_run support. There is no redundancy or filler, and the main purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, one required, and no output schema, the description covers the central decisions (preset vs explicit permissions) and the dry_run option. It omits return-value details and error conditions, but given strong schema descriptions and the non-destructive write nature, it is sufficiently complete for agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 88%, so the baseline is 3. The description adds value by clarifying that the 'admin' preset does not automatically include the Administrator permission; it must be listed explicitly in the permissions array. This detail is not evident from the schema's preset enum or permissions description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Create a role') and details the two input mechanisms: a vetted preset or an explicit permission list. It clearly differentiates from sibling tools like list_roles, update_role, and delete_role by focusing solely on creation. The admin caveat adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context is provided for when to use this tool: to create a role using presets or explicit permissions. The description notes that Administrator must be explicitly specified rather than assumed from a preset, which guides correct usage. However, it does not explicitly mention alternatives like update_role or clone_role, nor state scenarios where this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description adds crucial context: the two-phase deletion process, the immediate effect ('its protection stops immediately'), and that the first call is non-destructive. This goes beyond simple destructive intent and informs the agent about the safe invocation path. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a purpose: stating the action and effect, explaining the safe call pattern, and offering an alternative. It is concise, front-loaded, and free of redundant wording, making it easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool, the description covers the essential context: what it does, immediate consequences, the safe two-step protocol with a returned token, and a reversible alternative. It does not detail the dry_run behavior or preview contents, but with no output schema, it still gives the agent enough to invoke correctly. Slight gap in not explaining all parameters, but overall complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, covering rule and guild. The description compensates partially by explaining the confirm_token's role in the two-step delete flow, which is not documented in the schema. However, it does not address the dry_run parameter, so the description does not fully fill the gap. A score of 3 reflects partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Delete an AutoMod rule; its protection stops immediately,' using a specific verb and resource. This clearly distinguishes it from siblings like update_automod_rule and create_automod_rule. The confirmation flow detail adds further specificity, ensuring no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when and how to use the tool: 'Safe to call directly: the first call changes nothing and returns a preview plus a confirm_token; repeating the call with the token deletes it.' It also names the reversible alternative with 'Disabling is the reversible alternative,' giving the agent clear guidance on choosing between deletion and disabling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds critical context beyond the annotations (destructiveHint=true) by explaining that the first call is safe and changes nothing, returning a preview and confirm_token. It also discloses that servers built from the blueprint are unaffected, which is valuable behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no superfluous wording. The description is front-loaded with the action and immediately explains the safe call pattern, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential operational flow (preview, confirm, effect on built servers) and is sufficient for most use cases. It lacks details on error conditions (e.g., invalid token) and the exact meaning of dry_run, but overall it is complete enough for a moderately complex delete tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only blueprint has a description). The description explains the role of confirm_token and the workflow, but it does not clarify the dry_run parameter or how it interacts with the two-step process. Partial compensation, but not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a saved blueprint from the local store,' using a specific verb and resource. It distinguishes from sibling tools like save_blueprint, get_blueprint, and list_blueprints by focusing on deletion, and adds context that servers built from it are untouched.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance for the two-step confirmation flow: call once for a preview and token, then repeat with the token to delete. It does not explicitly name alternatives, but the intent is clear from the context and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a critical behavioral trait: 'the first call changes nothing and returns a preview plus a confirm_token; repeating the call with the token deletes it.' This goes far beyond the annotations by explaining the non-destructive first call and the confirmation mechanism, directly enriching the agent's understanding of how to invoke the tool safely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every sentence adds value. It is concise and well-structured, providing necessary behavioral context without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and the two-step workflow, the description covers the essential context for using it correctly. However, it omits details about the dry_run parameter, the exact contents of the preview, and permission requirements, leaving some gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies the confirm_token parameter ('repeating the call with the token deletes it') and implies the preview behavior, but it does not explain the dry_run parameter, which remains ambiguous. Since schema coverage is only 50%, the description partially compensates but leaves a significant gap for one of the four parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete a custom emoji' with a specific verb and resource, clearly distinguishing it from other delete tools. It also briefly explains the two-step confirmation process, which clarifies the tool's unique behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: the first call is a safe preview, and the second call with the token performs the deletion. It does not explicitly mention alternatives or when not to use it, but the resource is unique and the workflow is well-illustrated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, but the description adds critical behavioral context: the two-step confirmation flow where the first call is non-destructive and returns a preview and confirm_token, and the second call with the token actually deletes. This goes well beyond annotations and clarifies exactly how the destructive action is gated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, then the safety mechanism. Every phrase earns its place; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavior and the confirmation flow, but it omits the dry_run parameter's effect and whether confirm_token expires. Given no output schema, a bit more detail on the preview contents would complete the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 40%, so the description must compensate for undocumented params. It explains confirm_token's role, but does not clarify dry_run, reason, or guild behavior beyond the schema. The description adds value on confirm_token but leaves param interactions incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a forum post') and its scope ('and every reply in it'), distinguishing it from sibling tools like delete_message or delete_thread. The verb is specific and the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool for removing a forum post and all replies, and the 'Safe to call directly' note guides usage expectations. It does not explicitly name alternatives or exclusion cases, but the context from the scope is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the destructiveHint annotation by disclosing the two-phase commit behavior (non-destructive first call, destructive second call) and the impact on posts. This is critical behavioral context not inferable from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, followed by the key behavioral nuance. Every word earns its place; it is concise without omitting essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the most critical context: the two-phase deletion process and its effect on posts. However, it does not explain error handling, permissions, or the exact contents of the preview, and the dry_run parameter remains undocumented. Given the lack of an output schema, a bit more detail would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes tag, forum, and guild. The description adds meaning for confirm_token by explaining its role in the second call, but it does not clarify the dry_run parameter or the exact content of the preview. With 60% schema coverage, the description partially compensates but leaves meaningful gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove a tag from a forum') and the effect on posts ('posts carrying it simply lose it'), making the tool's purpose unambiguous. It distinguishes from sibling tools like create_forum_tag and update_forum_tag by focusing on removal and its consequence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the safe two-call usage pattern: the first call returns a preview and confirm_token, and the second call with the token removes the tag. This provides clear context for how to use the tool correctly, though it does not explicitly name alternatives or state 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark destructiveHint=true, but the description adds crucial behavioral detail: the first call changes nothing and returns a preview plus confirm_token, and only the repeated call with that token actually deletes. This goes well beyond the annotations and prevents accidental destructive actions. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every clause earns its place by explaining safety and the two-step mechanism. There is no redundant or filler wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description effectively conveys the safety mechanism and the preview/confirm_token flow, which is the most important behavioral aspect. However, it does not explain the dry_run parameter, the contents of the preview, or what the final deletion call returns. Given the lack of an output schema, these omissions leave minor gaps, but the overall deletion flow is understandable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers guild and integration_id with descriptions, but reason, dry_run, and confirm_token lack schema descriptions. The description explains confirm_token's role and alludes to the preview flow, but does not clarify the dry_run parameter or what 'reason' is for. With schema coverage at 40%, the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Remove an integration from the server,' which is a specific verb+resource pair that clearly distinguishes this from sibling delete tools like delete_webhook or delete_emoji. It also names the resource type (integration) and the action, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context by stating 'Safe to call directly' and explaining the two-step flow (first call preview, second call deletion). This tells the agent when to invoke it and reassures about accidental damage. It does not explicitly name alternatives, but the intent is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations indicating destructive behavior, the description discloses the crucial two-phase nature: 'the first call changes nothing and returns a preview plus a confirm_token; repeating the call with the token revokes it.' This explains exactly what side effects occur and prevents accidental deletion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence. It front-loads the action and immediately follows with the essential safety protocol. Every phrase earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the core usage and safety behavior for a destructive tool with no output schema. It explains the preview and confirm_token workflow, but leaves some gaps such as the exact format of the preview, how to pass confirm_token, and the roles of optional parameters like guild and reason. These are secondary to the main destructive-action context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only 40% description coverage. The description adds key meaning to confirm_token by explaining its role in the revocation flow, but it does not explicitly clarify dry_run, reason, or the relationship between the first call and dry_run. This partial compensation leaves some parameters underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with the specific action 'Revoke an invite link', clearly stating the tool's purpose. This distinguishes it from sibling tools like create_invite, list_invites, and get_invite, which handle different invite operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for the safe two-step calling sequence: first call previews and returns a confirm_token, second call with token revokes. It does not explicitly discuss alternatives or when-not-to-use, but the guidance on how to use the tool effectively is strong and directly addresses the main usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing the critical two-phase behavior: the first call returns a preview and confirm_token without deleting, and deletion only occurs on the second call with the token. It also clarifies side effects ('Members holding it simply lose it; nothing else changes'), providing detailed behavioral transparency that is essential for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, comprising three sentences that each add critical information: the action, the side effects, and the safe two-step process. It is front-loaded with the primary purpose and avoids unnecessary verbosity, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description effectively explains the most important non-obvious behavior (the gated deletion flow) and the impact on role members. It does not detail the preview content or error conditions, and no output schema exists, but the core decision-making context is covered. Some information about permissions or edge cases is missing, but overall it is adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 40% schema description coverage, the description partially compensates by explaining the role of confirm_token in the deletion flow. However, it does not clarify the dry_run parameter or the exact semantics of reason, leaving gaps for agents attempting to construct correct calls. The description adds some context but not enough to fully cover the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Delete a role', a specific verb+resource that clearly states the tool's purpose. It further distinguishes this tool from a simple delete by explaining the two-step confirm_token gating mechanism, which sets it apart from sibling tools like remove_role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Safe to call directly' and recommends 'Prefer this gated flow over telling the user to delete the role manually.' This gives clear usage context and a preference over manual deletion. However, it does not explicitly contrast with sibling tools like remove_role or update_role, leaving a small gap in alternative differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description adds crucial context beyond that: the first call changes nothing and returns a preview plus confirm_token, and only the subsequent call with the token deletes. This reveals the non-obvious two-step behavior, which is essential for safe use. It also clarifies that destructive action is gated by the token, fully aligning with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that leads with the action, then immediately explains the critical confirmation mechanism. No filler or redundant phrases; every word contributes. It is concise yet information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with a two-step confirmation pattern, the description covers the essential workflow and return value (preview + token). It does not explain the exact preview format, the dry_run parameter's behavior, or edge cases like invalid tokens, but the core safe-usage context is present. Given the complexity of the confirmation flow, this is quite complete, though not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (sticker and guild have descriptions; dry_run and confirm_token do not). The description adds meaning to confirm_token by explaining it comes from the first call and is required to complete deletion. However, the dry_run parameter is not explicitly explained; the description implies a dry-run behavior but does not clarify whether dry_run is a flag or if the first call automatically dry-runs. This leaves a significant semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair: 'Delete a custom sticker.' It distinguishes this tool from siblings like delete_emoji by specifying 'sticker' and adds the qualifier 'custom,' making the scope precise. The confirmation-flow detail further clarifies the tool's unique purpose compared to a straightforward delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by explaining the two-step confirmation process: the first call is a dry-run preview and the second call with a token performs the deletion. It also states 'Safe to call directly,' which sets expectations for first use. However, it does not mention alternatives or when not to use this tool (e.g., for emojis) or prerequisites like required permissions, leaving a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true), the description reveals a crucial two-phase behavior: the first call is a no-op that returns a preview and confirm_token, and the second call with the token actually kicks. This adds significant context not captured by annotations and directly addresses the safety of calling a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—three sentences with no redundancy. The first sentence states the purpose, the second clarifies the rejoin constraint, and the third explains the safe call pattern and action. Every sentence serves a distinct purpose, and the most important behavioral info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no output schema, the description explains the core operation and the critical two-step token flow, which is necessary for correct invocation. However, it omits details about the reason parameter, the exact behavior of dry_run, and post-kick outcomes (e.g., audit logs or DM), leaving some gaps for a fully comprehensive understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40% (guild and member), leaving reason, dry_run, and confirm_token undocumented. The description compensates partially by explaining the confirm_token flow and preview, but it does not clarify the purpose of dry_run or how it relates to the preview, nor the reason parameter. Thus, it adds some value but does not fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove a member from the server') with a specific verb and resource. It also distinguishes from sibling tools like ban_member by noting the member can rejoin with a new invite, which differentiates the kick behavior from a ban.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by explaining the safe two-step call pattern and instructing the agent to relay the preview for user confirmation. However, it does not explicitly mention alternative tools or when not to use this tool, so it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds behavioral nuance that guild and global commands are separate lists and a name can exist in both, which is useful beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no filler. Every phrase contributes meaning, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only list tool with two optional parameters, no output schema, and a clear description of what it returns (the list of commands). It adequately covers the essential context, though it does not detail the return format or any potential empty results, which would be a minor gap for a tool lacking an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, so baseline is 3. The description adds semantic clarity by explaining that omitting guild yields the global set and passing a guild yields that server's set, which enriches the meaning of the 'guild' parameter beyond its schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists slash commands registered by the bot's application, using the specific verb 'list' and resource 'app commands'. It distinguishes global vs guild command sets, setting it apart from sibling list tools like list_events or list_integrations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: omit guild for the global set, pass a guild for that server's set. It explains the key decision point but does not explicitly mention alternatives or when not to use this tool, which is minimal for a simple read-only list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds paging behavior and cursor continuation beyond the readOnlyHint annotation. It doesn't deeply describe response shape or edge cases, but given the annotation already signals safety, the added paging context is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that immediately state purpose, pagination mechanics, and the preferred alternative. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with full schema descriptions and a readOnly annotation, the description is sufficient to understand the core behavior. It covers pagination and alternative tool usage, though it doesn't mention default guild behavior or output format, which are reasonably implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description only reinforces the 'after' cursor behavior, adding marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a 'paged roster of server members', using a specific verb and resource. It also distinguishes itself from search_members, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use search_members for finding specific people, and explains the pagination flow with 'Pass after with the last id to continue'. This gives clear guidance on when to use the tool and how to use the cursor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Reinforces the readOnlyHint annotation with 'Changes nothing' and adds valuable non-obvious behaviors: reports all problems at once, reuses existing channels/roles, never duplicates. This goes beyond what annotations or schema alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the core action and safety guarantee. Each sentence provides distinct value without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with nested schema and no output schema, the description covers purpose, validation scope, safety, and reuse behavior. It does not explicitly describe the returned build plan's structure or how to pass it to execute_build_plan, but the core usage is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds context about composing the blueprint from the user request and optionally using a reference layout, but does not detail individual parameter behavior beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates a blueprint and stages an ordered build plan, listing specific validations (Discord limits, name collisions, role references, feature requirements, bot permissions). It distinguishes from execution tools by explicitly noting 'Changes nothing.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that this is for the planning phase prior to actual changes, with guidance to compose the blueprint from the user's request. It does not explicitly name alternatives or when-not conditions, but the planning vs. execution distinction is evident from the description and sibling tools like execute_build_plan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnly=false) and non-destructive (destructive=false). The description adds a non-obvious behavioral trait: the API accepts fewer than the seven default channels Discord's UI requires, which is valuable for agents. However, it does not clarify whether omitting prompts/default_channels resets or preserves existing settings, a meaningful gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, no filler. The second sentence earns its place by surfacing a non-obvious constraint about default channel counts. Excellent conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (5 params, nested one level, no output schema), the description plus schema provide a solid picture. It lacks explicit statement about partial update behavior (whether omitted fields are reset) and return value, but annotations and schema mitigate some of this. The API quirk adds helpful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers about 60% of parameters with descriptions. The description supplements this by explaining that prompts grant channels/roles and default_channels are what every member sees, plus the enabled state. It does not cover mode/guild, but those are adequately described in the schema. The overall semantic contribution is helpful without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('Configure the new-member onboarding flow') and enumerates the configurable aspects: prompts with options granting channels and roles, default channels, and enabled state. This clearly distinguishes it from sibling get_onboarding and other update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose statement makes it clear when to use this tool for onboarding configuration. It does not explicitly name alternatives or exclusions, but the description and sibling get_onboarding give practical context. The note about Discord's app requiring seven default channels while the API accepts fewer provides useful usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the crucial two-step behavior (non-destructive first call with confirm_token, destructive second call) and the 14-day Discord limitation. This adds significant context beyond the destructiveHint=true annotation, clarifying that the first call is safe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core action, then the constraint, then the safety workflow. Every sentence contributes essential information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, a destructive annotation, and no output schema, so the description carries a heavy burden. It covers the workflow and constraints well, but omits dry_run semantics and contains an inconsistency: it states '2 to 100' while the schema permits a count minimum of 1. This leaves a potentially confusing ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to confirm_token (repeating the call with it deletes) and ties contains/from_author to filtering. However, dry_run is not explained, leaving a gap for that parameter. Schema covers most other fields, so the description adds partial value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes many recent messages at once (2 to 100), with optional filters by author or text. This specific verb+resource+scope distinguishes it from siblings like delete_message, which handles a single message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The two-step confirmation flow is explicitly described: first call returns the list and confirm_token, second call deletes. It also notes Discord's 14-day age limit, providing clear context. However, it does not explicitly contrast with delete_message or other alternatives, though the bulk-use case is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true), the description discloses that the first call is non-destructive, returns a preview and confirm_token, and only the second call with the token actually deletes. This is critical behavioral context that prevents accidental deletion and aligns with safe invocation patterns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and every word earns its place. It conveys both what the tool does and the critical two-step behavior without any fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and no output schema, the description adequately covers the key behavior an agent needs to know: the safe two-step call sequence. It also clarifies safety in a way that is not inferable from annotations, making it complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (guild and sound have descriptions, but dry_run and confirm_token do not). The description adds meaning to confirm_token by explaining its role in the deletion flow, but it does not explain the dry_run parameter or its relationship to the preview step. The description partially compensates for the schema gap but leaves one parameter ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Delete a soundboard sound,' clearly identifying the tool's function. It also distinguishes it from sibling tools like list_soundboard_sounds, create_soundboard_sound, and update_soundboard_sound, which are all different operations on the same resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains the two-step usage pattern: call once for preview/token, then repeat with token to delete. This is clear when-to-use guidance for the tool's core flow. However, it does not mention alternatives or when not to use this tool, though the name and context make the primary use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds value by clarifying the scope (scheduled events, not messages or subscriptions) and the return fields. It does not mention pagination or ordering, but with the annotation covering the read-only nature, this is sufficient. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long. The first sentence front-loads the core purpose and content fields. The second sentence proactively disambiguates from similar tools. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity tool with one optional parameter and no output schema. The description covers what the tool does, what fields are returned, and differentiates it from related tools. It is fully adequate for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional 'guild' parameter, so the schema fully documents the parameter. The description adds no extra parameter details, which is acceptable because the schema carries the burden. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists scheduled community events (the kind members RSVP to) and specifies the fields included: type, time, status, and interest counts. It explicitly distinguishes itself from sibling tools by naming list_scheduled_messages and list_event_subscriptions, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit alternatives: 'For pending scheduled messages see list_scheduled_messages; for live event subscriptions see list_event_subscriptions.' This tells the agent when to use this tool versus related siblings, effectively conveying the usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds concrete behavioral detail: every failed check includes fixing instructions, and the tool checks specific setup components. This goes beyond the annotation without contradicting it, though it stops short of describing the output format or exact response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: the first lists the health check scope, the second covers failure feedback, the third addresses the bot parameter, and the fourth states when to use it. Information is front-loaded with the core purpose in the opening phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a diagnostic tool with one optional parameter and no output schema, the description is comprehensive. It covers what is checked, that failures include remediation instructions, the bot-selection behavior, and the recommended usage context. Nothing essential is missing for an agent to invoke it appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the 'bot' parameter with a clear description of its optional use and default behavior. The description echoes this guidance ('pass bot to check a specific one') but does not add new meaning beyond what the schema provides. Baseline of 3 applies because schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an 'End-to-end health check of the Omnicord setup' and enumerates the specific checks performed (token validity, gateway intents, guild count, default guild membership). This distinguishes it from all sibling tools, which focus on individual resources rather than overall setup health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Run this first when anything misbehaves.' This positions the tool as the initial diagnostic step. It also provides conditional usage for multi-bot setups: 'With more than one bot configured, pass bot to check a specific one.' No alternative tools are mentioned, but the 'run first' directive establishes clear precedence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, and the description adds valuable behavioral context: it covers every channel the bot can read, searches inside embeds and polls, uses whole-word full-text matching, and supports filtering by author, content type, and pinned state. It does not describe pagination or rate limits, but with the annotation covering safety, the added context is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main action, and every sentence adds value. It covers scope, matching behavior, and available filters/sorting without fluff. It is well-structured and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter search tool with no output schema, the description is quite thorough: it covers scope, matching semantics, filters, and ordering. However, it does not explicitly describe the return format or pagination details (offset/limit), relying on the schema for those. Since the output schema is absent, a brief note on what is returned (e.g., matching messages) would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds significant meaning beyond the schema. It clarifies that query matching is whole-word not substring, that 'has' includes image/link/file examples, that sort order is 'newest first or by relevance', and that channel can be used to limit scope. These enrich the parameter understanding beyond the raw schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the server's message history via Discord's native search index, using a specific verb and resource. It distinguishes from siblings like read_messages and search_members by emphasizing full-text search across history with filters. The scope (all readable channels or one named channel) is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use: for searching message history with keyword matching, filters, and sorting. It explains the whole-word matching behavior, which guides the agent to use word searches rather than fragments. It does not explicitly name alternative tools or exclusions, but the usage context is strong enough to avoid confusion with read_messages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by explaining the time-limited nature (up to 24 hours), the ability to lift pauses with 0, and the read-only state reporting. It also mentions that Discord's own raid/DM spam detection is included, providing rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a purpose: scope, action, and usage. It is front-loaded with the most important information and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (3 optional parameters, no output schema), the description fully explains the tool's behavior, including the report mode and edge cases. It leaves no significant gaps for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% parameter coverage, including descriptions for dms, invites, and guild. The description's mention of '0 to lift a pause' and 'omit to leave unchanged' mirrors the schema, adding no new information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as Discord's raid-defense security action for the whole server, specifically pausing new invites and DMs. It distinguishes itself from sibling invite tools by focusing on server-wide lock down during a raid.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the tool is for locking down the server during a raid, providing clear context. It gives usage instructions for pausing, resuming, and reporting state, though it does not name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond the readOnlyHint/destructiveHint annotations by explaining that passing an empty status clears it and that this is the live status, not the topic. It does not contradict the annotations; readOnlyHint=false aligns with the write operation. It doesn't detail permissions or side effects, but the annotations cover the core 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: the first front-loads the action and constraints, the second explains the clear behavior, and the third makes the crucial topic distinction. There is no redundancy or wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with three parameters and no output schema, the description covers all necessary aspects: what it does, the maximum length, how to clear it, and the distinction from topic. It is complete and gives sufficient context for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of parameters with descriptions, giving a baseline of 3. The description enriches the meaning of 'status' by explaining it as the live status line about what's happening in the channel, and clarifies that empty clears it (though the schema also says this). This added context justifies a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'voice channel status,' specifying it is the short status line shown on a voice channel, up to 500 characters. It also distinguishes from the topic, setting it apart from related tools like update_channel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (setting the live status) and contrasts it with the topic, implying that this is not for setting the topic. However, it doesn't explicitly mention alternative tools or give when-not-to-use conditions, so it falls 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive intent, but the description adds significant context: the two-step confirm flow, that the first call changes nothing and returns a preview plus confirm_token, and that it can delete recent messages. This goes beyond the annotations and clearly explains the tool's safety and destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences, front-loaded with the core action, then the flow details. Every sentence is informative with no redundancy or filler, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still indicates return values (preview plus confirm_token) and covers the main flow, safety, and the edge case of departed users. It does not describe the preview's contents or failure conditions, but it is sufficient for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes user, guild, and delete_message_seconds. The description compensates for the undocumented dry_run and confirm_token by explaining the preview/confirm workflow, and clarifies that user accepts IDs for departed members. This adds meaning beyond the schema, though the 'reason' parameter remains unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool bans a user from the server, optionally deletes their recent messages, and works on users who have already left. This specific verb+resource combination, along with unique capabilities, distinguishes it from sibling tools like kick_member and unban_member.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage guidance: it is safe to call directly for a preview, then repeat with the confirm_token to execute. It also notes the user ID handling for departed members. However, it does not explicitly contrast with alternatives (e.g., when to prefer this over kick_member) or state 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description reveals a two-step confirmation flow: the first call is safe and changes nothing, returning a preview and confirm_token. This is critical behavioral information that shapes how an agent should invoke the tool safely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action, and each sentence contributes necessary information. No wasted words, efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool's complexity centers on the two-step confirmation, which the description adequately explains. No output schema exists, but the description mentions the preview and token. Minor gaps include not specifying the exact preview content or post-execution result, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 50%, the description adds crucial meaning for the confirm_token parameter (returned from first call, used to execute) and implies the dry_run behavior (first call changes nothing). It does not explain all parameters, but it clarifies the most complex part of the flow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Clear all reactions from a message, or all of one emoji.' This specific verb-resource pairing distinguishes it from siblings like remove_reaction and get_reactions, indicating what unique action this tool performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit procedural guidance: the first call is a preview that returns a confirm_token, and repeating with the token executes. This is clear usage context, though it does not explicitly name alternatives or conditions for 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, which is consistent with 'Create'. The description adds behavioral context: members see the event on the events list and can mark interest, and external events are 'in-person or off-platform.' It does not disclose permission requirements or return behavior, but with annotations present, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler. The first sentence states purpose, the second disambiguates from siblings, and the third gives type-specific requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, type variants, sibling exclusions, and parameter relationships. It does not mention return values, but no output schema exists; overall it is complete for a creation tool with this schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the conditional use of parameters: channel is required for voice/stage, while location and end_time are required for external events. It also clarifies the meaning of 'external' beyond the schema's enum. Schema coverage is 67%, and the description compensates for the remaining gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' and identifies the resource as 'Discord scheduled community event' with explicit variants (voice, stage, external). It also distinguishes from siblings by explicitly naming schedule_message and subscribe_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states what the tool is not for: 'This is not for sending a message later (use schedule_message) or watching live activity (use subscribe_events).' It also provides conditional requirements for event types (voice/stage need a channel; external needs location and end time).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive operation. The description adds meaningful behavioral context by explaining the three modes (standalone, branched, private) and the channel-type constraint. It does not disclose hidden side effects like permission requirements, but for a creation tool with these annotations, this is adequate and consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with no wasted words. The first sentence front-loads the core action and the three modes; the second sentence provides the critical sibling alternative. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main behavior, all three usage modes, and the key exclusion (forum channels). It does not describe return values or prerequisites, but the lack of an output schema and the tool's relative simplicity make this acceptable. The parameter details are mostly covered by the schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 71%, so the baseline is 3. The description adds value beyond the schema by explaining that message_id creates a branched thread and that private means invite-only and only works standalone. It also clarifies the channel type ('text or announcement channel'), which the schema does not specify in the parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Start') with a clear resource ('a thread in a text or announcement channel'), and explicitly distinguishes itself from the sibling create_forum_post by directing forum posts elsewhere. This makes the purpose unmistakable and differentiates it from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: standalone threads, branched threads when message_id is given, and private threads 'when asked'. It also names an alternative tool ('use create_forum_post instead') for forum channels, clearly indicating when NOT to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses the two-phase behavior: the first call changes nothing and returns a preview plus confirm_token, and only the second call actually deletes. It also warns that anything still posting stops working, adding valuable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and every sentence contributes necessary information: what the tool does, the consequence, and the safe call sequence. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive two-step tool with no output schema, the description covers the core lifecycle: preview, confirm_token, and final deletion. It does not spell out optional parameters or exact second-call payload, but it provides enough for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, and the description compensates by explaining the critical confirm_token workflow and the non-destructive first call. However, it does not explicitly name or clarify dry_run, reason, or guild beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb and resource ('Delete a webhook') and immediately states the consequence ('Anything still posting through it stops working'). This clearly differentiates it from sibling tools like update_webhook or send_webhook_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to delete a webhook) and provides explicit safety guidance: 'Safe to call directly' and the two-step confirmation flow. It does not explicitly name alternatives or exclusions, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds important behavioral details: the original travels as a quoted snapshot, the optional note is posted as a separate message because Discord does not allow text on the forward itself, and that it functions across channels. This provides a thorough understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core action, and every sentence adds meaningful detail without redundancy. It is concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema, the description covers the essential behavior, including the quoted snapshot and note posting. It does not mention permissions or edge cases, but given the simplicity of the operation and good annotations, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with descriptions for all parameters. The description adds further meaning by explaining that the 'content' parameter is an optional note posted separately and that the forward includes a quoted snapshot, clarifying how 'message_id' and 'from_channel' relate. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool forwards a message from one channel to another, explicitly referencing the Discord client's forward behavior and the quoted snapshot mechanism. This distinguishes it from sibling tools like send_message or crosspost_message by specifying the exact semantic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool ('forward a message... the way the Discord client's forward does') and notes that it works across channels in the server. It does not explicitly mention alternatives or when not to use it, but the scenario is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important non-obvious behaviors beyond the annotations: upsert semantics (update if name taken), propagation delays, daily rate limits, and the lack of support for subcommands/subcommand groups. This gives the agent essential context for expectations and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the primary action. Each sentence adds meaningful information without fluff. It is cleanly structured and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no output schema, write/update operation), the description covers the key usage considerations: upsert behavior, timing, rate limits, and unsupported features. It could mention what the response contains, but it is sufficiently complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 useful guidance for the guild parameter (pass it while iterating) and implies name semantics via the update-in-place behavior, which adds value beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Register a slash command', and adds the nuance that it updates in place if the name already exists. This distinguishes it from list_app_commands and delete_app_command, though it overlaps with update_app_command.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit context for when to use it, especially the guild vs global command trade-offs ('guild commands appear immediately, while global commands can take up to an hour... rate limited per day'). However, it does not explicitly mention alternative tools like update_app_command or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates a safe read, but the description adds behavior beyond that: 'Name search uses Discord's member search; role filtering walks the member list and reports if it hit the paging cap.' This discloses implementation details and a potential limitation, which is valuable for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then alternatives, then behavioral notes. No redundancy or wasted words. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with four optional parameters and no output schema, the description covers purpose, usage, and key behavioral caveats. It could mention return format or interaction between query and role, but the guidance is strong enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 a bit of nuance (name fragment vs prefix, paging cap for role filtering), but does not substantially improve on the schema's parameter descriptions. It remains at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Find specific members by a name fragment, or list those holding a given role.' It distinguishes itself from siblings by explicitly referencing list_members, get_member, and find, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool vs alternatives: 'For the whole roster use list_members; for one member's full profile use get_member; to turn a fuzzy name into an id use find.' Also mentions the role-filtering paging cap, setting expectations for edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint: false, destructiveHint: true), the description discloses a critical behavioral trait: the first call is non-destructive and returns a confirm_token, while the second call applies the destructive action. It also notes that "The reason lands in the audit log," adding audit context. No contradiction with annotations; the description clarifies the destructive hint applies only upon confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary purpose, and every sentence earns its place: purpose, safe invocation steps, and audit log note. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two-step confirmation, 6 parameters, no output schema), the description explains the essential flow and the confirm_token mechanism. It could mention error cases or that the token is required for the second call, but it does specify "repeating the call with the token applies the timeout." Overall, it is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 50% schema description coverage, the description compensates by explaining the purpose of dry_run and confirm_token through the two-step flow: "the first call changes nothing and returns a preview plus a confirm_token; repeating the call with the token applies the timeout." It also gives meaning to reason by stating it lands in the audit log. The schema already covers guild, member, and duration_minutes, so the description adds value for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action, resource, and effect: "Time a member out so they cannot talk, react, or join voice, for up to 28 days." This clearly distinguishes it from sibling tools like ban/kick (permanent) and remove_timeout (the opposite).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool safely with the two-step preview/confirm flow: "Safe to call directly: the first call changes nothing and returns a preview plus a confirm_token; repeating the call with the token applies the timeout." It also instructs to relay the preview for user approval. It doesn't explicitly compare to alternatives, but the purpose implies when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the destructiveHint annotation by revealing the two-phase behavior: the first call changes nothing and only returns a preview and confirm_token, while the second call with the token actually removes the command. This is a critical behavioral nuance that prevents accidental destructive actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and perfectly front-loaded: the first sentence states the purpose, and the second explains the safe calling flow. No redundant words or filler; every clause adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and 5 parameters, the description covers all essential operational context: the confirmation flow, the token, and the preview. It even tells the user what the first call returns, effectively covering the output schema that is absent. This is sufficient for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 60% coverage and leaves dry_run and confirm_token undocumented, but the description explains the confirm_token's role in the second call and implies a dry-run mode in the first ('changes nothing'). This compensates for the missing schema descriptions, though it does not explicitly name dry_run.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: unregistering a slash command so it no longer appears for users. This specific verb+resource pairing distinguishes it from siblings like delete_integration or delete_webhook, and the effect is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on how to invoke the tool safely: the first call is a preview, and the second call with the token performs the deletion. It does not explicitly compare alternatives (e.g., update_app_command to disable), but the step-by-step invocation guidance is strong for a destructive tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the critical two-call confirmation gate: the first call deletes nothing and returns a preview plus confirm_token, and deletion only occurs on the second call. It also explains that deleting a category leaves its channels in place, uncategorized. This adds valuable nuance beyond the annotations' destructiveHint=true and is not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the primary purpose. Each sentence provides necessary context—purpose, usage flow, and category behavior—without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature and lack of output schema, the description fully covers the essential workflow: first call returns preview and token, second call completes deletion. It also covers the category edge case. The rationale for the confirmation gate is provided, making the tool's behavior complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the confirm_token parameter by explaining its role in the two-step deletion flow, and it clarifies that the channel parameter accepts both channel and category names. However, other parameters (guild, reason, dry_run) are not explained in the description and lack schema descriptions, leaving a gap in coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence 'Delete a channel or category' uses a specific verb and resource, making the tool's purpose unmistakable. It also distinguishes from sibling tools like create_channel, update_channel, and clone_channel by explicitly limiting scope to deletion of channels and categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit invocation guidance: 'When the user asks to delete something, call this and relay the preview for their go-ahead.' It also compares the tool to manual Discord usage, directing the agent to use this tool instead. The two-step flow with confirm_token is clearly explained, leaving no ambiguity about when and how to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description richly discloses the tool's behavior beyond the destructiveHint annotation: the first call deletes nothing and returns a preview plus confirm_token, and deletion only happens on repeated call with the token. It also mentions dry_run support, adding significant operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, with each sentence serving a purpose: stating what it does, explaining the confirmation flow, and giving usage guidance. It is front-loaded with the core action and avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and two-step confirmation mechanism, the description covers the essential operational details: how to call it safely, what to expect (preview and token), and when to use it. It is sufficient for an agent to correctly select and invoke the tool, especially with the supportive schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes 5 of 6 parameters (83% coverage), but the description adds important context for dry_run and confirm_token, which are central to the two-step flow. It compensates for the undocumented dry_run parameter and clarifies how confirm_token is obtained and used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Purpose is stated clearly and specifically as 'Delete one message,' distinguishing it from bulk_delete_messages and other delete tools. The two-step confirmation flow is also described, which sets it apart from direct-deletion tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use the two-step flow to let the user approve through the conversation, providing a clear context. It also states the tool is safe to call directly, implying when to invoke it. However, it does not explicitly name alternative tools like bulk_delete_messages for multi-message deletion, so it misses a direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses the two-phase behavior: the first call changes nothing and returns a preview plus confirm_token, and only the repeated call with the token deletes. It also notes the share link stops working, adding genuine behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the tool's purpose, and every clause adds value—there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with no output schema, the description provides enough context: the effect (share link stops working), the safe confirmation flow, and what the first call returns (preview + confirm_token). This is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (code and guild have descriptions; dry_run and confirm_token do not). The description compensates by explaining the roles of confirm_token and the dry-run behavior, even though it does not name the parameters directly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('Delete') and resource ('server template'), and adds the specific consequence that the share link stops working. This distinguishes it from sibling tools like create_server_template and sync_server_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear guidance on how to call the tool safely: the first call is a preview, and the second call with the confirm_token deletes. It implies when to use it (for deleting templates) and explains the two-step safe workflow, though it does not explicitly contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Rich behavioral disclosure goes far beyond the annotations (readOnlyHint=false, destructiveHint=false): it reveals live re-validation, dependency ordering, permission compilation, strict additivity, fail-stop behavior, report contents, and resume semantics. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
All four sentences carry essential information with no filler. The description is front-loaded with the core action, then expands into ordering, safety guarantees, failure behavior, and resume. It is dense but efficiently structured for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's complex behavior despite a large nested schema and no output schema: validation, ordering, permission compilation, additive promise, failure stop/report, and idempotent resumption. It tells the agent everything needed to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers all parameters at 100%, so baseline is 3. The description adds meaningful semantic context beyond field-level docs: what happens to the blueprint (re-validated), the build order, how private_to/read_only are compiled into permissions, and how plan_id vs blueprint relate to the staging workflow. This goes beyond the schema but does not fully enumerate per-parameter syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'Execute a staged plan by plan_id, or pass a blueprint directly.' It specifies the tool's exact scope (building roles, categories, channels in dependency order) and distinguishes it from incremental tools like create_role/create_channel, as well as from plan_server_build which stages plans.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states the two invocation modes (plan_id or direct blueprint) and gives strong usage context: re-validation against live server, additive-only behavior, and resumption after failure. It lacks an explicit 'use alternative X instead' statement, but the additive constraint effectively says when not to use it, and the reference to 'a plan staged by plan_server_build' ties it to its staging sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation is consistent with the description of a historical record. The description adds context about the nature of the data ('who did what, to what, when, and why') and the contrast with live events, though it does not mention permissions or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The first sentence defines the tool, the second gives usage guidance and filter examples. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description is complete: it explains what the audit log contains ('who did what, to what, when, and why'), when to use it, and how to filter. The schema handles parameter details and the annotation covers safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 4 parameters with descriptions (100% coverage). The description adds semantic value by giving concrete filter examples ('action name like channel_create, member_ban_add, message_delete') and clarifying that user corresponds to 'acting user'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as 'Discord's historical record of administrative actions' and states its purpose: 'Use this to investigate what already happened'. It also distinguishes from sibling subscribe_events by contrasting historical vs real-time activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'for activity as it happens use subscribe_events' directly names the alternative. It also shows when to use this tool (investigate past events) and how to filter (by action or user).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true; description adds context about output (labels, member counts) and usage as a map, enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with essential info, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-param, read-only tool, the description fully explains what is returned and how to use it, sufficient given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, baseline is 4. Description does not need to add parameter details since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists servers with bot labels and approximate member counts, and distinguishes from 'get_server_overview' for full detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (when choosing which bot acts) and recommends alternative for detailed server info ('get_server_overview').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate non-read-only and non-destructive, but the description adds substantial behavioral context: delivery happens when the Omnicord process is running, and messages due during downtime are sent at the next start. It also clarifies that 'Omnicord sends it when the time comes,' revealing the delivery mechanism. This goes far beyond annotations and is not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, with the core purpose in the first sentence. Each subsequent sentence adds critical context: the event alternative, delivery mechanics, and the deployment limitation. No redundant information; it is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description provides complete guidance for correct invocation: what it does, when to use an alternative, the key scheduling limitation, and behavior on missed deliveries. It covers operational constraints (process must run) and failure recovery, making it sufficient for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so the schema already documents most parameters. The description does not add new semantics beyond what the schema provides; it merely mentions 'once or on a daily or weekly repeat' which maps to the repeat enum, and 'later time' which maps to send_at. Thus, it does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool posts a text message to a channel at a later time, with options for once, daily, or weekly repeat. It distinguishes itself from create_event by noting it sends an ordinary message, not an RSVP event. The verb 'post' and resource 'text message to a channel' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use create_event when members need to RSVP, providing a clear alternative. It also gives a critical usage condition: the Omnicord process must be running at delivery time, advising hosted or Docker deployment for always-on scheduling. This tells the agent when to use the tool and what environment is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the minimal annotations (readOnlyHint=false, destructiveHint=false), the description discloses critical behavior: passing preset and/or permissions replaces the role's permission set with a bundle plus listed names, omitted fields remain unchanged, and dry_run is supported. These details give the agent a clear mental model of side effects and safety, with no contradiction against the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then key behavioral nuance, then the dry_run option. Every sentence adds unique value and there is no redundancy or filler. The structure is highly scannable for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter mutation tool without an output schema, the description covers the essence: what fields are editable, how permission replacement works, partial-update semantics, and dry_run. It does not mention error conditions or required permissions (e.g., Manage Roles), but those are not strictly necessary for invoking the tool correctly and are often implied by the tool's nature. Slightly more detail on expected return or failure modes would push it to 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% schema coverage, the description compensates substantially. It explains the semantics of preset and permissions (replacement behavior), clarifies that only passed fields change (so omitted boolean/nullable fields remain untouched), and introduces the dry_run option. This adds meaning far beyond the raw parameter names and enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Edit') and resource ('a role'), then enumerates exactly which fields are mutable: name, color, hoist, mentionable flag, and permissions. This clearly differentiates it from sibling tools like create_role, delete_role, and clone_role by emphasizing partial updates and permission-set replacement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool—for modifying an existing role's fields—and the phrase 'Only passed fields change' communicates that it is a targeted update, implying you should not use it to replace the entire role. However, it does not explicitly state when not to use it or name alternatives, so it falls just 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already mark this as destructive (destructiveHint=true), the description adds essential behavioral details: the first call changes nothing, returns a preview and confirm_token, and only the second call deletes. It also notes that messages are deleted alongside the thread.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and every word adds value. It is a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and lack of an output schema, the description covers the workflow, safety, and an alternative. It falls slightly short by not naming the archiving tool or detailing the preview contents, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40%, but the description compensates by explaining the crucial confirm_token parameter and the two-call workflow. However, the dry_run and reason parameters remain unexplained, and the description does not explicitly map dry_run to the preview behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Delete a thread and its messages,' which is a specific verb+resource statement. It clearly distinguishes this tool from sibling delete tools like delete_channel or delete_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains exactly when to use this tool (permanent deletion) and when not (archiving as a reversible alternative). It also provides critical procedural guidance about the two-step confirmation flow, making it highly actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds context about the returned data and bot selection behavior. It doesn't contradict annotations and adds value by specifying the exact status items and the optional bot selection mechanism.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded purpose, followed by optional usage and alternatives. No wasted words; the structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status tool with one optional parameter and no output schema, the description covers purpose, usage, alternatives, and behavior completely. No gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the bot parameter (100% coverage), but the description goes beyond by adding contextual guidance: when to pass it (multiple bots) and how to discover valid values via list_servers. This adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to get identity and status of a connected Discord bot, enumerating specific fields like bot user, application, guild count, gateway intents, and Omnicord version. It also distinguishes from siblings by mentioning run_setup_check for health checks and referencing list_servers for configured bots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use the bot parameter (when more than one bot is configured) and points to list_servers for discovering bots. It also directs users to run_setup_check for a full health check, providing clear alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavioral details beyond readOnlyHint: the request layer waits automatically, the invalid-request counter's threshold for temporary IP ban. This adds valuable context about how the tool's data relates to behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: first explains what and how, second gives usage hint. Front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter diagnostic tool, the description fully explains what it returns and why it's useful. No output schema needed; the description is self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (schema coverage 100% with empty properties), so description correctly focuses on the tool's output behavior without needing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: reporting on how rate limiting has been going, including specific counters. It distinguishes this diagnostic tool from the many action-oriented sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear use case ('when calls feel slow'), implying diagnostic context. Does not explicitly state when not to use or mention alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Omnicord MCP server](https://glama.ai/mcp/servers/OrygnsCode/Omnicord/badges/card.svg)](https://glama.ai/mcp/servers/OrygnsCode/Omnicord)

Score Badge

Copy to your README.md:

[![Omnicord MCP server](https://glama.ai/mcp/servers/OrygnsCode/Omnicord/badges/score.svg)](https://glama.ai/mcp/servers/OrygnsCode/Omnicord)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/OrygnsCode/Omnicord'

If you have feedback or need assistance with the MCP directory API, please join our Discord server