matrix-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HOST | No | HTTP bind host | 127.0.0.1 |
| PORT | No | HTTP bind port | 3300 |
| MCP_TRANSPORT | No | Transport: http (default) or stdio | |
| MCP_BEARER_TOKEN | No | Shared secret MCP clients must present. Required in HTTP mode. | |
| TENANT_<NAME>_TOKEN | Yes | Matrix access token | |
| MATRIX_PRIMARY_TENANT | No | Tenant used when the tenant arg is omitted. Default: alphabetically first. | |
| TENANT_<NAME>_USER_ID | Yes | Full MXID the token belongs to, e.g. @alice:example.org | |
| TENANT_<NAME>_BASE_URL | Yes | Homeserver base URL, e.g. https://matrix.example.org | |
| MATRIX_MCP_MAX_UPLOAD_BYTES | No | Decoded size cap for matrix_send_file (default 10 MiB) |
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
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| matrix_list_joined_roomsA | List rooms the configured account has joined, with name, topic, and encryption flag. Cursor-paginated. Homeserver to target. Omit to use the primary tenant (''). Available: ['']. |
| matrix_get_room_infoD | Room name, topic, canonical alias, encryption status, member count. |
| matrix_list_room_membersB | List joined members of a room (user_id + display name), paginated. |
| matrix_get_recent_messagesA | Most recent messages in a room, newest first. Pass the returned next_cursor as before_cursor to page backward through history. End-to-end-encrypted rooms surface ciphertext (see README). |
| matrix_send_messageA | Send a plaintext message to a room. dry_run=true previews without sending. idempotency_key is forwarded as the Matrix transaction ID — pass a stable value on retry to avoid duplicate sends. |
| matrix_mark_readC | Mark a room as read up to (and including) the given event. |
| matrix_send_reactionB | Add an emoji reaction (👍 ❤️ ✅ etc.) to an existing message. Stacks alongside other reactions, doesn't replace. dry_run-able. |
| matrix_send_fileB | Send a file attachment to a room. file_b64 is the file contents base64-encoded. msgtype 'auto' infers from mime_type (m.image / m.video / m.audio / m.file). dry_run-able. |
| matrix_create_roomA | Create a new Matrix room. preset='private_chat' (default), 'trusted_private_chat', or 'public_chat'. Pass invite_user_ids as a list of full @user:server.tld ids. dry_run-able. |
| matrix_invite_userB | Invite a user to an existing room. user_id is a full Matrix ID like '@alice:example.org'. dry_run-able. |
| matrix_search_messagesB | Server-side full-text search across joined rooms (or one room if room_id is set). Encrypted rooms are not searchable server-side. |
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 11 tools
Each tool targets a distinct resource+action: listing rooms vs. getting one room's info, browsing recent messages vs. full-text search, and sending message/file/reaction are clearly separated. No two tools overlap in a way that would cause misselection.
Every tool follows the same matrix_verb_noun snake_case pattern (list_joined_rooms, get_room_info, send_message, create_room, etc.). Verbs are consistent and predictable across the set.
11 tools is well-scoped for a Matrix client covering rooms, messaging, and search. Each tool earns its place without redundancy or bloat.
Coverage is strong for read/send workflows: list rooms, room info, members, read/send messages, files, reactions, mark read, create room, invite, search. Notable gaps remain for lifecycle operations like join/leave room and redact/delete messages.