discord-mcp-server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
Multiple tools have overlapping or unclear boundaries, causing potential confusion. For example, 'list_channels' and 'get_channels' appear to serve the same purpose, and tools like 'creer_embed' and 'update_embed' have extensive descriptions that might overlap with other embed-related tools. The high tool count exacerbates this issue, making it difficult for an agent to distinguish between similar functions.
Naming Consistency2/5
The naming is inconsistent, mixing English and French (e.g., 'add_reaction' vs. 'creer_embed'), and using varied verb styles (e.g., 'create_button' vs. 'envoyer_message'). Some tools follow a verb_noun pattern, but the language and style deviations create a chaotic naming scheme that lacks a predictable pattern.
Tool Count2/5
With 53 tools, the count is excessive for a Discord server management domain, leading to bloat and complexity. This many tools suggests poor scoping, as many functions could be consolidated or omitted without losing essential coverage, making it overwhelming for agents to navigate effectively.
Completeness4/5
The tool set provides comprehensive coverage for Discord server management, including CRUD operations for channels, roles, messages, embeds, and members, along with advanced features like quizzes, polls, and analytics. Minor gaps might exist, such as limited moderation tools beyond basic actions, but overall, the surface is well-rounded for the domain.
Average 2.9/5 across 53 of 53 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('deletes a message') without explaining critical traits: whether this is destructive (likely yes, but not confirmed), permission requirements, rate limits, error conditions, or what happens upon success/failure. This leaves the agent guessing about important behavioral aspects.
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 a single phrase ('Supprime un message') that is under-specified rather than concise. It lacks front-loading of key information and doesn't efficiently convey purpose or usage in a structured way, leaving too much unsaid for a destructive operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is severely incomplete. It fails to address critical context: what happens after deletion (e.g., confirmation, error messages), permission requirements, or how it interacts with sibling tools. This leaves the agent with inadequate information to use the tool safely and effectively.
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 clear descriptions for all three parameters (channelId, messageId, reason). The description adds no additional meaning beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 'Supprime un message' (Deletes a message) is a tautology that restates the tool name 'delete_message' without adding specificity. It doesn't distinguish this tool from other deletion tools like 'delete_channel' or 'delete_role' in the sibling list, nor does it clarify what type of message (e.g., Discord message) is being deleted.
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. The description doesn't mention prerequisites (e.g., needing permissions), when not to use it, or how it differs from similar tools like 'edit_message' for modification instead of deletion.
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?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Supprime un canal' indicates a destructive mutation, but it doesn't specify critical details like whether deletion is permanent, requires admin permissions, affects channel history, or has side effects. The description is minimal and fails to compensate for the lack of 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 extremely concise with just three words ('Supprime un canal'), making it front-loaded and efficient. However, this conciseness comes at the cost of completeness, as it lacks necessary details for a destructive operation. Every word serves a purpose, but more sentences would be justified.
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?
Given this is a destructive mutation tool with no annotations, no output schema, and 2 parameters, the description is incomplete. It doesn't address behavioral aspects, return values, error conditions, or usage context. The high schema coverage helps with parameters, but overall context for safe and correct usage is lacking.
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 clear parameter descriptions in the schema itself. The tool description adds no additional parameter information beyond what the schema provides. According to scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
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 'Supprime un canal' (Deletes a channel) clearly states the verb and resource, making the basic purpose understandable. However, it doesn't differentiate from sibling tools like 'delete_message' or 'delete_role', which perform similar deletion operations on different resources. The purpose is clear but lacks sibling distinction.
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. There are no mentions of prerequisites (e.g., permissions needed), exclusions (e.g., cannot delete default channels), or comparisons to related tools like 'edit_channel' or 'get_channels'. Usage context is implied but not explicitly stated.
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?
With no annotations provided, the description carries full burden but only states the action (delete). It doesn't disclose critical behavioral traits such as whether deletion is permanent, requires specific permissions, affects members with the role, or has side effects. This is inadequate for a destructive 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 extremely concise with a single phrase ('Supprime un rôle'), which is front-loaded and wastes no words. It directly states the action without unnecessary elaboration, making it efficient in structure.
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 destructive tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior, consequences, permissions, or return values, leaving significant gaps for an AI agent to understand and use the tool safely and 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?
Schema description coverage is 100% for the single parameter 'roleId', so the schema fully documents it. The description adds no parameter information, which is acceptable given the high coverage. With zero parameters explained in the description, the baseline is 4 as per rules.
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 'Supprime un rôle' (Deletes a role) restates the tool name 'delete_role' in French, making it tautological. It specifies the verb (delete) and resource (role) but doesn't differentiate from sibling tools like 'edit_role' or provide any additional context about what deletion entails.
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 prerequisites (e.g., role must exist, permissions required), exclusions (e.g., cannot delete default roles), or refer to related tools like 'create_role' or 'edit_role' from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool modifies an existing message, implying a mutation operation, but doesn't describe any behavioral traits such as permissions required, whether edits are reversible, rate limits, or what the response looks like. This leaves significant gaps 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in French ('Modifie un message existant') that directly states the purpose. It's front-loaded with the core action, though it could be slightly more specific without losing conciseness.
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?
Given the tool's complexity (a mutation operation with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, error conditions, or response format, leaving the agent with insufficient context to use the tool effectively.
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 input schema already documents all three parameters (channelId, messageId, newContent) with descriptions. The description adds no additional meaning beyond what the schema provides, such as format details or constraints. Baseline 3 is appropriate when schema does the 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 'Modifie un message existant' clearly states the action (modify) and resource (existing message), but it's vague about what aspects can be modified. It distinguishes from siblings like 'delete_message' or 'envoyer_message' by focusing on editing rather than creating or deleting, but doesn't specify if it's content-only or includes other fields.
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 prerequisites (e.g., needing permission to edit messages), when editing is allowed (e.g., time limits), or what happens if the message doesn't exist. The description alone offers no 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?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as permissions needed, rate limits, pagination, output format, or whether it's read-only/destructive. For a tool with parameters and no output schema, this is insufficient.
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, efficient sentence with no wasted words. It's front-loaded and clear, though slightly under-specified. It earns a high score for brevity and directness.
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?
Given no annotations, no output schema, and a tool with parameters, the description is incomplete. It lacks details on behavior, output, error handling, or how parameters affect the listing. For a tool in a rich sibling set, more context is needed to be fully helpful.
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 fully documents parameters. The description adds no additional meaning beyond implying listing of channels, which aligns with the schema. Baseline score of 3 is appropriate as the schema handles parameter documentation adequately.
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 'Liste tous les canaux' clearly states the action (list) and resource (channels), but it's vague about scope and doesn't differentiate from sibling 'list_channels'. It doesn't specify whether it lists all channels globally or within a specific context, making it less precise than ideal.
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 like 'list_channels' or other channel-related tools. The description lacks context about prerequisites, constraints, or comparison with siblings, leaving usage unclear.
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?
No annotations are provided, so the description carries the full burden. It only states the action ('Obtenir les analytics') without disclosing behavioral traits such as permissions needed, rate limits, response format, or whether it's a safe read operation. This leaves significant gaps in understanding how the tool behaves.
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, efficient sentence in French that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, though it could benefit from more detail to improve clarity.
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?
Given the tool has no annotations, no output schema, and a simple input schema, the description is incomplete. It lacks details on what 'analytics' entails, the return format, or any behavioral context, making it insufficient for an agent to fully understand the tool's 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 the parameter 'embedId' clearly documented in the schema. The description adds no additional meaning beyond implying it's for a 'specific embed,' which is already covered by the schema. Baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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 states the purpose as 'Obtenir les analytics d'un embed spécifique' (Get analytics for a specific embed), which clearly indicates a read operation targeting analytics data. However, it doesn't differentiate from sibling tools like 'get_embed_details' or 'list_embeds' that might also retrieve embed-related information, making it somewhat vague about its specific scope.
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. The description doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage based on the name alone without explicit direction.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that it retrieves detailed server information, without mentioning whether this is a read-only operation, requires permissions, has rate limits, or what the output format might be. For a tool with no annotations, this leaves significant behavioral gaps, though it doesn't contradict any 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, efficient phrase in French that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool, though it could be more front-loaded with key details. There's no waste, but it lacks structural elements like bullet points or examples that might enhance clarity.
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?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It doesn't explain what 'detailed information' includes, how it differs from other info-retrieval siblings, or what the agent should expect in return. Without annotations or output schema, the description should provide more context to guide effective use, but it falls short.
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 1 parameter with 100% description coverage ('ID du serveur'), so the schema fully documents the parameter. The description adds no additional meaning about the parameter, such as where to find the guildId or if it's optional. With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't need to given the schema's clarity.
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 'Informations détaillées du serveur' (Detailed server information) states the general purpose of retrieving server details, which is clear but vague. It uses a verb-like phrase 'Informations détaillées' implying retrieval, but lacks specificity about what information is included or how it differs from similar tools like 'get_user_info' or 'statut_bot'. It's not tautological with the name 'get_server_info', but doesn't fully distinguish from siblings.
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. With siblings like 'get_user_info' for user details, 'list_channels' for channel listings, and 'statut_bot' for bot status, there's no indication of whether this tool is for general server metadata, configuration, or other specifics. Usage is implied only by the name and description, with no explicit context 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions exploring 'latest logs' but doesn't specify what that means operationally—e.g., whether it's a read-only query, how logs are retrieved (real-time vs. historical), any rate limits, or authentication needs. The description is minimal and fails to add meaningful context beyond the basic action.
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, efficient sentence in French, front-loaded with the core action. It's appropriately sized for a simple tool, with no wasted words, though it could be slightly more informative without losing conciseness.
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?
Given the tool's complexity (2 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what 'explore' entails operationally, the format or scope of returned logs, or any behavioral traits. With no output schema and minimal description, it leaves significant gaps for an AI agent to understand how to use the tool effectively.
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 ('lines' and 'level') well-documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides (e.g., it doesn't explain the 'level' enum values or default behavior). Baseline is 3 since the schema handles parameter documentation adequately.
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 'Explore les derniers logs du serveur' (Explore the latest server logs) states a general purpose with a verb ('Explore') and resource ('logs du serveur'), but it's vague about what 'explore' entails (e.g., viewing, filtering, retrieving). It doesn't distinguish from siblings like 'read_messages' or 'statut_bot', which might involve similar inspection tasks. This provides a basic understanding but lacks 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?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or sibling tools for comparison (e.g., 'read_messages' for chat logs or 'statut_bot' for bot status). Usage is implied by the name and description alone, with no explicit context or alternatives provided.
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?
No annotations are provided, so the description carries the full burden. It states 'lit' (reads), implying a read-only operation, but doesn't disclose behavioral traits like whether it requires specific permissions, returns paginated results, includes metadata (e.g., timestamps, authors), or has rate limits. For a tool with no annotations, this leaves significant gaps in understanding its behavior beyond the basic action.
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, efficient sentence ('Lit l'historique des messages') that directly states the action. It's front-loaded with the core purpose and wastes no words. However, it could be slightly more specific (e.g., 'Reads recent messages from a channel') to improve clarity without losing conciseness.
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?
Given no annotations, no output schema, and a simple 2-parameter tool, the description is incomplete. It lacks context on what the tool returns (e.g., list of messages, error handling), behavioral details (e.g., read-only nature, potential limits), and usage guidance. For a tool that likely returns data, the absence of output information is a notable gap, making it inadequate for full 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?
The input schema has 100% description coverage, with clear documentation for 'channelId' (ID du canal) and 'limit' (Nombre de messages, with min/max/default). The description adds no additional meaning beyond what the schema provides (e.g., it doesn't clarify the format of 'channelId' or how 'limit' affects ordering). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't need to heavily.
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 'Lit l'historique des messages' (Reads message history) states a clear verb ('lit' - reads) and resource ('historique des messages' - message history), providing a basic purpose. However, it doesn't differentiate from potential sibling tools like 'get_messages' or 'list_messages' (none exist in the provided list), and the phrasing is somewhat vague about what exactly 'history' entails. It's functional but lacks 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a channel ID), exclusions, or comparisons to other tools in the sibling list (e.g., 'envoyer_message' for sending or 'delete_message' for deletion). The agent must infer usage solely from the name and parameters.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description implies a read-only operation to check status, but does not specify whether it requires permissions, what data is returned, or any rate limits. It lacks details on output format or potential side effects, leaving behavioral traits unclear.
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 phrase in French that directly states the tool's purpose without redundancy. It is front-loaded and efficiently communicates the core function, with no wasted words or complex structure.
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?
Given the tool has no parameters and no output schema, the description is minimal but insufficient for a status-checking tool. It does not explain what status information is returned (e.g., uptime, errors, metrics), making it incomplete for an agent to understand the tool's full context and use it 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?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description does not need to add parameter semantics, and it appropriately avoids unnecessary details. A baseline score of 4 is assigned as the description does not mislead about parameters.
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 'Statut actuel du bot' (Current status of the bot) is a tautology that essentially restates the tool name 'statut_bot' (bot status) in French. It indicates the tool retrieves status information but lacks specificity about what status aspects are included (e.g., uptime, health, configuration). It distinguishes from siblings by focusing on bot status rather than operations like 'add_reaction' or 'create_channel', but remains vague.
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. The description does not mention prerequisites, timing, or context for usage. While the tool's purpose suggests it's for checking bot status, there is no explicit advice on scenarios like troubleshooting or monitoring, nor reference to related 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'creates' implies a write operation, the description doesn't specify permissions required, rate limits, whether the menu is interactive, or what happens on invocation. It lacks critical behavioral details for a tool that likely modifies chat state.
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, efficient sentence in French that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 tool with 7 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the return value, error conditions, or how the created menu behaves in context. Given the complexity and lack of structured data, more detail is needed to be 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 description adds no parameter-specific information beyond what's in the schema, which has 100% coverage with detailed descriptions for all 7 parameters. The baseline is 3 since the schema does the heavy lifting, but the description doesn't enhance understanding of parameter interactions or usage examples.
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 states the tool 'creates a message with a dropdown menu', which provides a clear verb ('creates') and resource ('message with dropdown menu'). However, it doesn't differentiate from sibling tools like 'create_button' or 'create_interactive_quiz', leaving the specific use case ambiguous. The purpose is understandable but lacks sibling distinction.
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. It doesn't mention any prerequisites, context, or exclusions, and doesn't reference sibling tools like 'create_button' or 'create_poll' for comparison. Usage is implied but not explicitly defined.
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?
With no annotations provided, the description carries full burden for behavioral disclosure but provides none. It doesn't mention required permissions, whether the operation is idempotent, what happens on duplicate names, how the role integrates with the system, or what the response contains. 'Crée' implies a write operation but gives no further 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 maximally concise - a single French phrase that directly states the tool's purpose. There's zero wasted language, though this comes at the cost of completeness. It's appropriately front-loaded with the core action.
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 mutation tool with 5 parameters and no annotations or output schema, the description is severely incomplete. It doesn't address behavioral aspects, usage context, return values, or error conditions. The 100% schema coverage helps with parameters, but the overall context for using this tool is inadequate.
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 5 parameters thoroughly. The description adds no parameter information beyond what's in the schema - it doesn't explain relationships between parameters, provide examples, or clarify edge cases. Baseline 3 is appropriate when schema does the heavy lifting.
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 'Crée un nouveau rôle' clearly states the action (create) and resource (new role) in French. It's specific enough to understand the basic function, but doesn't differentiate from sibling tools like 'edit_role' or 'delete_role' beyond the obvious verb difference.
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 like 'edit_role' or 'list_roles'. There's no mention of prerequisites, constraints, or typical use cases for creating a role versus modifying existing ones.
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?
No annotations are provided, so the description carries the full burden. It states the tool modifies an existing channel, implying a mutation, but doesn't disclose behavioral traits such as required permissions, whether changes are reversible, rate limits, or what happens on success/failure. This is a significant gap for a mutation tool with zero 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, efficient sentence in French that directly states the action. It's front-loaded with the core purpose and has zero wasted words, making it appropriately concise for the tool's complexity.
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?
Given this is a mutation tool with no annotations, no output schema, and 4 parameters, the description is incomplete. It lacks critical context like behavioral details, usage guidelines, and output expectations. The high schema coverage helps, but the description doesn't compensate for the missing structured data, leaving gaps for an AI 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?
Schema description coverage is 100%, so the schema already documents all parameters (channelId, name, categoryId, reason). The description doesn't add any meaning beyond what the schema provides, such as explaining how parameters interact or constraints on values. Baseline 3 is appropriate when schema does the 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 'Modifie un canal existant' (Modifies an existing channel) clearly states the verb (modifies) and resource (channel), but it's vague about what aspects can be modified. It distinguishes from obvious siblings like 'create_channel' or 'delete_channel' but doesn't differentiate from similar tools like 'edit_message' or 'edit_role' beyond the resource name.
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. It doesn't mention prerequisites (e.g., needing channel ID), exclusions, or comparisons to siblings like 'set_channel_permissions' or 'update_embed' that might overlap in functionality. Usage is implied only by the name and basic action.
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?
No annotations are provided, so the description carries full burden. It states the tool sends a message via webhook, implying a write operation, but doesn't disclose behavioral traits like authentication needs (though parameters suggest it), rate limits, error handling, or what happens on success/failure. This is inadequate for a mutation tool with zero 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, efficient sentence in French ('Envoie un message via webhook') with zero waste. It's appropriately sized and front-loaded, though it could benefit from more detail given the tool's complexity.
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?
Given the tool has 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks information on behavioral context, return values, error cases, or how it differs from sibling tools. For a webhook-sending tool with mutation implications, this minimal description is insufficient.
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 parameters documented in the schema. The description adds no additional meaning beyond the schema, such as explaining parameter relationships or usage examples. Baseline 3 is appropriate since the schema does the heavy lifting, but no extra value is provided.
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 'Envoie un message via webhook' clearly states the action (send) and resource (message via webhook), but it's vague about what kind of message or to what destination. It doesn't distinguish from sibling tools like 'envoyer_message' or 'create_webhook', leaving ambiguity about when to use this specific webhook-sending tool.
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. With siblings like 'envoyer_message' (send message) and 'create_webhook', the description offers no context about prerequisites (e.g., needing an existing webhook) or comparison to direct message-sending tools, leaving usage unclear.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a mutation operation ('définit' - sets) but doesn't specify whether this overwrites existing permissions, requires admin rights, has side effects, or how errors are handled. This leaves significant gaps in understanding 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 a single, efficient sentence in French that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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?
Given the complexity of a permission-setting tool with no annotations and no output schema, the description is insufficient. It doesn't explain what permissions are available, how they're formatted, the effect of the 'reset' parameter, or what the tool returns. This leaves critical context gaps for effective 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?
Schema description coverage is 100%, with clear descriptions for 'roleId', 'permissions', and 'reset'. The description adds no additional meaning beyond the schema, such as format examples or constraints. Since the schema does the heavy lifting, 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Définit les permissions d'un rôle' (Sets the permissions of a role) clearly states the verb ('définit' - sets) and resource ('permissions d'un rôle' - permissions of a role), making the basic purpose understandable. However, it doesn't differentiate from sibling tools like 'edit_role' or 'set_channel_permissions', leaving ambiguity about scope and 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 alternatives such as 'edit_role' (which might handle permissions) or 'set_channel_permissions'. The description lacks context about prerequisites, target scenarios, or exclusions, offering minimal usage direction.
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?
No annotations are provided, so the description carries full burden. It states the action ('add') which implies a write operation, but doesn't disclose behavioral traits like permission requirements, rate limits, whether it's idempotent, or what happens on failure. The description is minimal and lacks critical context 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 a single, efficient sentence in French with zero waste. It's appropriately sized for a simple tool and front-loaded with the core action. Every word earns 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?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., success confirmation, error details) or behavioral constraints. For a write operation with three parameters, more context is needed for reliable agent 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?
Schema description coverage is 100%, with all three parameters (channelId, messageId, emoji) documented in the schema. The description doesn't add any meaning beyond the schema, such as emoji format examples or ID sourcing. Baseline 3 is appropriate as the schema does the heavy lifting.
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 'Ajoute une réaction emoji' clearly states the action (add) and resource (emoji reaction) in French. It's specific about what the tool does, though it doesn't explicitly differentiate from sibling tools like 'edit_message' or 'create_button' which might also involve message interactions.
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. The description doesn't mention prerequisites (e.g., needing message and channel IDs), exclusions, or related tools like 'edit_message' for modifying reactions. Usage is implied but not explicitly stated.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('adds') which implies a write/mutation operation, but doesn't disclose any behavioral traits like required permissions, whether the operation is idempotent, what happens if the role is already assigned, or what the response looks like. This leaves significant gaps for agent understanding.
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, efficient French sentence that directly states the tool's purpose without any wasted words. It's appropriately sized for a simple mutation operation and front-loads the essential 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?
For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address behavioral aspects like permissions, idempotency, or error conditions, nor does it describe what the tool returns. Given the complexity of role management operations, more context is needed for proper agent usage.
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 clearly documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the structured schema fields. This meets the baseline expectation when schema coverage is complete.
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 'Ajoute un rôle à un membre' clearly states the action (adds) and resource (role to member) in French, making the purpose immediately understandable. It doesn't distinguish from sibling tools like 'remove_role_from_member' or 'create_role', but the verb+resource combination is specific enough for basic understanding.
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 like 'create_role' or 'remove_role_from_member'. There's no mention of prerequisites, permissions required, or contextual constraints for role assignment.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool attaches custom JavaScript code to a button, implying a mutation operation, but doesn't mention permissions required, side effects, error conditions, or what happens if the function fails. This leaves significant gaps for a tool that executes user-provided code.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a tool with clear parameters documented elsewhere.
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 tool that attaches executable JavaScript code to UI elements (a potentially complex and sensitive operation), the description is insufficient. With no annotations, no output schema, and minimal behavioral context, it doesn't provide enough information about security implications, error handling, or expected outcomes to guide safe and effective 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?
Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds no additional semantic context about parameters beyond what's in the schema, such as format examples or constraints. The baseline score of 3 reflects adequate but minimal value addition.
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 action ('attache une fonction personnalisée') and target resource ('à un bouton d'embed existant'), making the purpose understandable. However, it doesn't differentiate from the sibling 'enregistrer_fonction_bouton' or 'supprimer_fonction_bouton', which appear related to button functions.
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 like 'enregistrer_fonction_bouton' or 'creer_embed'. It mentions the target is an existing embed button but doesn't specify prerequisites, constraints, or appropriate contexts for invocation.
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?
No annotations are provided, so the description carries full burden. It states the action ('Bannit') which implies a destructive, permanent removal, but doesn't disclose behavioral details like required permissions, whether bans are reversible (though 'unban_member' exists), rate limits, or what happens to the user's data. For a high-impact mutation tool, this is a significant gap.
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 in French with zero wasted words. It's appropriately sized and front-loaded with the core action, making it easy to parse quickly.
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 destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, reversibility, or response format. Given the high-stakes nature of banning and the lack of structured safety hints, more context is needed.
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 fully documented in the schema. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain format constraints for 'userId' or typical values for 'deleteMessageSeconds'). Baseline 3 is appropriate when the schema does the heavy lifting.
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 'Bannit un membre du serveur' clearly states the action (ban) and target (server member) in French. It's specific about what the tool does, though it doesn't explicitly differentiate from sibling tools like 'kick_member' or 'timeout_member' beyond the obvious difference in action severity.
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 like 'kick_member', 'timeout_member', or 'warn_member'. The description states what it does but offers no context about appropriate use cases, prerequisites, or comparisons to similar 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'coloration syntaxique' (syntax highlighting) and 'division automatique si trop long' (automatic splitting if too long), which adds some context about output behavior. However, it lacks details on permissions required, rate limits, error handling, or what the output looks like (e.g., a message in the channel). For a tool with no annotations, this is insufficient for safe and effective use.
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, efficient sentence in French that directly states the tool's function without unnecessary words. It's front-loaded with the core action and includes key behavioral traits (syntax highlighting, automatic splitting), making it easy to parse quickly. Every part of the sentence contributes essential 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?
Given the complexity of a tool that displays code in a channel, the description is incomplete. No annotations are provided to cover safety or behavioral aspects, and there's no output schema to describe the result. The description mentions syntax highlighting and splitting, but lacks details on permissions, errors, or visual output. For a tool with 3 parameters and no structured support, this leaves significant gaps 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?
Schema description coverage is 100%, with clear descriptions for all three parameters (channelId, code, language). The description doesn't add any additional meaning beyond the schema, such as examples for language values or formatting tips. Since the schema already documents parameters well, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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's function: 'Affiche du code avec coloration syntaxique et division automatique si trop long' (Displays code with syntax highlighting and automatic splitting if too long). It specifies the verb 'affiche' (displays) and the resource 'code', making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'envoyer_message' or 'creer_embed', which might also involve displaying content in channels.
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. It doesn't mention prerequisites, such as needing a valid channel ID, or compare it to other display tools in the sibling list (e.g., 'envoyer_message' for general messages, 'creer_embed' for rich embeds). Without this context, an agent might struggle to choose appropriately between similar 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Crée' indicates a write/mutation operation, the description lacks crucial behavioral information: what permissions are required, whether this is a one-time action or creates persistent interactive elements, what happens after button creation, or any rate limits or constraints. For a mutation tool with zero annotation coverage, this is insufficient.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality.
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 mutation tool with 6 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after button creation, how the button functions, what the response looks like, or any error conditions. Given the complexity of creating interactive UI elements and the lack of structured documentation, the description should provide more contextual information.
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 mentions creating a message with an interactive button, which implies the existence of message content and button configuration parameters. With 83% schema description coverage (5 of 6 parameters have descriptions in the schema), the baseline is 3. The description doesn't add specific parameter semantics beyond what's already documented in the schema's 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 states the action ('Crée un message avec un bouton interactif' - Creates a message with an interactive button), specifying both the creation of a message and the interactive button component. However, it doesn't distinguish this tool from similar sibling tools like 'create_interactive_quiz', 'create_poll', or 'create_menu', which also create interactive elements.
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. There are multiple sibling tools for creating interactive content (create_interactive_quiz, create_poll, create_menu), but the description offers no differentiation or context about when this specific button creation 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?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Crée un nouveau canal' implies a write operation but doesn't specify permissions required, rate limits, whether it's idempotent, or what happens on failure. For a mutation tool with zero annotation coverage, this is a significant gap in 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, efficient sentence in French that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 channel creation tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, or behavioral aspects like permissions needed. Given the complexity and lack of structured data, more context is required for 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 description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional parameter information beyond implying creation of a channel. This meets the baseline of 3 where the schema does the heavy lifting, but the description doesn't compensate with extra context.
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 'Crée un nouveau canal' clearly states the action (creates) and resource (new channel) in French, making the purpose immediately understandable. It doesn't differentiate from siblings like 'edit_channel' or 'delete_channel', but the verb 'creates' is specific enough to distinguish it as a creation 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 provides no guidance on when to use this tool versus alternatives like 'edit_channel' or 'delete_channel'. It doesn't mention prerequisites (e.g., needing admin permissions) or contextual constraints, leaving the agent to infer usage from the name alone.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'validation automatique et animations' but lacks details on permissions, side effects (e.g., if it posts to a channel), rate limits, or error handling. For a tool with 11 parameters and no annotations, this is insufficient.
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, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence contributes to understanding the tool's function, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return values, error cases, or behavioral nuances needed for effective use, leaving significant gaps in 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 description coverage is 100%, meaning all parameters are documented in the schema itself. The description adds no additional parameter details beyond what's in the schema, so it meets the baseline of 3 without compensating or adding 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 states the action ('Créer un quiz interactif') and key features ('validation automatique et animations'), providing a specific verb and resource. However, it doesn't differentiate from sibling tools like 'create_poll' or 'create_button', which might have overlapping interactive functionality, so it doesn't reach the highest score.
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 offers no guidance on when to use this tool versus alternatives, such as 'create_poll' or other interactive tools in the sibling list. There's no mention of prerequisites, context, or exclusions, leaving the agent with minimal usage direction.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It states the tool creates a poll but doesn't mention what happens after creation (e.g., where the poll appears, how users interact, if it's ephemeral or persistent, or any rate limits). This leaves significant gaps 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?
The description is a single, efficient sentence in French that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with no wasted 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?
Given the tool's complexity (a mutation with 5 parameters), no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, response format, or error handling, making it inadequate for safe and effective use by an AI 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?
Schema description coverage is 100%, so the schema already documents all parameters (channelId, question, options, duration, allowMultiple). The description adds no additional meaning beyond the schema, such as explaining the format of options or how duration affects the poll, meeting the baseline for high coverage.
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 verb 'Crée' (creates) and the resource 'sondage interactif avec boutons' (interactive poll with buttons), making the purpose specific. It distinguishes from siblings like 'create_interactive_quiz' by specifying 'poll' rather than 'quiz', though it doesn't explicitly contrast them.
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 like 'create_interactive_quiz' or 'create_button'. The description lacks context about prerequisites, such as needing a valid channel ID or permissions, or when polls are 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?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like required permissions, whether the webhook is reusable, rate limits, what happens on creation failure, or the expected output format. This is inadequate for a mutation tool with zero 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, efficient sentence in French with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
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 mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral context (e.g., permissions, side effects), output format, or error handling, which are critical for an agent to use this tool correctly in a real-world scenario.
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 (channelId, name, avatarUrl) and their purposes. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints, meeting the baseline for high schema coverage.
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 'Crée un webhook sur un canal' clearly states the action (creates) and resource (webhook on a channel) in French. It distinguishes from siblings like 'send_webhook' (sends messages via webhook) and 'list_webhooks' (lists existing webhooks), but doesn't specify what the webhook does or its purpose beyond creation.
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 is provided. It doesn't mention prerequisites (e.g., needing channel permissions), when not to use it, or compare it to similar tools like 'create_button' or 'create_channel' for automation purposes.
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?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Modifie' implies a mutation operation, but the description doesn't specify required permissions, whether changes are reversible, rate limits, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this is a significant gap in 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, efficient French phrase ('Modifie un rôle existant') that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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?
Given this is a mutation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain behavioral aspects like permissions, side effects, or return values. The agent lacks crucial context for safe and effective tool invocation beyond basic parameter documentation in the 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 100%, so the schema fully documents all 5 parameters (roleId, name, color, hoist, mentionable). The description adds no additional parameter information beyond what the schema provides. According to guidelines, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
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 'Modifie un rôle existant' clearly states the action (modify) and resource (existing role) in French. It distinguishes from sibling tools like 'create_role' (creation vs. modification) and 'delete_role' (modification vs. deletion). However, it doesn't specify what aspects of a role can be modified, which prevents a perfect score.
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. It doesn't mention prerequisites (e.g., needing an existing role ID), exclusions, or comparisons to similar tools like 'create_role' or 'delete_role'. The agent must infer usage from the tool name and schema alone.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'enregistre' implies a write/mutation operation, the description doesn't address critical behavioral aspects: required permissions, whether this overwrites existing functions, error conditions, side effects, or what happens on success. For a mutation tool with zero annotation coverage, this represents significant gaps in 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, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for the tool's complexity and front-loads the essential information. Every element of the description earns its place by specifying the action, target, and key constraint (button must exist).
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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address what the tool returns, error conditions, permissions required, or behavioral consequences. While the schema covers parameters well, the description fails to provide the contextual information needed for safe and effective use of this write 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 three parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't clarify parameter relationships, constraints, or usage patterns. With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't 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 states the action ('enregistre' - registers/saves) and the target resource ('une fonction personnalisée pour un bouton existant' - a custom function for an existing button). It specifies the button is identified by ID, which distinguishes it from creating new buttons. However, it doesn't explicitly differentiate from sibling tools like 'attacher_fonction_bouton_embed' or 'supprimer_fonction_bouton'.
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 minimal guidance - it mentions the button must exist and be identified by ID. However, it offers no explicit guidance on when to use this tool versus alternatives like 'attacher_fonction_bouton_embed' (which appears similar but for embed buttons) or 'supprimer_fonction_bouton' (for deletion). No prerequisites, exclusions, or comparison with sibling tools are provided.
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?
No annotations are provided, so the description carries full burden. 'Envoie un message texte simple' implies a write operation but doesn't disclose any behavioral traits: no mention of permissions required, rate limits, whether it's synchronous/asynchronous, error conditions, or what happens on success. For a mutation tool with zero annotation coverage, this is inadequate.
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, efficient French phrase that gets straight to the point. There's zero wasted language - every word contributes to conveying the tool's purpose. It's appropriately sized for what it communicates.
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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, what errors might occur, or any behavioral constraints. Given the complexity of sending messages in a Discord context (permissions, rate limits, formatting), the description should provide more complete 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%, with both parameters clearly documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema (channelId and content). With complete schema coverage, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Envoie un message texte simple' clearly states the action (send) and resource (text message) in French. It's specific about sending a simple text message, though it doesn't explicitly differentiate from sibling tools like 'send_webhook' or 'edit_message' which also involve messaging.
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. With many sibling tools involving messaging (send_webhook, edit_message, create_poll, etc.), there's no indication of when this simple text message sending is preferred over other message-related 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves detailed user information but doesn't specify what 'detailed' entails, whether it requires permissions, if it's read-only, or any rate limits. This leaves significant gaps in understanding the tool's behavior and constraints.
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, efficient sentence in French that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured for quick understanding.
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?
Given no annotations and no output schema, the description is incomplete for a tool that likely returns complex user data. It doesn't hint at the structure or content of the returned information, leaving the agent uncertain about what 'detailed information' includes, which is a significant gap for effective tool 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 description coverage is 100%, with clear descriptions for 'userId' and 'guildId' in the input schema. The description adds no additional meaning beyond the schema, such as explaining the relationship between userId and guildId or providing examples. Baseline score of 3 is appropriate as the schema adequately documents 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 'Obtenir des informations détaillées sur un utilisateur' clearly states the action (obtain) and resource (user information) in French, making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'get_server_info' or 'list_members', but the specificity of 'detailed information about a user' is sufficient for clarity 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 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 'get_server_info'. It lacks context on prerequisites, exclusions, or specific scenarios where this tool is preferred, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action but doesn't explain what 'kick' entails (e.g., temporary removal vs. permanent ban, notification to the member, audit log entry, or whether the member can rejoin). For a destructive operation, this is a significant gap in 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, clear sentence in French that directly states the tool's purpose without unnecessary words. It's front-loaded and efficiently communicates the core functionality, making it easy to parse quickly.
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 destructive tool with no annotations and no output schema, the description is incomplete. It lacks critical context such as what the kick action does behaviorally, potential side effects, required permissions, or what the return value might be (e.g., success confirmation or error). This leaves significant gaps for an AI agent to understand the tool fully.
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 ('userId' and 'reason') adequately. The description doesn't add any additional meaning beyond what's in the schema, such as format examples or constraints, which aligns with the baseline score when schema coverage is high.
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 action ('Expulse' meaning kick/expel) and the resource ('un membre du serveur' meaning a server member), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'ban_member' or 'timeout_member', which would require a 5.
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 like 'ban_member', 'timeout_member', or 'remove_role_from_member'. It also doesn't mention prerequisites such as required permissions or appropriate contexts for kicking a member.
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?
With no annotations, the description carries full burden but only states what the tool does, not how it behaves. It lacks details on permissions needed, rate limits, pagination, output format, or error conditions—critical for a list operation in a Discord-like 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, efficient sentence in French that directly states the tool's purpose without fluff. It's appropriately sized for a simple list tool and front-loaded with essential 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?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'canaux' entails (e.g., channel objects with IDs/names), how results are returned, or behavioral aspects like permissions, making it incomplete for safe and effective 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?
Schema description coverage is 100%, so the schema fully documents the single parameter 'type' with enum and default. The description adds no parameter-specific information beyond implying 'all' channels, which aligns with the default but doesn't elaborate on filtering semantics.
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 'Liste tous les canaux du serveur' clearly states the action (list) and resource (channels), with 'tous' indicating comprehensiveness. However, it doesn't differentiate from sibling 'get_channels' (which appears to serve a similar purpose), leaving some ambiguity about when to use each.
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 like 'get_channels'. The description implies a complete listing but doesn't specify context, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Liste') but doesn't mention whether this is a read-only operation, if it requires permissions, how results are returned (e.g., pagination, format), or any rate limits. This is a significant gap for a tool with potential complexity in member listing.
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, efficient sentence in French that directly states the tool's purpose. It's front-loaded with the core action and resource, with no wasted words, though it could benefit from slight elaboration for better completeness.
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?
Given no annotations, no output schema, and a tool that likely returns structured member data, the description is incomplete. It doesn't explain what information is returned (e.g., member IDs, names, roles), how to handle large lists, or any behavioral nuances, leaving the agent under-informed for effective 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?
Schema description coverage is 100%, so the schema fully documents both parameters (guildId and limit). The description adds no additional meaning beyond implying the tool operates on a server, which is already covered by the guildId parameter's description. Baseline 3 is appropriate when the schema does the heavy lifting.
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 verb ('Liste') and resource ('membres et leurs rôles d'un serveur'), making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'get_user_info' or 'list_roles', but the focus on members with roles is specific enough for basic clarity.
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 like 'get_user_info' for individual members or 'list_roles' for roles alone. The description implies usage for listing members with roles, but lacks explicit context or exclusions, leaving the agent to infer based on tool names alone.
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?
With no annotations, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like pagination, rate limits, permissions required, or output format, which are critical for a list 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, efficient sentence in French with zero waste. It's front-loaded and appropriately sized for a simple tool.
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?
Given no annotations, no output schema, and a simple but incomplete description, this is inadequate. A list tool should clarify output format, pagination, or permissions, which are missing here.
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 no parameter semantics beyond the schema, which has 100% coverage for the single parameter. With 0 parameters documented in the description, the baseline is 4 as it doesn't need to compensate, but it also doesn't enhance understanding.
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 'Liste tous les rôles du serveur' clearly states the action (list) and resource (server roles), but it's vague about scope and doesn't distinguish from siblings like 'get_server_info' or 'list_members'. It's functional but lacks specificity about what 'tous' entails.
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 prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('move a member') but doesn't describe what this entails operationally - whether it requires specific bot permissions, what happens if the member isn't in a voice channel, whether it works across servers, or what the expected outcome looks like. For a mutation tool with zero annotation coverage, this is insufficient.
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 in French that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple tool with two parameters.
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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like required permissions, error conditions, or what constitutes success. Given the server context with many member management tools, more guidance would be helpful.
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 (userId and channelId). The description doesn't add any additional semantic context about these parameters beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting.
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 action ('Déplace' - moves) and the target resource ('un membre vers un salon vocal' - a member to a voice channel). It's specific about what the tool does, though it doesn't explicitly differentiate from siblings like 'kick_member' or 'timeout_member' which also affect member positions.
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. The description doesn't mention prerequisites (e.g., member must be in a voice channel already), constraints (e.g., bot permissions needed), or when other tools like 'kick_member' might be more 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?
No annotations are provided, so the description carries full burden. It implies a mutation (removing a role), but doesn't disclose behavioral traits like required permissions, whether the change is reversible, effects on the member, or error conditions. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence in French, front-loaded with the core action. It's appropriately sized for a simple tool, with no wasted words, though it could be slightly more informative without losing conciseness.
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?
Given the tool's complexity (a mutation with no annotations and no output schema), the description is incomplete. It lacks details on behavioral aspects, usage context, and output expectations. For a role-removal operation, more information on permissions, effects, and error handling would be needed for adequate 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 description coverage is 100%, with clear descriptions for 'userId' (ID du membre) and 'roleId' (ID du rôle à retirer). The description adds no additional meaning beyond the schema, such as format examples or constraints. Baseline 3 is appropriate since the schema does the heavy lifting, but no extra value is provided.
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 'Retire un rôle d'un membre' clearly states the action (retire/remove) and the target (a role from a member) in French. It's specific about what the tool does, though it doesn't explicitly differentiate from sibling tools like 'add_role_to_member' or 'delete_role' beyond the verb choice. The purpose is unambiguous but lacks sibling comparison.
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. It doesn't mention prerequisites, context, or exclusions, such as whether it's for managing user permissions or part of a workflow. With siblings like 'add_role_to_member' and 'delete_role', there's no indication of when removal is appropriate over deletion or other actions.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('retire') implying a mutation, but doesn't describe effects (e.g., whether it logs the reason, requires permissions, or affects member status), making it insufficient for a mutation tool with zero 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, efficient sentence in French that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero waste.
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?
Given the tool's complexity as a mutation (removing a timeout) with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., permissions, side effects) and doesn't explain the return values or error cases, leaving significant gaps for an AI 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?
Schema description coverage is 100%, with parameters 'userId' and 'reason' fully documented in the schema. The description adds no additional meaning beyond the schema, such as explaining the 'reason' parameter's purpose or format, so it meets the baseline of 3.
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 'Retire le timeout d'un membre' clearly states the action (remove) and target (timeout of a member) in French. It's specific enough to understand the basic function, though it doesn't explicitly differentiate from sibling tools like 'timeout_member' or 'unban_member' beyond the verb choice.
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. It doesn't mention prerequisites (e.g., a member must be timed out first), contrast with 'timeout_member' for setting timeouts, or specify contexts like moderation scenarios.
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?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose required permissions, whether changes are reversible, rate limits, or what happens to existing permissions not mentioned. 'Définit' implies a write/mutation operation, but no safety or side-effect information is given.
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, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized and front-loaded with the essential 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?
For a mutation tool with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what permissions can be set, how they interact, what the tool returns, or any error conditions. The context signals indicate significant complexity that isn't addressed.
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 documented in the schema. The description adds no additional meaning about parameters beyond what's in the schema (e.g., format of permission strings, interaction between allow/deny arrays). Baseline 3 is appropriate when schema does the heavy lifting.
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 action ('Définit les permissions') and target resource ('d'un canal pour un rôle'), making the purpose understandable. It distinguishes from general permission tools like 'set_role_permissions' by specifying channel-level permissions, though it doesn't explicitly contrast with all siblings.
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 like 'set_role_permissions' or 'edit_role'. The description implies it's for channel-specific role permissions but offers no context about prerequisites, appropriate scenarios, 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions animation and retry options, but doesn't describe what the tool actually does (e.g., posts a message, updates UI), potential side effects (e.g., channel notifications), permissions required, rate limits, or error handling. For a tool with 10 parameters and no annotations, this is a significant gap in 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, efficient sentence in French that front-loads the core purpose. Every word earns its place by specifying key features (animation, retry option) without redundancy. It's appropriately sized for a tool with many parameters but clear functionality.
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?
Given the tool's complexity (10 parameters, no annotations, no output schema), the description is incomplete. It lacks context on what the tool outputs (e.g., a message ID, embed object), behavioral details (e.g., interactive elements, user feedback), and how it integrates with other tools. For a display tool with rich parameters, more guidance on usage and effects is needed.
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 thoroughly. The description adds no additional parameter semantics beyond implying that 'isSuccess' triggers different animations and 'showRetry' controls UI elements. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't compensate with extra context like parameter interactions or examples.
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's purpose: 'Afficher un résultat de jeu avec animation de réussite/échec et option de recommencer' (Display a game result with success/failure animation and retry option). It specifies the verb ('Afficher'), resource ('résultat de jeu'), and key features (animation, retry option). However, it doesn't explicitly differentiate from sibling tools like 'create_interactive_quiz' or 'deploy_rpg', which might also handle game outcomes.
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. It doesn't mention prerequisites (e.g., after a game ends), exclusions (e.g., not for real-time updates), or comparisons to siblings like 'creer_embed' or 'update_embed' that might handle similar display tasks. Usage is implied by the name but not explicitly stated.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Supprime' clearly indicates a destructive mutation, the description doesn't address permissions needed, whether the deletion is reversible, what happens to associated data, or what the response looks like. This is inadequate for a mutation tool with zero 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, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a simple operation and front-loads the core functionality.
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 destructive mutation tool with no annotations and no output schema, the description is insufficient. It doesn't address behavioral aspects like permissions, reversibility, or response format. While concise, it lacks the completeness needed for an agent to safely invoke this tool without additional 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%, so the schema already documents the single 'buttonId' parameter. The description doesn't add any additional parameter context beyond what's in the schema, such as format examples or constraints. Baseline 3 is appropriate when the schema handles parameter documentation adequately.
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 action ('Supprime' - delete) and the resource ('la fonction personnalisée d'un bouton' - custom function of a button), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'lister_fonctions_boutons' or 'attacher_fonction_bouton_embed', which would be needed for a perfect score.
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, prerequisites, or exclusions. It's a bare statement of function with no contextual usage information, leaving the agent to infer when this operation 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?
With no annotations provided, the description carries full burden but only states it's a temporary mute without detailing behavioral aspects. It doesn't mention required permissions, whether the timeout is reversible (though 'remove_timeout' sibling exists), rate limits, what happens if applied repeatedly, or what the tool returns. For a mutation tool with zero annotation coverage, this is insufficient.
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 sentence, zero waste. The description is front-loaded with the core action and includes helpful parenthetical clarification about it being a temporary mute. Every word earns 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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, permission requirements, or how it differs from similar moderation tools. The 100% schema coverage helps with parameters, but behavioral and contextual gaps remain significant.
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 all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema (userId, duration in minutes, reason). Baseline 3 is appropriate when schema does the heavy lifting.
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 action ('Applique un timeout') and target resource ('à un membre'), with additional clarification that it's a temporary mute. It distinguishes from siblings like 'ban_member' (permanent) and 'remove_timeout' (reverse action), but doesn't explicitly contrast with 'warn_member' or 'kick_member' which are different 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 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 like 'warn_member', 'kick_member', or 'ban_member'. The description doesn't mention prerequisites (e.g., moderation permissions) or appropriate contexts for timeout versus other moderation actions.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Débannit un utilisateur' implies a mutation operation that reverses a ban, but it doesn't specify required permissions, whether the action is reversible, rate limits, or what happens if the user isn't banned. This is inadequate for a mutation tool with zero 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, efficient French phrase that directly states the tool's function with zero wasted words. It's appropriately sized and front-loaded, making it immediately understandable without unnecessary elaboration.
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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, or behavioral nuances. Given the complexity of user moderation and the lack of structured data, more context is needed for the agent to use this tool effectively.
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 ('userId' and 'reason') clearly documented in the schema. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline score of 3 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Débannit un utilisateur' clearly states the verb ('unbans') and resource ('a user') in French, making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'ban_member' or 'remove_timeout' which might handle similar user moderation actions, so it falls short of a perfect score.
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 like 'remove_timeout' or 'kick_member', nor does it mention prerequisites such as the user needing to be banned first. It's a basic statement of function with no contextual usage information.
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?
With no annotations, the description carries full burden but only mentions 'validation' vaguely. It doesn't disclose critical behaviors: whether this is a mutating operation (likely yes), authentication needs, rate limits, error responses, or what 'validation' entails (e.g., file type checks). The description is insufficient for a tool with potential 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, efficient sentence in French that directly states the tool's purpose. It's front-loaded with the core action and includes a useful detail ('validation') without unnecessary elaboration.
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 file upload tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., mutating nature, error handling), usage context, and expected outcomes. The mention of 'validation' is vague and doesn't compensate for the missing structured information.
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 well-documented in the schema. The description adds no additional parameter semantics beyond implying file upload and validation, which is already clear from the tool name and schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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 action ('Upload un fichier local') and target ('vers un canal Discord'), specifying it's a file upload to a Discord channel. It distinguishes from siblings like 'envoyer_message' (send message) by focusing on file uploads, though it doesn't explicitly mention validation as a differentiator.
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 is provided. While 'validation' hints at error handling, there's no mention of prerequisites (e.g., bot permissions), constraints (e.g., file size limits), or when to choose other tools like 'send_webhook' for file sharing.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this adds a warning but doesn't explain what that means operationally: whether warnings are logged, visible to the member, have expiration, require specific permissions, or what the response looks like. For a moderation tool with zero annotation coverage, this leaves significant behavioral 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, efficient sentence that communicates the core purpose without any wasted words. It's appropriately front-loaded with the essential 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?
For a moderation tool that presumably mutates member state, the description is insufficient given the lack of annotations and output schema. It doesn't explain what 'adding a warning' entails operationally, what permissions are required, what happens after the warning is added, or how this differs from similar sibling tools.
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 adequately. The description doesn't add any additional context about parameter semantics beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.
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 action ('Ajoute un avertissement') and target resource ('à un membre'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'timeout_member' or 'ban_member' which serve related moderation functions.
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 like 'timeout_member', 'kick_member', or 'ban_member'. There's no indication of severity levels, prerequisites, or appropriate contexts for warnings versus more severe actions.
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?
No annotations are provided, so the description carries full burden. It states the tool deploys a persistent mini-RPG, implying a write operation with ongoing effects, but doesn't disclose behavioral traits like permissions needed, whether it's idempotent, rate limits, or what 'persistent' entails (e.g., data storage, runtime). This leaves significant gaps 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?
The description is a single, efficient sentence in French that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every part contributing essential 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?
Given the tool likely involves mutation (deploying a game) with no annotations and no output schema, the description is incomplete. It doesn't explain what 'deploie' entails operationally, what the RPG does, how persistence works, or what happens on invocation. For a zero-param tool, it's minimal but lacks needed context for safe use.
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 0 parameters and 100% schema description coverage, the baseline is 4. The description adds context by specifying deployment to a channel, but since there are no parameters to document, it doesn't need to compensate for schema gaps.
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 action ('déploie' meaning 'deploys') and the resource ('mini-RPG persistant'), specifying it deploys to a specified channel. It distinguishes from siblings like create_channel or create_interactive_quiz by focusing on RPG deployment, but doesn't explicitly differentiate from other game-related tools (none are listed).
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. The description mentions deploying to a 'canal spécifié' (specified channel), but doesn't clarify prerequisites, when-not-to-use scenarios, or how it relates to siblings like create_interactive_quiz or show_game_result.
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?
No annotations are provided, so the description carries the full burden. It states it lists functions but doesn't disclose behavioral traits such as whether it's read-only, paginated, or requires specific permissions. The description is minimal and doesn't add context beyond the basic action, leaving gaps in understanding how the tool behaves.
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 directly states the tool's purpose without any fluff. It's front-loaded and appropriately sized for a simple listing tool, making it easy for an agent to parse quickly. Every word earns 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?
Given the complexity (a listing tool with no parameters) and lack of annotations or output schema, the description is incomplete. It doesn't explain what the output includes (e.g., format, fields) or any constraints. For a tool with no structured data to fall back on, this leaves significant gaps in understanding its full behavior.
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 tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The description appropriately doesn't mention parameters, which is efficient. Baseline for 0 params is 4, as it avoids unnecessary information.
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 verb ('Liste') and resource ('fonctions personnalisées enregistrées pour les boutons'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'list_embeds' or 'list_channels', which reduces specificity. The title being null doesn't affect this score since the description itself is clear.
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. With siblings like 'enregistrer_fonction_bouton' and 'supprimer_fonction_bouton', it's implied for listing, but there's no explicit mention of context, prerequisites, or exclusions. This leaves the agent to infer usage based on the name alone.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Liste') but doesn't mention whether this is a read-only operation, what permissions are required, the format of the returned list, or any rate limits. This is inadequate for a tool with zero 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, efficient sentence in French that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
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's low complexity (one parameter, no output schema, no annotations), the description is minimally complete but lacks depth. It doesn't explain the return format or behavioral aspects, which are important for an agent to use it correctly, though the schema covers the parameter well.
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, with 'channelId' clearly documented as 'ID du canal'. The description doesn't add any extra meaning beyond this, such as explaining what a 'canal' refers to in context. Since the schema does the heavy lifting, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Liste tous les webhooks d'un canal' clearly states the verb ('Liste') and resource ('webhooks d'un canal'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'create_webhook' or 'send_webhook' beyond the basic action, which prevents a perfect score.
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 (e.g., 'create_webhook' for creating webhooks or 'send_webhook' for sending them). It lacks context about prerequisites or exclusions, leaving usage entirely implicit.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Arrêter') but doesn't clarify if this is a destructive operation, requires specific permissions, has side effects (e.g., stopping updates without deleting the embed), or what the response looks like. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence in French that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and target, making it easy to parse quickly. Every word contributes to understanding the tool's function.
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 tool with one parameter and no output schema, the description is minimally adequate but lacks depth. It doesn't explain what happens after stopping auto-update (e.g., does the embed remain static?), potential errors, or integration with siblings like 'list_auto_update_embeds'. With no annotations and incomplete behavioral context, it meets basic needs but leaves room for improvement.
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, with 'embedId' documented as 'ID du message embed'. The description doesn't add any parameter details beyond this, such as format examples or constraints. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema already provides adequate parameter information.
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 'Arrêter l'auto-update d'un embed' clearly states the action (stop) and target (auto-update of an embed). It uses a specific verb and resource, making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'update_embed' or 'list_auto_update_embeds', which would require mentioning what distinguishes this tool from those.
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. It doesn't mention prerequisites (e.g., needing an embed with auto-update enabled), exclusions, or related tools like 'update_embed' for modifying other aspects. Without such context, the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does without mentioning whether it's read-only, requires authentication, has rate limits, or what the output format might be (e.g., list structure, pagination). This leaves significant gaps in understanding 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 a single, clear sentence in French that directly states the tool's purpose without any unnecessary words or fluff. It is front-loaded and perfectly sized for its simple function, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate as a basic statement of purpose. However, it lacks details on output format (e.g., what data is returned) and behavioral context (e.g., read-only nature), which could be important for an AI agent to use it effectively, making it only minimally 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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, as there are none to explain, which is efficient and avoids redundancy.
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 verb ('Lister' meaning 'List') and resource ('embeds avec auto-update actif' meaning 'embeds with auto-update active'), providing a specific purpose. However, it doesn't explicitly differentiate from the sibling tool 'list_embeds', which likely lists all embeds regardless of auto-update status, leaving some ambiguity about sibling distinction.
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 like 'list_embeds' or 'stop_embed_auto_update'. It lacks context about prerequisites, such as whether it requires specific permissions or server settings, making it minimally helpful for decision-making.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves details for editing and returns structured properties, but lacks critical behavioral information such as required permissions, rate limits, error conditions, or whether it's a read-only operation. The description is insufficient for a tool that interacts with Discord resources.
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 perfectly concise and front-loaded: the first sentence states the core purpose, and the second sentence adds valuable context about the return format. Every sentence earns its place with no wasted words, making it easy for an agent to parse quickly.
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's moderate complexity (retrieving Discord embed details) and the absence of both annotations and an output schema, the description is incomplete. It covers the purpose and return format but misses behavioral aspects like permissions, errors, and rate limits. However, it's adequate as a minimum viable description for a read 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 three parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema—it doesn't explain relationships between parameters or provide usage examples. Baseline 3 is appropriate when 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 ('Récupère les détails complets') and resource ('d'un embed existant'), and distinguishes it from siblings like 'list_embeds' (which likely lists multiple embeds) and 'update_embed' (which modifies rather than retrieves). The purpose is precise 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 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. It doesn't mention when to choose 'get_embed_details' over 'list_embeds' or other embed-related tools, nor does it specify any prerequisites or exclusions for usage. The context is implied but not 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?
With no annotations provided, the description carries full burden. It does disclose important behavioral traits: the Discord mention support differences between title/authorName/footerText (no mentions) versus description (supports mentions). However, it doesn't address critical mutation behaviors like whether changes are reversible, what permissions are required, rate limits, or error conditions. The description adds value but leaves significant gaps 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two focused paragraphs. The first sentence clearly states the purpose, and subsequent sentences add specific capabilities and important constraints. The Discord mentions warning is front-loaded with an emoji for emphasis. While efficient, the second paragraph could be slightly more integrated with the first.
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 complex mutation tool with 22 parameters and no annotations or output schema, the description is moderately complete. It covers the tool's purpose and some behavioral constraints (mention support), but lacks critical context about mutation consequences, permissions, error handling, and response format. Given the complexity and absence of structured safety information, the description should provide more comprehensive 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?
Schema description coverage is 100%, so the schema already documents all 22 parameters thoroughly. The description adds minimal parameter semantics beyond the schema - it mentions the four image positions (authorIcon, thumbnail, image, footerIcon) and theme application, but these are already covered in the schema. The baseline of 3 is appropriate when 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 ('Modifie un embed existant') and comprehensively lists the resources that can be modified (title, description, color, image positions, fields, buttons, and themes). It distinguishes itself from sibling tools like 'creer_embed' (create) and 'edit_message' (general message editing) by focusing specifically on embed modification.
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 like 'creer_embed' (for creating new embeds) or 'edit_message' (for non-embed message edits). It mentions applying predefined themes but doesn't explain when this is appropriate or what prerequisites exist for using the tool.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions scanning and listing messages with embeds, which implies a read-only operation, but doesn't specify if it requires specific permissions, has rate limits, or how it handles pagination beyond the 'limit' parameter. The description adds some context about returning data for editing, but lacks details on performance, error conditions, or side effects that would help an agent use it correctly.
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, efficient sentence that front-loads the core purpose (scanning and listing messages with embeds) and adds necessary context (returning data for editing). There's no wasted language, and every part of the sentence contributes directly to understanding the tool's function and output.
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's moderate complexity (scanning messages with specific content), no annotations, and no output schema, the description is partially complete. It explains what the tool does and the purpose of the output, but lacks details on behavioral aspects like permissions, rate limits, or error handling. For a tool with no structured output definition, it should ideally describe the return format more explicitly, though it hints at it with 'ID de messages, titres, descriptions, et toutes les infos des embeds'.
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, clearly documenting both parameters ('channelId' and 'limit'). The description doesn't add any parameter-specific information beyond what's in the schema, such as format examples or constraints. However, since the schema coverage is high, the baseline score of 3 is appropriate—the description doesn't compensate but doesn't need to, as the schema adequately defines the 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 specific action ('Scanne un channel et liste tous les messages avec des embeds'), identifies the resource (Discord channel messages with embeds), and distinguishes it from siblings like 'read_messages' (general message reading) or 'get_embed_details' (detailed analysis of specific embeds). It specifies the exact scope: scanning for messages containing embeds and returning comprehensive embed information for editing purposes.
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 find and edit embedded messages in a Discord channel, but it doesn't explicitly state when NOT to use it or name alternatives. For example, it doesn't clarify if this should be used instead of 'read_messages' for general message retrieval or 'get_embed_details' for analyzing specific embeds. The guidance is functional but lacks comparative context with sibling 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes multiple behavioral traits: the three-step process (obligatory/recommended/optional), automatic Phase 1 enhancements (cache, fallback, validation), and crucial Discord mention behavior (what supports/doesn't support mentions). It doesn't cover rate limits, authentication needs, or error handling, but provides substantial operational context beyond basic functionality.
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 excessively long (over 500 words) with multiple sections, emojis, and formatting that doesn't efficiently convey essential information. While structured with steps and sections, it includes tangential details like image pixel dimensions and Phase 1 enhancement marketing language. A more concise, front-loaded description would better serve an AI agent needing to quickly understand the tool's core purpose and usage.
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's high complexity (38 parameters, nested objects) and no output schema, the description provides substantial context about behavior and usage. However, it lacks information about return values, error conditions, or what happens after embed creation. The description covers many aspects but doesn't fully compensate for the absence of output schema and annotations for such a complex 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 100%, so the schema already documents all 38 parameters thoroughly. The description adds some semantic context by grouping parameters into three steps (channelId/title/description as obligatory, theme as recommended, image/thumbnail/buttons/fields as optional) and explaining image positions. However, it doesn't add significant meaning beyond what's already in the detailed schema descriptions, meeting the baseline for high 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: creating Discord embeds with a three-step process. It specifies the verb 'Créer' and resource 'embed Discord', distinguishing it from sibling tools like 'envoyer_message' (send message) or 'update_embed' (update existing embed). The title is null, so the description fully carries 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 clear context for when to use this tool (creating Discord embeds) and mentions using 'help=true' for interactive guidance. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools (e.g., 'envoyer_message' for simple messages, 'create_poll' for polls). The three-step structure implies a recommended usage flow but 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool retrieves image URLs (not modifies data), supports multiple sources (Unsplash, Picsum, local logos), and includes details like 'Picsum = illimité' for limit handling. However, it lacks information on error handling, rate limits, or authentication needs, which are important for a tool with diverse external sources.
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 front-loaded with a clear purpose and recommended mode, but it is overly verbose with extensive examples, thematic lists, and emojis that add visual clutter. While informative, the length (multiple sections like 'EXEMPLES D'USAGE', 'CATÉGORIES THÉMATIQUES') reduces conciseness, making it harder to scan quickly. Some sentences could be condensed without losing clarity.
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 (8 parameters, no annotations, no output schema), the description is mostly complete. It covers purpose, usage modes, parameter interactions, and examples, which helps the agent understand how to invoke it. However, it lacks details on output format (beyond 'URLs d'images'), error cases, or performance considerations, leaving some gaps for a tool with multiple external sources and modes.
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 description coverage is 100%, so the baseline is 3. The description adds significant value by explaining parameter semantics beyond the schema: it clarifies how 'mode' affects source selection (e.g., 'auto = détecte automatiquement'), provides thematic context for 'category' values (e.g., 'cyberpunk - Villes futuristes, néon'), and gives usage examples that illustrate parameter combinations. This compensates well, though it doesn't cover all parameters equally (e.g., 'sector' is less detailed).
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: 'Liste/Récupère les URLs d'images pour les embeds Discord' (List/Retrieve image URLs for Discord embeds). It specifies the verb ('list/retrieve'), resource ('image URLs'), and context ('for Discord embeds'), distinguishing it from sibling tools that manage channels, roles, messages, etc., which are unrelated to image retrieval.
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 guidance on when to use different modes: 'MODE AUTO (recommandé)' for automatic source detection, with detailed examples for AUTO, REAL, LOGO, PHOTO, and GIF modes. It explains what each mode does (e.g., 'Mode REAL (vraies photos thématiques)' for real thematic photos) and includes usage examples, helping the agent choose the right mode based on the desired outcome.
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:

[![-Serveur-Discord-MCP MCP server](https://glama.ai/mcp/servers/DeamonDev888/-Serveur-Discord-MCP/badges/card.svg)](https://glama.ai/mcp/servers/DeamonDev888/-Serveur-Discord-MCP)

Score Badge

Copy to your README.md:

[![-Serveur-Discord-MCP MCP server](https://glama.ai/mcp/servers/DeamonDev888/-Serveur-Discord-MCP/badges/score.svg)](https://glama.ai/mcp/servers/DeamonDev888/-Serveur-Discord-MCP)

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/DeamonDev888/-Serveur-Discord-MCP'

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