Discourse MCP

Official

by discourse

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific resources and actions in the Discourse platform. For example, discourse_filter_topics handles topic filtering, discourse_get_chat_messages retrieves chat messages, and discourse_list_categories lists categories—each serves a unique function with no overlap that would cause confusion.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with the 'discourse_' prefix, such as discourse_list_categories, discourse_get_user, and discourse_read_post. This uniformity makes the tool set predictable and easy to navigate, with no deviations in naming conventions.
Tool Count5/5
With 14 tools, this server is well-scoped for interacting with a Discourse forum, covering key areas like topics, posts, chats, users, categories, tags, drafts, and search. Each tool earns its place by addressing a specific need without being overly broad or sparse.
Completeness4/5
The tool set provides comprehensive coverage for reading, listing, filtering, and searching core Discourse resources, with minor gaps. For instance, it lacks tools for creating or updating content (e.g., posting new topics or replies), which agents might need for full CRUD operations, but existing tools support most common workflows effectively.
Average 3.3/5 across 14 of 14 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- 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

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. 'Get basic user info' implies a read-only operation but doesn't specify permissions required, rate limits, error conditions (e.g., invalid username), or what 'basic' entails (e.g., public vs. private data). This leaves significant gaps for an agent to understand 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence ('Get basic user info.'), which is front-loaded and wastes no words. However, it borders on under-specification, as it could benefit from slightly more detail without losing efficiency.
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 low complexity (1 parameter, no nested objects) but lack of annotations and output schema, the description is incomplete. It doesn't explain what 'basic user info' returns, potential errors, or usage context, leaving the agent with insufficient information to use the tool effectively beyond its basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention the 'username' parameter at all, and schema description coverage is 0%, so it adds no meaning beyond the schema. With only one parameter and no schema descriptions, the baseline is 3, as the simple parameter is self-explanatory but undocumented. No compensation is provided for the coverage gap.
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 'Get basic user info' clearly states the verb ('Get') and resource ('user info'), making the purpose understandable. However, it's vague about what 'basic user info' includes and doesn't differentiate from potential sibling tools like 'discourse_list_user_posts' or 'discourse_list_user_chat_channels' that might also retrieve user-related data.
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 valid username), exclusions, or comparisons to sibling tools like 'discourse_search' that might also find user information. 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?
No annotations are provided, so the description carries the full burden. It only states the action ('search') without disclosing behavioral traits such as authentication requirements, rate limits, whether results are paginated, or what the output format looks like. For a search tool with no 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 extremely concise with just three words, front-loaded and zero waste. It efficiently conveys the core purpose without unnecessary elaboration, making it easy to scan and understand 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 tool's complexity (search functionality with 3 parameters), no annotations, no output schema, and low schema description coverage, the description is incomplete. It doesn't cover key aspects like result format, error handling, or behavioral constraints, leaving the agent with insufficient information to use the tool effectively.
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 33% (only 'query' has a description), with 3 parameters total. The description adds no meaning beyond the schema—it doesn't explain what 'with_private' does (e.g., include private content) or how 'max_results' affects pagination. It fails to compensate for the low coverage, leaving most parameters undocumented in both schema and 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 'Search site content' clearly indicates the verb 'search' and resource 'site content', but it's vague about what 'site content' encompasses (topics, posts, users, etc.) and doesn't distinguish from siblings like discourse_filter_topics or discourse_select_site. It states what the tool does 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?
No guidance on when to use this tool versus alternatives is provided. It doesn't mention when to prefer this over siblings like discourse_filter_topics for filtering or discourse_select_site for site selection, nor does it specify any prerequisites or exclusions. The description 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 the full burden of behavioral disclosure. It states 'Read a specific post,' which implies a read-only operation but does not specify details like authentication requirements, rate limits, error handling, or what data is returned (e.g., content, author, timestamps). This leaves significant gaps for a tool with no 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 extremely concise with a single sentence ('Read a specific post.'), which is front-loaded and wastes no words. It efficiently conveys the core action without unnecessary elaboration, making it easy to parse.
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 (one parameter, no annotations, no output schema), the description is incomplete. It does not explain what 'reading' entails (e.g., output format), potential errors, or usage context. For a tool with no structured support, more detail is needed to guide 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?
The input schema has one parameter (post_id) with 0% description coverage, so the schema provides no semantic details. The description adds no information about the parameter, such as what post_id represents or how to obtain it. However, with only one parameter and a straightforward tool, the baseline is 3 as the schema minimally defines the requirement.
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 basic action ('Read') and resource ('a specific post'), which is clear but minimal. It distinguishes from siblings like 'discourse_read_topic' by specifying 'post' rather than 'topic', but lacks detail on what reading entails (e.g., retrieving content, metadata). The purpose is vague beyond the basic verb-noun pairing.
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 does not mention prerequisites (e.g., needing a valid post_id), exclusions, or comparisons to siblings like 'discourse_read_topic' or 'discourse_list_user_posts'. The description offers 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?
No annotations are provided, so the description carries the full burden. It mentions 'if enabled,' which implies a conditional availability, but doesn't disclose other behavioral traits like whether this is a read-only operation, pagination behavior, rate limits, or what happens if tags are disabled. For a tool with zero annotation coverage, this leaves significant 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 extremely concise at just three words, with zero wasted text. It's front-loaded with the core action and resource, and the parenthetical adds necessary context without verbosity. 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 tool's simplicity (0 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what 'tags' are in this Discourse context, what 'if enabled' entails, or what the return value looks like. For a list operation, even with no parameters, more context on output and behavior would be helpful.
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 baseline for 0 parameters is 4, as the description doesn't need to compensate for missing schema information. No additional parameter semantics are required.
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 'List tags (if enabled)' states the verb ('List') and resource ('tags'), making the basic purpose clear. However, it's vague about what 'tags' are in this context and doesn't differentiate from sibling tools like 'discourse_list_categories' or 'discourse_list_user_posts' beyond the resource name. The parenthetical '(if enabled)' adds some context but doesn't fully specify 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?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing authentication), comparison to similar list tools, or exclusions. The '(if enabled)' hints at a conditional context but doesn't explain what enables tags or when this tool would fail.
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 mentions reading metadata and posts, implying a read-only operation, but doesn't specify authentication requirements, rate limits, error conditions, or what 'first N posts' means in practice (e.g., ordering, pagination). The description is minimal and lacks critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that directly states the tool's function without any fluff. It's front-loaded with the core action and resource, making it efficient and easy to parse. 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 3 parameters with low schema coverage (33%), no annotations, and no output schema, the description is insufficient. It doesn't explain return values, error handling, or important behavioral aspects like what 'metadata' includes or how posts are ordered. For a tool with this complexity and lack of structured data, more descriptive 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 33% (only start_post_number has a description). The description mentions 'first N posts' which hints at post_limit, but doesn't explain topic_id or provide additional context beyond the schema. Since schema coverage is low (<50%), the description should compensate more but only adds marginal value, warranting a baseline 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 clearly states the verb 'Read' and the resource 'topic metadata and first N posts', making the purpose unambiguous. It distinguishes from siblings like discourse_read_post (which reads individual posts) and discourse_filter_topics (which filters topics rather than reading a specific one). However, it doesn't explicitly contrast with all siblings, keeping it at 4 rather than 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. It doesn't mention when to choose this over discourse_read_post for reading posts within a topic, or when to use discourse_filter_topics for topic discovery. There's no context about prerequisites, permissions, or typical use cases.
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 visibility based on auth context. It doesn't disclose behavioral traits like pagination, rate limits, sorting, or what 'visible' entails (e.g., public vs. private categories), 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 with no wasted words. It's front-loaded with the core purpose and includes essential context about auth visibility, making it appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no annotations or output schema, the description is minimally adequate. It covers the basic purpose and auth scope but lacks details on behavior (e.g., output format, limitations), leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description adds value by clarifying the auth context scope, which isn't in the schema, earning a baseline 4 for zero-param tools.
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 ('List') and resource ('categories'), specifying they are 'visible to the current auth context'. It distinguishes from siblings like 'discourse_list_tags' or 'discourse_list_drafts' by focusing on categories, but doesn't explicitly differentiate beyond that.
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, exclusions, or compare with other listing tools (e.g., 'discourse_list_tags'), leaving 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 full burden for behavioral disclosure. It mentions that the tool returns 'channel information including title, description, and member counts', which provides some output context. However, it doesn't address important behavioral aspects like pagination behavior (implied by offset/limit parameters but not explained), rate limits, authentication requirements, or whether this is a read-only operation. For a listing tool with zero annotation coverage, this leaves significant 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 perfectly concise with two sentences that each earn their place. The first sentence states the purpose and scope, while the second describes the return format. There's zero wasted language, and the most important information (what the tool does) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with comprehensive parameter documentation (100% schema coverage) but no annotations and no output schema, the description provides adequate but incomplete context. It covers the basic purpose and return format, but lacks behavioral details that would be important for an AI agent. The absence of output schema means the description should ideally provide more detail about the return structure, but it only mentions three fields without specifying format or 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 the schema already fully documents all 4 parameters. The description adds no parameter-specific information beyond what's in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description. The description doesn't compensate with additional parameter context, but doesn't need to given the comprehensive schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'all public chat channels visible to the current user', making the purpose immediately understandable. It distinguishes from siblings like 'discourse_list_user_chat_channels' by specifying 'public' channels rather than user-specific ones. However, it doesn't explicitly contrast with other listing tools like 'discourse_list_categories' or 'discourse_list_tags'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving public chat channels, but provides no explicit guidance on when to use this versus alternatives like 'discourse_list_user_chat_channels' or 'discourse_search'. It mentions 'visible to the current user' which provides some context about access permissions, but lacks clear when/when-not scenarios or named alternatives.
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 'validate and select,' which hints at setup and verification, but doesn't explain what validation entails (e.g., checking site accessibility, permissions), whether it stores state for subsequent calls, or any error handling. For a tool with no annotations, 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: 'Validate and select a Discourse site for subsequent tool calls.' It is front-loaded with the core purpose and wastes no words, 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.
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 (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and usage context but lacks details on behavioral aspects like validation specifics or state management. Without annotations or output schema, it should do more to compensate, but it meets the minimum for a simple setup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'site' parameter documented as 'Base URL of the Discourse site.' The description doesn't add any meaning beyond this, such as format examples or validation rules. With high schema coverage, the 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.
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: 'Validate and select a Discourse site for subsequent tool calls.' It specifies the action (validate and select) and the resource (Discourse site), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools, which are all for interacting with Discourse sites but serve different functions like listing or reading content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: 'for subsequent tool calls,' implying it should be called first to set up the site for other operations. It doesn't specify when not to use it or name alternatives, but the context is sufficient for basic guidance without being explicit about exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions authentication requirement and unread tracking information, which are useful behavioral traits. However, it doesn't cover other important aspects like pagination, rate limits, error conditions, or response format, leaving gaps for a tool that likely returns a list of channels.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose, scope, and key feature (unread tracking). Every element earns its place with no redundant information, making it appropriately front-loaded and concise.
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 (listing user-specific channels with tracking), no annotations, and no output schema, the description is somewhat complete but has gaps. It covers authentication context and what's included, but doesn't describe the response structure, potential limitations, or how unread tracking is presented, which would help the agent 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 with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and it adds value by explaining what the tool returns (channels with unread tracking) beyond what the empty schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing all chat channels for the authenticated user, specifying both public channels they're a member of and direct message channels. It distinguishes from siblings like 'discourse_list_chat_channels' by focusing on user-specific channels rather than all channels, though it doesn't explicitly name this distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'currently authenticated user' and including unread tracking, suggesting it's for personal chat management. However, it lacks explicit guidance on when to use this tool versus alternatives like 'discourse_list_chat_channels' or 'discourse_get_chat_messages', leaving the agent to infer based on scope.
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 return content ('draft keys, sequences, and preview content') and implies read-only behavior through 'List', but lacks details on permissions, rate limits, or pagination beyond the schema's offset parameter. This is adequate but has gaps for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that are front-loaded with the core purpose and efficiently add usage guidance. Every word contributes value, with no wasted text or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description covers the purpose and usage well. However, it lacks details on behavioral aspects like authentication needs or error handling, which would be beneficial for a tool with no annotations, making it minimally complete but not thorough.
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 (offset). The description adds no parameter-specific information beyond what's in the schema, resulting in the baseline score of 3 for adequate coverage without extra 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 ('List all drafts') and resource ('for the current user'), distinguishing it from siblings like discourse_get_draft (singular) or discourse_list_user_posts (different resource). However, it doesn't explicitly differentiate from all list-type siblings (e.g., discourse_list_categories), making it a 4 rather than 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage ('Use this to find existing drafts before updating them'), which implicitly suggests when to use it. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings, so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions 'flexible pagination' and the four query modes, which gives some behavioral context. However, it lacks details on permissions, rate limits, error conditions, or response format (especially important since there's no output schema), leaving gaps for a mutation-free read 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 front-loaded with the core purpose, followed by a bullet-like list of four specific capabilities. Every sentence directly contributes to understanding the tool's functionality, with zero redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with 7 parameters and no annotations or output schema, the description is adequate but incomplete. It covers the query modes well but omits details on permissions, rate limits, error handling, and return format. Given the complexity and lack of structured data, it should provide more behavioral context to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 7 parameters. The description adds value by summarizing the four query modes, which helps contextualize parameters like target_message_id, direction, and fetch_from_last_read. However, it doesn't provide additional syntax or format details beyond the schema, meeting the baseline for high 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 verb ('Get') and resource ('messages from a chat channel'), and specifies the key capabilities: pagination and date-based filtering. It distinguishes itself from siblings like discourse_list_chat_channels (which lists channels) and discourse_search (which searches content) by focusing specifically on retrieving messages within a channel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists four usage scenarios (pagination, date-based query, message-based query, last-read fetch), providing clear context for when to use this tool. However, it does not mention when NOT to use it or explicitly name alternatives (e.g., discourse_search for broader content search), which prevents a perfect score.
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 discloses the tool's behavior as a retrieval operation, but lacks details on permissions, error handling, rate limits, or what happens if the draft key is invalid. The mention of 'sequence' as optional in the schema is not explained in the description, leaving gaps in 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 front-loaded with the core purpose in the first sentence, followed by helpful examples in the second sentence. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
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 (simple retrieval), no annotations, and no output schema, the description is adequate but incomplete. It covers the purpose and basic usage but lacks details on behavioral aspects like return format, error cases, or prerequisites, which are important for a tool without structured annotations or output 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 both parameters (draft_key and sequence). The description adds minimal value by providing examples of common keys ('new_topic', 'topic_<id>'), but does not explain parameter interactions or semantics beyond what the schema already covers, aligning with 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 verb ('Retrieve') and resource ('a specific draft'), and distinguishes it from siblings by specifying retrieval by key rather than listing all drafts (like discourse_list_drafts). The examples of common keys ('new_topic', 'topic_<id>') further clarify the scope and differentiate it from other retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to retrieve a specific draft by key) and implies an alternative (discourse_list_drafts for listing drafts). However, it does not explicitly state when not to use it or compare it to all sibling tools, such as discourse_get_user or discourse_read_post, which might handle different resources.
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 ordering ('most recent first'), pagination details (30 posts per page, page parameter usage), and that it returns a list. It doesn't cover aspects like rate limits, authentication needs, or error handling, but for a read-only list tool, this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by essential behavioral details (ordering, pagination). Every sentence adds value: the first states what the tool does, the second specifies default behavior and pagination mechanics. There's no wasted text, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (list operation with pagination), no annotations, and no output schema, the description is fairly complete. It covers purpose, ordering, pagination, and parameter usage. It doesn't describe the return format (e.g., structure of posts) or error cases, but for a list tool, this is a minor gap.
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% description coverage, so the description must compensate. It explains the 'page' parameter's semantics in detail (pagination logic with offsets), which adds significant value beyond the schema's type constraints. It doesn't explicitly describe the 'username' parameter, but its purpose is implied by the tool name and context. This partial coverage is adequate given the low 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 clearly states the tool's purpose: 'Get a list of user posts and replies from a Discourse instance, with the most recent first.' It specifies the verb ('Get'), resource ('user posts and replies'), and scope ('from a Discourse instance'). However, it doesn't explicitly differentiate from sibling tools like discourse_get_user or discourse_read_post, which might also retrieve user-related content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning pagination ('Use the page parameter to paginate'), suggesting this tool is for retrieving multiple posts. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like discourse_search or discourse_read_topic, nor does it mention any prerequisites or 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 full burden for behavioral disclosure. It effectively describes key behavioral traits: the query language syntax, permission-aware results (important for access control), and pagination behavior (implied through page/per_page parameters). It doesn't mention rate limits, error conditions, or authentication requirements, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is densely packed with query syntax details but remains a single paragraph. While information-dense, it could benefit from better structure (e.g., bullet points for different filter types). Every sentence earns its place by explaining the query language, but the presentation could be more scannable for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a filtering tool with 3 parameters (one complex), no annotations, and no output schema, the description provides substantial context about the query language and permission-aware results. It adequately covers the tool's purpose and usage, though it could benefit from explicit examples of complete queries and more detail about result format since there's no output 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%, providing good documentation for all three parameters. The description adds value by explaining the complex 'filter' parameter syntax in detail (key:value tokens, operators, date formats, etc.), but doesn't add meaningful context for 'page' and 'per_page' beyond what the schema already states. Baseline 3 is appropriate given the 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 explicitly states 'Filter topics with a concise query language', providing a specific verb ('filter') and resource ('topics'). It clearly distinguishes this tool from siblings like 'discourse_search' by focusing on structured filtering rather than general search, and from 'discourse_list_categories/tags' by targeting topics specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the detailed query language explanation, suggesting this tool is for structured filtering of topics. However, it doesn't explicitly state when to use this versus alternatives like 'discourse_search' or 'discourse_list_categories', nor does it provide exclusion criteria or prerequisites for use.
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:

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

Score Badge

Copy to your README.md:

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

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