What can you do with this server?

The flarum-mcp server provides an MCP interface to interact with Flarum forums, enabling both read and write operations on forum content. Read tools (no authentication required): * list_tags – List all forum tags/categories, including their numeric IDs, slugs, descriptions, and discussion counts. * search_discussions – Full-text search across forum discussions, returning titles, IDs, authors, and tags (up to 50 results). * recent_discussions – Fetch the most recently active discussions (up to 50 results). * discussions_by_tag – List discussions under a specific tag slug (e.g., malware-analysis), up to 50 results. * get_discussion – Fetch a full discussion by ID, including its posts rendered as plain text (up to 50 posts). Write tools (require authentication via API token or username/password): * create_discussion – Start a new discussion with a title, Markdown body, and at least one tag ID. * reply_to_discussion – Post a Markdown reply to an existing discussion by its ID. * upload files – Upload images or other files to embed in posts when creating or replying to discussions (requires the fof/upload Flarum extension).

How do I use flarum-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@flarum-mcp show recent discussions" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

flarum-mcp

by ReverserID

Overview Schema Related Servers Score Discussions

JavaScript

Remote

flarum-mcp

An MCP server for Flarum forums. It lets any MCP client (Claude Code, Claude Desktop, …) search, read, and post discussions through Flarum's REST/JSON:API. Read tools need no auth; write tools use a personal access token. Ships preconfigured for reverser.id.

Tools

Tool	Auth	What it does
`list_tags`	–	List categories/labels with id, slug, description, count
`search_discussions`	–	Full-text search discussions
`recent_discussions`	–	Most recently active discussions
`discussions_by_tag`	–	Discussions under a tag slug (e.g. `malware-analysis`)
`get_discussion`	–	Read a discussion + its posts as plain text
`create_discussion`	token	Start a new discussion (needs ≥1 tag id); optional `attachments`
`reply_to_discussion`	token	Reply to an existing discussion; optional `attachments`
`upload_file`	token	Upload an image/file (local path or URL) → embed snippet
`get_post`	–	Read a single post + permalink
`whoami`	token	Show which user the credentials authenticate as
`search_users`	token	Find users by username/name
`like_post`	token	Like / unlike a post
`subscribe_discussion`	token	Follow / ignore a discussion
`edit_post`	token	Replace a post's content
`rename_discussion`	token	Change a discussion's title
`set_tags`	token	Replace a discussion's tags
`sticky_discussion`	token	Pin / unpin a discussion
`lock_discussion`	token	Lock / unlock a discussion
`delete_discussion`	token	Delete a discussion (irreversible)
`delete_post`	token	Delete a post (irreversible)

create_discussion and reply_to_discussion accept an optional attachments array of local file paths or http(s) URLs — each is uploaded and embedded in the post (images render inline, other files as download links). Uploading requires the fof/upload extension enabled on the forum.

Related MCP server: discord-mcp

Configuration

Env var	Required	Default
`FLARUM_BASE_URL`	no	`https://reverser.id`
`FLARUM_USERNAME` (or `FLARUM_EMAIL`)	write tools	–
`FLARUM_PASSWORD`	write tools	–
`FLARUM_API_TOKEN`	optional alternative to the above	–

Auth is only needed for the write tools (create_discussion, reply_to_discussion); read tools work anonymously.

The recommended way is to just give it a username/email + password — the server logs in for you via POST /api/token and caches the token for the life of the process, so you never mint one by hand:

"env": {
  "FLARUM_BASE_URL": "https://reverser.id",
  "FLARUM_USERNAME": "your-username",
  "FLARUM_PASSWORD": "your-password"
}

Prefer not to store a password? Supply a ready-made token instead (takes precedence if set):

curl -s https://reverser.id/api/token -H 'Content-Type: application/json' \
  -d '{"identification":"USERNAME_OR_EMAIL","password":"PASSWORD"}'
# -> {"token":"xxxxxxxxxxxx...","userId":1}
# then set FLARUM_API_TOKEN to that value

Legacy REVERSER_* names (REVERSER_BASE_URL, REVERSER_USERNAME, REVERSER_PASSWORD, REVERSER_API_TOKEN) are still read as fallbacks.

Use with Claude Code

Once published, no install needed — run it with npx:

claude mcp add flarum-mcp \
  --env FLARUM_BASE_URL=https://reverser.id \
  --env FLARUM_USERNAME=your-username \
  --env FLARUM_PASSWORD=your-password \
  -- npx -y flarum-mcp

Or a project-local .mcp.json:

{
  "mcpServers": {
    "flarum-mcp": {
      "command": "npx",
      "args": ["-y", "flarum-mcp"],
      "env": {
        "FLARUM_BASE_URL": "https://reverser.id",
        "FLARUM_USERNAME": "your-username",
        "FLARUM_PASSWORD": "your-password"
      }
    }
  }
}

Use with Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "flarum-mcp": {
      "command": "npx",
      "args": ["-y", "flarum-mcp"],
      "env": {
        "FLARUM_BASE_URL": "https://reverser.id",
        "FLARUM_USERNAME": "your-username",
        "FLARUM_PASSWORD": "your-password"
      }
    }
  }
}

Local development

git clone https://github.com/ReverserID/flarum-mcp.git
cd flarum-mcp
npm install          # runs the build via the "prepare" script
npm start            # node build/index.js

Quick manual test — handshake + list_tags over stdio, no client needed:

printf '%s\n' \
 '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"t","version":"0"}}}' \
 '{"jsonrpc":"2.0","method":"notifications/initialized"}' \
 '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"list_tags","arguments":{}}}' \
 | node build/index.js

Layout

flarum-mcp/
├── src/
│   ├── index.ts     # MCP server + tool definitions
│   └── flarum.ts     # tiny Flarum JSON:API client + helpers
├── package.json
├── tsconfig.json
├── .env.example
└── LICENSE

Notes

stdio transport uses stdout for the protocol — the server only ever logs to stderr. Keep it that way if you extend it.
Extend with more tools (likes, flags, user lookup, notifications) by following the same server.registerTool(...) pattern.

License

MIT © ReverserID

Available Tools

7 tools

create_discussionCreate a discussionA

Start a new discussion (requires REVERSER_API_TOKEN). Flarum needs at least one primary tag — pass tag ids from list_tags. Content is Markdown.

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Discussion title
`tagIds`	Yes	Tag ids — at least one primary category (see list_tags)
`content`	Yes	Body, in Markdown

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided, so description must cover behavior. It mentions authentication and Markdown format, but lacks details on return values, error handling, or side effects beyond creation.

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?

Three concise sentences with no redundancy. Could be slightly more structured but is efficient and front-loaded with the main action.

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

Completeness4/5

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

For a simple creation tool with 3 parameters and no output schema, the description covers prerequisites and key constraints. Missing some behavioral context but adequate given low complexity.

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

Parameters3/5

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

Schema coverage is 100%, so description adds minimal extra value (e.g., Markdown hint). The baseline is 3, and the description does not significantly enhance understanding beyond 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 'Start a new discussion' clearly states the verb 'create' and the resource 'discussion', distinguishing it from sibling tools like get_discussion, reply_to_discussion, and search_discussions that perform different actions.

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

Usage Guidelines4/5

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

Specifies a prerequisite (REVERSER_API_TOKEN) and provides guidance on how to get tag ids (list_tags). However, it does not explicitly state when to use alternatives or exclude cases.

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

discussions_by_tagDiscussions in a tagA

List discussions filed under a given tag (category), by tag slug — e.g. 'malware-analysis'.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Tag slug (see list_tags)
`limit`	No	Max results (1–50)

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It states the function but lacks details on pagination, ordering, or behavior when slug is invalid. It is not misleading but could be more informative.

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 efficiently conveys the purpose and provides an example. No unnecessary words.

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 simple tool with 2 parameters and no output schema, the description is adequate but does not mention return format or other context that could be helpful.

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

Parameters3/5

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

Schema coverage is 100% with descriptions for both parameters. The description adds an example slug and a cross-reference to list_tags, providing marginal extra value beyond the schema.

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

Purpose5/5

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

The description clearly states it lists discussions by a tag slug, with an example. It distinguishes from siblings like search_discussions or recent_discussions by specifying the filtering mechanism.

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

Usage Guidelines3/5

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

The description implies usage when you have a tag slug, but it does not explicitly state when to use this tool versus alternatives like search_discussions. No exclusion criteria are mentioned.

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

get_discussionRead a discussionA

Fetch a discussion by id, including its posts rendered as plain text.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Discussion id
`postLimit`	No	Max posts to include

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description bears the full burden. It states the tool renders posts as plain text but does not explicitly declare it as read-only or disclose other behavioral traits (e.g., required permissions, rate limits). The name implies safety, but the description lacks explicit reassurance.

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 immediately conveys the tool's primary function. No redundant or irrelevant information; every word earns its place.

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

Completeness4/5

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

Given the tool's simplicity (2 parameters, no output schema), the description adequately covers what it does and includes the detail about posts being rendered as plain text. It could optionally mention the return structure, but the current description is sufficient for an agent to infer the result.

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

Parameters3/5

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

Schema coverage is 100%, with each parameter described in the schema. The description adds no new semantic information beyond the schema: it mentions fetching by id but does not elaborate on postLimit or id formatting. Baseline of 3 is appropriate.

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 ('Fetch'), the resource ('discussion by id'), and the specific output ('including its posts rendered as plain text'). It effectively distinguishes from sibling tools like create_discussion, search_discussions, etc.

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 use when you have a discussion id, but does not provide explicit guidance on when to use this tool versus alternatives like search_discussions or recent_discussions. Missing 'when-not-to-use' or alternative tool references.

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

list_tagsList forum tagsA

List every category/tag on the reverser.id forum with its numeric id, slug, and discussion count. Use the ids here when creating a discussion.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It clarifies the read-only nature and return fields, but doesn't mention authentication, pagination, or ordering. Adequate for a simple list, but lacks depth.

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 well-structured sentences. Front-loaded with purpose, no extraneous words.

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

Completeness5/5

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

No output schema, but description explains return fields. Connects to sibling tool create_discussion. Fully sufficient for a parameterless list tool.

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?

No parameters exist, schema coverage is 100% trivially. Description adds no parameter info, but none needed. Baseline 4 for 0 parameters.

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

Purpose5/5

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

The description clearly states it lists every tag on the forum with specific attributes (numeric id, slug, discussion count), distinguishing it from sibling tools like create_discussion or discussions_by_tag.

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

Usage Guidelines5/5

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

Explicitly tells the agent to use the IDs when creating a discussion, providing clear guidance on when and why to invoke this tool.

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

recent_discussionsRecent discussionsB

List the most recently active discussions on the forum.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max results (1–50)

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, and the description only says 'most recently active' without defining what constitutes 'active' (e.g., last reply, creation date, or activity score). It does not disclose whether the tool is read-only or safe, nor any potential side effects. The agent is left guessing the exact 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?

A single, concise sentence that imparts the core purpose with zero wasted words. It is appropriately front-loaded.

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

Completeness2/5

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

Given no output schema and no annotations, the description should compensate. It fails to describe what the output contains (e.g., titles, IDs, timestamps), whether results are paginated, or how 'recent' is ordered. For a simple tool, this is insufficient for an agent to fully understand the return value.

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 covers 100% of parameters (only 'limit') with a clear description. The tool description adds no further meaning beyond the schema, so baseline 3 applies.

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 'List the most recently active discussions on the forum,' which uses a specific verb ('List') and resource ('discussions'). It naturally distinguishes from sibling tools like 'search_discussions' or 'discussions_by_tag' which imply filtering, whereas this simply lists recent activity.

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 explicit guidance on when to use this tool over siblings. For example, it does not clarify that this is for browsing vs. searching, nor does it mention scenarios where 'search_discussions' or 'discussions_by_tag' would be more appropriate. The usage context is entirely implied.

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

reply_to_discussionReply to a discussionA

Post a reply to an existing discussion (requires REVERSER_API_TOKEN). Content is Markdown.

ParametersJSON Schema

Name	Required	Description	Default
`content`	Yes	Reply body, in Markdown
`discussionId`	Yes	Target discussion id

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses authentication (requires token) and content format (Markdown), but lacks details on rate limits, side effects, or error behavior. This is minimal but functional for a simple write 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 concise sentence that conveys all necessary information without redundancy. Every part earns its place.

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 tool has low complexity (2 params, no output schema) and the description covers action, auth, and format. Missing details like response type or discussion existence checks, but overall adequate for a write tool.

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

Parameters3/5

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

Schema coverage is 100% with both parameters having descriptions. The description only repeats that content is Markdown (already in schema) and adds no new semantic information. Given high coverage, baseline 3 is appropriate.

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 states 'Post a reply to an existing discussion,' which clearly specifies the verb (post), resource (reply), and context (existing discussion). It distinguishes from sibling tools like create_discussion (new discussion) and get_discussion (retrieval).

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 mentions the requirement of REVERSER_API_TOKEN and that content is Markdown, providing clear context. However, it does not explicitly state when to use this tool versus alternatives like create_discussion, though the name and context signals make it inferable.

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

search_discussionsSearch discussionsB

Full-text search discussions on the forum. Returns matching titles with id, author, and tags.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max results (1–50)
`query`	Yes	Search text

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided. The description says 'full-text search' but then 'Returns matching titles', which is ambiguous about whether it searches only titles or full content. No mention of read-only nature, order, pagination, or authentication requirements.

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

Conciseness4/5

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

Two concise sentences. Front-loaded with action and return info. Minimal 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?

Schema covers parameter details. No output schema. Description lacks clarity on search scope (titles vs full content) and does not mention pagination behavior. Adequate but with minor gaps.

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 covers both parameters with descriptions (query and limit). Description adds no additional semantics beyond the schema. Baseline 3 is appropriate.

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 it performs full-text search on discussions and specifies returned fields (title, id, author, tags). Distinguishes from siblings like discussions_by_tag which filters by tag, and recent_discussions which returns recent, not searchable.

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. It does not mention use cases or exclusions like 'use discussions_by_tag for tag-specific queries.' The agent must infer from sibling names.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool targets a distinct action or query (create, list-by-tag, get, list-tags, recent, reply, search) with no overlap in functionality.

Naming Consistency4/5

Most tools follow verb_noun pattern with snake_case, but 'discussions_by_tag' and 'recent_discussions' deviate slightly (preposition, adjective-first) from the dominant pattern.

Tool Count4/5

7 tools is a reasonable count for a forum MCP, covering essential operations without being too sparse or bloated.

Completeness4/5

Covers create, read (by ID, by tag, recent, search), and reply; missing update and delete capabilities, but core read/write workflows are present.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

MCP Registry Server A
ai.com.mcp
Publish and discover MCP servers via the official MCP Registry. Powered by HAPI MCP server.
Developer Tools Search
336,314
nü people Job Server A
io.github.nu-people
Public MCP server for discovering open jobs. Search, filter, and get application links.
Search
52
mcp AOAuth
com.mux
The official MCP Server for the Mux API
Multimedia Processing Entertainment & Media API Testing
22168
crowdin A
io.usefulapi
MCP server for Crowdin — projects, files, strings, translation progress, tasks, and members.
Language Translation Project Management
122

Related MCP Servers

Discord MCP Server
Communication Developer Tools Autonomous Agents
BennettSchwartz
A
license
A
quality
C
maintenance
An MCP server for interacting with Discord.
Updated 8 months ago (2026-01-12 13:24 UTC)
19
348
11
MIT
discord-mcp
Communication Social Media
taka392
A
license
A
quality
D
maintenance
MCP server for interacting with Discord via REST API, enabling guild, channel, and message operations using a bot token.
Updated 4 months ago (2026-05-13 12:24 UTC)
7
MIT
MCP for Flarum
Communication Content Management Systems
linkrobins
A
license
A
quality
A
maintenance
Provides MCP-compatible AI clients with full access to a Flarum forum's API, enabling reading, searching, creating discussions, replying, moderation, and management of users, tags, and groups.
Updated a month ago (2026-07-29 00:25 UTC)
15
2
MIT
nodebb-plugin-integration
RAG Systems Search Knowledge & Memory
Sergey-ek
A
license
Not graded
quality
B
maintenance
MCP server for NodeBB forums that enables AI assistants to access forum data, search topics, and perform semantic search via the Model Context Protocol.
Updated 2 months ago (2026-07-18 19:53 UTC)
26
MIT

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/ReverserID/flarum-mcp'

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