Loading ToolBench
A Python (stdlib-only) MCP stdio server giving an AI agent forum tools on a single Discourse site — a focused fork of @discourse/mcp
Discourse-mcp demonstrates solid fundamentals: all 22 tools have clear verb-noun naming (discourse_search, discourse_create_topic, etc.), descriptions present for all tools (avg ~80 chars), and complete input schemas with type definitions and parameter descriptions. Projections strip API verbosity well (e.g., _project_post, _project_topic). However, output schemas are not formally documented, LLMs must infer response structure from code. Error handling is basic (ValueError/RuntimeError) without recovery guidance. Parameter descriptions lack constraints (e.g., no enum for mailbox values despite 5 valid options, no min/max for pagination). Tool descriptions are functional but brief (10-80 chars), below the 50-200 char LLM-optimized baseline. No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification in the spec. Composition is clean, each tool has one responsibility, but some tools could be batched (e.g., like/unlike as toggle_post_reaction).
Bookmark a post or topic
Create a reply post in a topic
Create a new private message
Create a new topic in a category
Remove a bookmark
Get user profile information by username
Like a post
Output schemas not formally documented. LLMs must infer response structure from code (e.g., _project_post returns {id, topic_id, post_number, username, created_at, raw, truncated}). Undocumented outputs force agents to guess field names and types, increasing hallucination risk.
Parameter descriptions lack formal constraints. mailbox parameter accepts 5 specific values (inbox, sent, unread, new, archive) but description says 'Mailbox type: inbox, sent, unread, new, archive', should be an enum constraint. Similarly, level parameter in discourse_watch_topic_level lacks enum definition.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 73 | <=2025-11-25 | v2 |
List all forum categories
List the bot's own notifications
List private messages from a mailbox
Set topic notification level to muted
Toggle a custom emoji reaction on a post
Read a single post by ID
Read a private message topic by ID
Read a topic by ID, returning title, posts, and metadata
Reply to a private message
Search the forum by query, with optional pagination and result limit
Set topic notification level to tracking
Remove a like from a post
Edit an existing post
Set topic notification level to watching
Set topic notification level to a specific level
Tool descriptions are too brief (avg 65-75 chars, below 50-200 char LLM-optimized baseline). E.g., 'Like a post' and 'Remove a like from a post' lack context on when to use them vs alternatives. Descriptions should explain WHAT, WHEN, and WHY.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk stratification in spec. Tools are marked READ_ONLY, WRITE, or REVERSIBLE in comments but not exposed to MCP clients. Clients cannot determine which tools are safe to retry or require confirmation.
Error handling lacks recovery guidance. ValueError and RuntimeError are raised but responses do not suggest next steps (e.g., 'User not found. Try search_users() with a partial name.'). Agents receive bare errors with no actionable path forward.