dendrite-admin-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_HTTP_HOST | No | Host for HTTP transport (default 0.0.0.0) | 0.0.0.0 |
| MCP_HTTP_PORT | No | Port for HTTP transport (default 3939) | 3939 |
| MCP_TRANSPORT | No | Transport mode: stdio (default) or http | stdio |
| MCP_AUTH_TOKEN | No | Bearer token required for HTTP transport; generate with openssl rand -hex 32 | |
| DENDRITE_BASE_URL | Yes | Base URL of the homeserver's client-facing port, e.g. https://matrix.example.com | |
| DENDRITE_ADMIN_TOKEN | Yes | Access token of a Dendrite server admin user; sent as a Bearer token to all /_dendrite/admin and most /_synapse/admin endpoints | |
| DENDRITE_REGISTRATION_SHARED_SECRET | No | registration_shared_secret from dendrite.yaml; only needed for the register_user tool |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| evacuate_roomA | Part all local users from a room. Useful when a room is stuck and needs every local member removed at once. |
| purge_roomA | Remove a room and all its events from Dendrite's database. Does not delete associated media. Irreversible. |
| download_room_stateA | Fetch and return the room state for a given room as seen by a specific federated server. Useful for debugging state resolution and federation issues. |
| evacuate_userA | Part a local user from every room they are currently joined to. |
| reset_passwordA | Set a new password for a local user, optionally invalidating all of their existing access tokens. |
| refresh_devicesA | Immediately query a federated user's /devices endpoint, refreshing Dendrite's cached device/cross-signing keys. Useful for resolving encryption issues with remote users. |
| whoisA | Retrieve connection/session information Dendrite holds about a given user. |
| register_userA | Create a new local account using Dendrite's shared-secret registration flow (registration_shared_secret in dendrite.yaml). Requires DENDRITE_REGISTRATION_SHARED_SECRET to be configured; does not use the admin bearer token. |
| list_registration_tokensA | List registration tokens, optionally filtered by whether they are still valid. |
| get_registration_tokenB | Fetch details of a single registration token. |
| create_registration_tokenA | Create a new registration token that can be used to gate new-account registration. Omit 'token' to have Dendrite generate a random one. |
| update_registration_tokenB | Modify the usage limit, expiry time, or validity of an existing registration token. |
| delete_registration_tokenB | Permanently delete a registration token. |
| send_server_noticeA | Send a server notice (an m.text message from the server) to a specific local user. Requires server notices to be configured in dendrite.yaml. |
| fulltext_reindexA | Trigger a reindex of all searchable events (m.room.message, m.room.topic, m.room.name). Can be expensive on large homeservers. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 15 tools
Each tool targets a specific administrative action: registration tokens have clear CRUD separation (list/get/create/update/delete), while room operations (evacuate, purge, download state) and user operations (register, reset password, whois) are distinct. Even similar-sounding tools like evacuate_room and evacuate_user are clearly differentiated by their target resource.
Most tools follow a consistent verb_noun pattern (list_registration_tokens, create_registration_token, reset_password, etc.). Minor deviations include 'whois' (a single word) and 'fulltext_reindex' (which could be interpreted as reindex_fulltext), but these are still understandable and do not create confusion.
With 15 tools, the set is well-scoped for a Matrix homeserver admin tool. Each tool addresses a distinct administrative need (token management, user admin, room admin, server maintenance) and none feel redundant. The count is at the upper boundary but remains justified.
The tool set covers registration token CRUD, core user operations (create, reset password, whois), and room management (evacuate, purge, download state), but notable gaps exist: there is no user deletion/deactivation, no list users tool, and no general room listing/search. Agents cannot perform the full lifecycle for users or rooms.