Skip to main content
Glama
CharityDEX

VoiceOS Discord MCP Server

by CharityDEX

Server Quality Checklist

58%
Profile completionA complete profile improves this server's visibility in search results.
  • Latest release: v1.0.0

  • Disambiguation4/5

    Most tools have distinct purposes (connect, list channels, read, send, reply), but list_discord_servers is ambiguous as it 'explains how to list' rather than listing, potentially overlapping with list_discord_channels.

    Naming Consistency5/5

    All tools consistently follow verb_noun pattern (e.g., connect_discord_bot, list_discord_channels), with clear and predictable naming.

    Tool Count4/5

    6 tools is reasonable for a Discord bot integration covering auth, listing, reading, and writing. Slightly narrow but not excessive.

    Completeness3/5

    Covers core operations but list_discord_servers only explains rather than actually retrieving servers, creating a functional gap. Missing update/delete message and server management tools.

  • Average 3.7/5 across 6 of 6 tools scored. Lowest: 2.1/5.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 0 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
  • Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.

    If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.

    MCP servers without a LICENSE cannot be installed.

  • 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

  • Behavior2/5

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

    The description mentions behavior when authentication is missing (returns a Composio Connect Link) but doesn't disclose what the tool returns on success, side effects, or any other behavioral traits. With 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.

    Conciseness2/5

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

    The description is one sentence but poorly structured, starting with 'Explain how to list' which is awkward. It tries to convey two separate points without clear organization.

    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 output schema and no annotations, the description should fully explain purpose and return value. It only partially covers authentication failure but not success behavior or expected output, leaving the agent uninformed.

    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 no parameters, so description has no burden to explain parameters. The description adds context about authentication, which is tangential but acceptable.

    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 says 'Explain how to list', which is ambiguous and seems like a help command rather than the actual listing operation. It doesn't clearly state that the tool performs the listing of servers.

    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 on when to use this tool versus siblings like list_discord_channels. It does not mention prerequisites or context of use.

    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?

    Discloses it's a write action and should be shown as a confirmation pill, providing some behavioral context. However, no annotations exist, and the description lacks details on error handling, rate limits, or idempotency.

    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?

    Two sentences, each serving a purpose: stating the action and specifying user confirmation. Efficient but could be slightly tighter.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness2/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    With 6 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return values, error conditions, or how to use optional parameters (channel_name/guild_id) 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 baseline is 3. The tool description repeats the need to confirm parameters but adds no new meaning beyond the schema.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    Clearly states 'Reply to a specific Discord message ID in a channel', which is a specific verb-resource combination. Distinguishes from siblings like 'send_discord_message' and 'read_discord_messages'.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines3/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    Indicates it's a write action requiring user confirmation, but does not explicitly contrast with sibling tools like 'send_discord_message' for new messages or 'read_discord_messages' for reading. No when-not-to-use guidance.

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

  • Behavior3/5

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

    With no annotations, the description reveals key behaviors: only returns channels the bot can discover, and prompts for authentication if missing. However, it omits details on invalid guild IDs, pagination, or error handling, leaving 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 two sentences, front-loaded with the core purpose, followed by practical guidance. Every sentence is useful and there is no redundancy.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness3/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    The description lacks any information about the return format (e.g., list of channel objects) or pagination behavior. Given no output schema, this is a notable gap for a list tool, but the guidance on parameters partially compensates.

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

    Parameters3/5

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

    Schema coverage is 100%, so the description adds little beyond restating the guild_id as 'when known'. It does not mention the text_only parameter at all, relying fully on the schema's description.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states the verb 'list' and resource 'Discord channels' with the context of the Composio DISCORDBOT's discoverable channels. It distinguishes from sibling tools that list servers or perform message actions.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines4/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The description advises providing a guild ID when known and notes the tool returns a Connect Link if auth is missing. It specifies when to use ('user asks what channels are available'), but does not explicitly exclude alternative tools.

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

  • Behavior3/5

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

    With no annotations provided, the description carries the full burden. It declares the tool is 'read-only', which is good, but does not disclose other behaviors like authentication requirements (bot presence in channel), rate limits, or error handling. Some behavioral context is added, but not exhaustive.

    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?

    Extremely concise and front-loaded: two sentences. The first clearly states the purpose and the second provides usage context. Every sentence adds value with no redundancy.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness3/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given 8 optional parameters, no output schema, and no annotations, the description is adequate for the core purpose but lacks details about return format (e.g., what fields are in messages) and edge cases (e.g., channel not found or no messages). The schema covers parameters but output is not described.

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

    Parameters3/5

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

    Schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond what the schema already explains for each parameter. It mentions channel_id as primary but the schema already covers all parameters with descriptions.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states the action: 'Read recent messages from a specific Discord channel by channel ID.' It uses a specific verb and resource, and distinguishes from sibling tools like send_discord_message or reply_discord_message by emphasizing it is a read-only action.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines4/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    Explicitly tells when to use: 'Use this when the user asks what is happening in a Discord channel or wants context from recent Discord messages.' It implies not for sending or replying by stating 'read-only action', but does not specify when not to use or alternatives in detail.

    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 must fully disclose behavioral traits. It labels itself as a 'write action' and mentions confirmation, but fails to disclose permissions, rate limits, side effects, or success/failure behavior. This is inadequate for a mutation tool.

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

    Conciseness5/5

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

    Two sentences, front-loaded with purpose, no unnecessary words. Every sentence adds value.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness3/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given 6 parameters and no output schema, the description covers purpose and usage but omits behavioral details like return value, error handling, and synchronization. This leaves agents with incomplete context for handling the 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 baseline is 3. Description adds minimal extra meaning, only repeating 'exact message content' and 'Discord messages limited to 2000 characters' which are already in schema. No further insight on how parameters interact.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    Description clearly states 'Send a new message to a specific Discord channel by channel ID.' It uses a specific verb (send) and resource (Discord channel), differentiating from sibling tools like read_discord_messages (read) and reply_discord_message (reply).

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines5/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    Explicitly instructs to show as a confirmation pill and confirm channel ID and message content with user before execution. This provides clear when-to-use and user interaction protocol, though it does not directly compare to siblings.

    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?

    No annotations are provided, so the description carries the full burden. It clearly states it creates a link for authentication, which is a non-destructive action. However, it omits details about the output (e.g., returns a URL) or whether user interaction is needed, so it's not fully transparent.

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

    Conciseness5/5

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

    Two sentences with zero wasted words. Front-loaded with the core action.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness4/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the tool's simplicity (no parameters, no output schema), the description is mostly complete. It explains purpose and usage. A minor gap is not describing the return value (e.g., a URL), but it's not critical for selection.

    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 zero parameters, so the description need not add parameter info. Baseline score of 4 is appropriate since no compensation is needed.

    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 a Composio Connect Link for Discord bot authentication. It uses specific verbs ('Create') and resources ('Composio Connect Link for authenticating the Discord bot/account connection'), and is distinct from sibling tools that focus on channels, servers, and messages.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines5/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    Explicitly tells when to use: 'whenever the user asks to connect Discord' or 'whenever another Discord tool reports that authentication is required.' This provides clear context and excludes alternatives.

    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

voiceos-discord-mcp MCP server

Copy to your README.md:

Score Badge

voiceos-discord-mcp MCP server

Copy to your README.md:

Latest Blog Posts

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/CharityDEX/voiceos-discord-mcp'

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