codex-discord-mcp

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation3/5
reply and send_message are described as identical in behavior, causing clear overlap and potential misselection. latest_generated_images and recover_generated_image also serve similar purposes with subtle differences that could confuse. Other tools are distinct enough.
Naming Consistency3/5
Naming mixes verb_noun patterns (send_message, edit_message) with bare verbs (reply, react) and noun phrases (latest_generated_images, bridge_status). While most names are readable, the inconsistency undermines predictability.
Tool Count4/5
At 11 tools, the count is reasonable for a Discord integration, though a few tools (reply/send_message) appear redundant and could be consolidated. Not excessive or thin.
Completeness4/5
Core Discord operations (send, edit, react, fetch, attachments) are covered, along with a queue mechanism and status check. Missing delete message and channel listing are minor gaps; agents can work around them using existing tools.
Average 3.8/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 17 commits in the last 12 weeks
- Last stable release on July 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides useful behavioral detail: messages are returned oldest first, and full search is not available. However, it omits the return format, default limit, and any rate-limit or error behavior, leaving gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states the core action with ordering, second adds a relevant API limitation. No filler, front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should clarify the return value, default limit, and parameter semantics. It does not, leaving significant operational gaps for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the 'limit' or 'channel' parameters. The phrase 'Discord channel history' hints at the channel, but 'limit' is entirely unexplained, failing to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Fetch'), resource ('Discord channel history'), and gives ordering ('oldest first') and scope ('recent'). It distinguishes this read tool from sibling write tools like send_message, reply, and edit_message.
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 intended use is implied ('Fetch recent Discord channel history') and the API limitation offers some context, but there is no explicit guidance about when to choose this over siblings or when not to use it. No alternatives are directly named.
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 must disclose behavioral traits. It only mentions 'allowlisted' as a constraint and vaguely references 'same behavior as reply' without elaborating on side effects, permissions, rate limits, or failure modes. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and both sentences add value (description and sibling distinction). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no output schema, but the description only provides basic send semantics. It omits parameter descriptions, reply behavior details, attachment handling, and any return/response info, making it insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain any of the four parameters (text, files, chat_id, reply_to). No semantics are added beyond the schema's bare field names.
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 sends a Discord message to an allowlisted chat, and distinguishes it from the sibling 'reply' by noting it's for non-reply sends. This provides a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly contrasts with the 'reply' sibling, clarifying when to use this tool (non-reply sends) and implying reply is for reply scenarios. This gives clear context and a named alternative.
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 must disclose behavior. It states the key restriction (only bot-sent messages can be edited), but does not disclose potential failure modes, authorization requirements, rate limits, or side effects. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple 3-parameter schema, no output schema, and no annotations. The description covers the core purpose and scope but omits parameter explanations and any note about return values or error conditions, leaving some gaps for a complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for the three required parameters (text, chat_id, message_id), and the description does not explain them. With 0% schema coverage, the description was expected to compensate but does not, leaving parameter semantics entirely to parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Edit', identifies the resource as 'a Discord message', and adds the scoping constraint 'previously sent by the bot', which clearly distinguishes it from siblings like send_message and reply.
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 condition 'previously sent by the bot' gives clear context that this tool is for modifying existing bot-sent messages, implying it should not be used for messages from other users or for sending new messages. However, it does not explicitly name alternatives or exclusions, so it falls between implied and clear 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 responsibility for behavioral disclosure. It does not explain what 'handled' means (e.g., permanent removal from queue, idempotence, or reversibility) or any side effects. This is a significant gap for a mutating operation, leaving the agent uncertain about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action and timing with zero unnecessary words. It is concise and well-structured, though it omits some behavioral context (covered elsewhere).
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 (one parameter, no output schema, no annotations), the description is nearly adequate, covering purpose and timing. However, it fails to clarify what 'handled' entails behaviorally, and the parameter semantics are underexplained. It meets the minimum viable threshold but leaves clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for queue_id, and the description does not mention the parameter at all. The parameter name is somewhat self-explanatory, but the description does not compensate for the lack of schema-level details, such as how to obtain the queue_id or what format it takes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('mark') and resource ('queued Discord message') and clearly states the action ('as handled'). It distinguishes this tool from sibling messaging tools (reply, send_message, etc.) by focusing on queue state management rather than message transmission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'after replying or deciding no reply is needed.' This gives clear contextual timing without naming alternatives, which is appropriate since no sibling tool performs this exact function. It lacks exclusionary guidance but is sufficient for the simple use case.
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?
No annotations are provided, so the description carries the full burden. It adds useful context about Unicode vs. custom emoji syntax, but does not disclose whether the reaction is additive, if permissions are required, or any error behavior beyond the implied mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and immediately useful syntax detail. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description covers the core action and emoji format, but it omits any error handling, success/failure behavior, or whether custom emoji must belong to the same server. Given the lack of annotations and output schema, a bit more context would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only explains the 'emoji' parameter format; 'chat_id' and 'message_id' are left implicit by name. This is a significant gap given the schema provides no 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 ('Add an emoji reaction') and resource ('Discord message'), with specific syntax details for Unicode and custom emoji that distinguish it from sibling messaging tools like reply and send_message.
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 purpose implies usage for reactions rather than sending or replying, but the description does not explicitly state when to use this tool over alternatives or provide any exclusions. It relies on the reader to infer from the verb 'react'.
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 carries the full burden. It discloses the core behavior (downloads all attachments, stores in local bridge inbox, returns absolute paths) but lacks details on edge cases, permissions, or side effects. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no wasted words. Every part contributes to understanding the tool's purpose and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description includes the return value (absolute paths) and the destination (local bridge inbox). For a simple 2-parameter tool, it covers the main functional aspects, though it lacks parameter descriptions and potential edge-case behavior. Overall, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not mention the parameters at all. The parameter names (chat_id, message_id) are somewhat self-explanatory from context, but the description fails to provide explicit semantics or formats, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (download), the resource (all attachments from a Discord message), and the outcome (return absolute paths). It is specific and distinguishes from sibling tools like send_message or reply.
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 attachments from a message need to be retrieved, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. The context is clear from the purpose, but no explicit alternatives or conditions are mentioned.
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, the description carries the full burden. It discloses that this is a read-only listing operation ('List') and defines the scope (only unhandled queued messages). It adds context about the lack of push channel, which justifies the tool's existence. It does not mention rates, ordering, or side effects, but the core behavioral trait is covered.
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 succinct sentences: the first states the primary purpose, the second provides the rationale. No extraneous information. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description should at least explain the 'limit' parameter and hint at the return structure. It does neither. While the purpose is clear, the missing parameter documentation represents a significant gap, making the description incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero description for the only parameter 'limit' (0% coverage), and the tool description does not mention it at all. The description fails to explain what 'limit' does, leaving the agent without any guidance on how to use the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states a specific verb and resource: 'List queued inbound Discord messages that have not been marked handled.' It distinguishes itself from siblings by emphasizing 'queued' and 'not marked handled,' and even explains the rationale ('no Discord push channel').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context for when to use the tool: 'Use this because Codex MCP has no Discord push channel.' This implies it is the intended polling mechanism for new messages, though it does not explicitly name alternative tools or exclusion criteria.
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 discloses the source directory (including default ~/.codex/generated_images) and the ordering (newest first). However, it does not explain what happens when no images exist, how the limit parameter affects results, or the exact return format beyond 'absolute paths'. These are meaningful gaps for a tool with zero annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and every clause adds value. The first sentence states exactly what the tool returns and from where, and the second provides a concrete use case. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter, the description covers the primary purpose and usage. However, it omits documentation of the limit parameter and any mention of default behavior when limit is not provided. Given there is no output schema, the description should have been more explicit about the return value's shape and the effect of the parameter. This is a clear, but not fatal, gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, 'limit', with no description, and the overall schema coverage is 0%. The description does not mention the parameter at all, leaving the agent to infer its meaning from the name. Since the description was expected to compensate for the low schema coverage, this is a significant omission, though the parameter name is somewhat intuitive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Return absolute paths of the most recently generated images from Codex's built-in image_gen output directory'. It specifies the resource (image_gen output directory) and the action (return absolute paths), and it distinguishes itself from siblings by focusing on generated images and providing paths for attachment. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: 'Use this to recover the path of an image you just generated so you can attach it via the files array of reply or send_message.' This provides clear usage context. It does not explicitly mention when not to use it or name alternatives, but the guidance is strong enough to make the intended use case obvious.
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 carries the full transparency burden. 'Show' clearly indicates a read-only operation, and the listed outputs give some behavioral insight. However, it does not mention potential side effects, authentication requirements, or failure modes, leaving some ambiguity for a status 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, concise sentence that front-loads the action and outputs without wasted words. It is perfectly sized for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-output-schema tool, the description sufficiently covers the main return values: bridge state path, queue counts, and Discord login status. It does not elaborate on what 'bridge state path' means or when to use it, but given the simplicity, it is largely 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 tool has zero parameters, so the schema is trivially complete. The description adds no parameter details, but none are needed. Baseline 4 is appropriate for a no-parameter tool.
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 'Show' and specifies three concrete outputs: bridge state path, queue counts, and Discord login status. This distinguishes it from sibling tools that send messages or manage conversations, and it is not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided, and no alternatives are mentioned. The name and description imply it is for status monitoring, which is adequate but not clearly stated. It is distinct from siblings by function, but the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing side effects. It clearly discloses that it decodes from the session log and writes to disk, and returns absolute paths. It does not mention failure modes or overwrite behavior, but the core behavior is transparent. This is strong given the absence 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences pack in the action, rationale, and parameter details without redundancy. Each sentence adds value: the first states the core function, the second explains the need and output, the third defines parameters. This is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and lack of output schema, the description provides sufficient context: it explains why the tool exists, what it returns, and how to pass results to reply/send_message. It doesn't address error handling or edge cases, but for a 2-parameter utility, it is nearly complete, hence a 4 rather than 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), so the description must compensate. It does so effectively by explaining 'count (default 1)' and 'session_file (absolute rollout path; defaults to the newest session),' adding meaning beyond the plain types. It doesn't specify constraints like valid ranges, but the core semantics are covered.
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 primary action: 'Recover the most recently generated image(s)... and write them to disk.' It distinguishes itself from siblings by explaining the Codex inline preview limitation and that this tool decodes and saves the image, differentiating it from tools like latest_generated_images or reply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool: when Codex's image_gen shows an inline preview but doesn't write a file. It also notes the output is 'ready to pass to the files array of reply/send_message,' indicating a clear integration point. However, it doesn't explicitly mention alternatives or when not to use it, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the source of chat_id, the semantic of reply_to, and the absolute path requirement for files. It omits error behavior, but for a simple messaging tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each adding necessary information: the action, the required chat_id source, and optional parameters. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, required parameter context, and optional parameter semantics. Given no output schema, the lack of return value discussion is acceptable. Minor gap: no explicit statement about success/failure 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?
Schema description coverage is 0%, yet the description compensates by explaining chat_id provenance, reply_to threading, and files path format. The text parameter is self-explanatory.
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 'Reply in Discord' with a specific verb and resource. It differentiates itself from siblings by requiring a chat_id from a queued message, which is a distinct use case.
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: 'Pass chat_id from a queued message' and optional reply_to threading. It does not explicitly exclude alternatives or state when not to use it, but the operational context is strong enough for an agent to select it.
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:

[![codex-discord-mcp MCP server](https://glama.ai/mcp/servers/Openclaw-Metis/codex-discord-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Openclaw-Metis/codex-discord-mcp)

Score Badge

Copy to your README.md:

[![codex-discord-mcp MCP server](https://glama.ai/mcp/servers/Openclaw-Metis/codex-discord-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Openclaw-Metis/codex-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/Openclaw-Metis/codex-discord-mcp'

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