This server acts as an MCP gateway to a Rocket.Chat workspace, enabling AI clients to interact with Rocket.Chat for messaging, file management, and workspace administration.
Messaging
Send messages to channels or as direct messages to users
Delete your own messages (or any with force-delete permission)
Read message history from channels, groups, or DMs (with pagination support)
Search messages by keyword within a specific room
List rooms with unread messages and their latest content
File Management
Upload files (images, documents, etc.) to channels or user DMs, with optional accompanying text
Download attachments from messages to local files
Workspace & User Management
List all rooms (channels, groups, DMs)
Create new channels
List all workspace users (requires admin/view-* permission)
Get detailed profile information for a specific user by username
Provides tools to interact with a Rocket.Chat workspace, including sending and reading messages, direct messages, file uploads/downloads, channel management, and user search.
An MCP server for Rocket.Chat. It lets MCP clients (Claude Desktop, Cursor, Claude Code, etc.) send and read messages, send DMs, search history, upload/download files, and manage channels on a Rocket.Chat workspace over stdio.
Actively maintained fork of elieworkspace/rocketchat-mcp, adding Personal Access Token auth, more tools, and reliability/security improvements. See NOTICE for attribution.
Tool | Description |
| Send a message to a channel |
| Send a direct message to a user |
| Delete a message (your own, unless the role has force-delete) |
| Read history of a channel/group/DM; supports |
| Keyword search within a room ( |
| List rooms with unread messages and their latest content |
| Upload a file to a channel or |
| Download a message's attachments to local files |
| List channels, groups and DMs ∗ |
| List users ∗ |
| Get a user's profile |
| Create a channel |
∗ list_all_rooms and list_users call workspace-wide endpoints
(channels.list / users.list) that require admin or the corresponding
view-* permission. Every other tool works for a normal chat user.
Related MCP server: Rocket.Chat MCP Server
A normal chat user is enough for the core tools. A Personal Access Token is recommended — it keeps the token out of process arguments:
Variable | Description |
| Workspace URL, e.g. |
| Your Rocket.Chat user ID |
| Personal Access Token |
| (optional) orphan-watchdog interval in seconds, default |
Username/password is also supported via --username / --password.
Use --no-verify-ssl for self-signed certificates.
uvx rocketchat-mcp --server-url https://chat.example.comTo run the latest unreleased code straight from GitHub instead:
uvx --from git+https://github.com/millerchou/rocketchat-mcp rocketchat-mcp --server-url https://chat.example.com{
"mcpServers": {
"rocketchat": {
"command": "uvx",
"args": ["rocketchat-mcp"],
"env": {
"ROCKETCHAT_SERVER_URL": "https://chat.example.com",
"ROCKETCHAT_USER_ID": "your_user_id",
"ROCKETCHAT_AUTH_TOKEN": "your_personal_access_token"
}
}
}
}git clone https://github.com/millerchou/rocketchat-mcp
cd rocketchat-mcp
uv run rocketchat.py --server-url https://chat.example.com \
--auth-token "$ROCKETCHAT_AUTH_TOKEN" --user-id "$ROCKETCHAT_USER_ID"Persistent HTTP connection pool, room-endpoint caching, log rotation (1 MB), and an orphan watchdog that self-exits when the MCP client process dies.
Modifications in this fork are released under the MIT License. This is a fork of upstream code originally published without a license; see NOTICE for details.
Create a new channel.
Args:
name: Name of the channel to create
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only says 'Create a new channel' without disclosing side effects, permissions, rate limits, or output behavior. For a write operation, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two lines), which is concise but omits critical details. While brevity is good, it sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering the output schema exists and there's only one parameter, the description still lacks essential context about the tool's behavior, return value, and usage nuances. It does not fully inform an AI agent for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds 'name: Name of the channel to create', which only reiterates the parameter name from the schema. With 0% schema description coverage, it fails to provide additional context like naming constraints or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a new channel', matching the tool name and indicating the action. However, it lacks specifics about the type of channel (public/private) or any distinguishing features from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like sending a message. Missing context about prerequisites 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.
Delete a message.
Args:
room_id: ID of the room containing the message
msg_id: ID of the message to delete
| Name | Required | Description | Default |
|---|---|---|---|
| room_id | Yes | ||
| msg_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It states 'Delete a message' but does not disclose if deletion is permanent, if there are any side effects, or if recovery is possible. Lacks important 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear one-line summary followed by parameter definitions. It is front-loaded and efficient, though it could benefit from a brief behavioral note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with two required parameters and an output schema (assumed to be handled), the description minimally covers the essentials. Lacks details on return values or error conditions, but the tool is straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the purpose of each parameter (room_id and msg_id) in the docstring, which adds meaning beyond the schema (which has 0% description coverage). However, it does not provide format or validation details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a message' with a specific verb and resource. It lists the required parameters (room_id, msg_id) and distinguishes from sibling tools like send_message_in_channel which are about sending, not deleting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 prerequisites (e.g., message ownership, permissions) or scenarios where deletion is not appropriate. Sibling tools are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download attachments from a message. Returns local file paths that can be viewed with the Read tool.
Args:
message_id: The message ID (shown as 'id: xxx' in message listings)
| Name | Required | Description | Default |
|---|---|---|---|
| message_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that it returns local file paths viewable with a Read tool, which adds behavioral context. However, it does not mention permissions, attachment limits, or whether all attachments are downloaded, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus a simple Args section. Purpose is front-loaded. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Though an output schema exists (not shown), the description mentions return paths. It lacks context on temporary storage, limits, or error handling. For a single-parameter tool, it is moderately complete but could be more robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameter. It provides helpful context: message ID is shown as 'id: xxx' in listings. This adds meaning beyond the schema's bare type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads attachments from a message, using a specific verb and resource. However, it does not distinguish from sibling tools like send_file, which also deals with files, so it's not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., send_file, search_messages). It implies usage by providing message_id context, but no explicit when-not-to-use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get messages from a channel, group or DM (newest first).
Args:
room_id: Room ID or room name of the channel/group/DM
count: Number of messages to retrieve (default: 20, max: 100)
offset: Skip this many newest messages — use to page back through history
instead of re-reading with a larger count (e.g. offset=20 to get
the 20 messages older than the first page)
| Name | Required | Description | Default |
|---|---|---|---|
| room_id | Yes | ||
| count | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description adds behavioral details: 'newest first' ordering, offset for paging, default and max count. Could mention authentication or error handling, but covers key behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with Args section and examples. Slightly verbose in offset explanation, but every sentence adds value. Acceptable length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description explains input completely: required room_id, optional count/offset with defaults. Paging mechanics are covered. No missing context for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description adds essential meaning: room_id accepts 'room name', count has default/max, offset described with paging example. Greatly enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get messages from a channel, group or DM (newest first)'. It specifies the verb, resource, and ordering, distinguishing it from siblings like search_messages or send_message_in_channel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains paging with count and offset, including an example. It doesn't explicitly state when not to use (e.g., for searching), but the context and sibling list imply it. Clear for basic use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all rooms with unread messages and their latest unread content.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It indicates a read operation (get), but does not disclose any traits like data limits, performance implications, or whether 'latest unread content' is truncated. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no extraneous content. Efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic functionality but lacks details on output structure, pagination, or filtering scope. With an output schema present, return values need not be explained, yet the description could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description adds no parameter information, which is acceptable since none exist. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all rooms with unread messages and their latest unread content. It distinguishes from siblings like get_channel_messages (specific channel) and search_messages (search all messages).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for unread summaries but provides no explicit guidance on when to use this tool versus alternatives like get_channel_messages or search_messages. No exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a specific user.
Args:
username: Username to get information about
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as permission requirements, error handling, rate limits, or what happens if the username does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence to state the purpose and a brief argument description. No wasted words, and the main point is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values need not be described. However, the description lacks details on error cases (e.g., invalid username) and common behaviors like caching or pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the input schema: 'Username to get information about' clarifies the parameter's purpose. However, with 0% schema coverage, more detail would improve understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'information about a specific user', which distinguishes it from sibling tools like 'list_users' and 'search_messages'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'list_users' or 'search_messages'. There is no context about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all rooms (channels, groups and DMs) available to the user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it lists rooms available to the user; it does not disclose pagination, whether archived rooms are included, or any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently conveys the tool's purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately conveys the basic purpose, but lacks details about pagination or archived room inclusion, making it minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%, so the description adds no parameter information, but none is needed; baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'rooms', and specifies the types (channels, groups and DMs), effectively distinguishing from sibling tools like create_channel or send_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 versus alternatives; it is implied as the only listing tool for rooms, but there is no context about when not to use it or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all users available to the user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'available to the user,' which is vague. Does not explain what 'available' means, authentication needs, rate limits, or output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence. It is appropriately sized for a zero-parameter list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and has an output schema, the description lacks details on return fields, pagination, or filtering. It is minimally complete but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%, so baseline is 4. The description adds nothing about parameters, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'users', and it is distinct from sibling tools which focus on channels, messages, and files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or alternatives, but the simplicity of the tool makes it self-explanatory. No explicit exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search messages in a room by keyword. Much cheaper than paging through history with get_channel_messages when looking for a specific message.
Args:
room_id: Room ID or room name of the channel/group/DM to search in
query: Search keyword(s)
count: Max results to return (default: 20, max: 100)
| Name | Required | Description | Default |
|---|---|---|---|
| room_id | Yes | ||
| query | Yes | ||
| count | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions it is cheaper and provides count limits, but lacks details on sorting, case sensitivity, or returned fields. Since annotations are absent, a more thorough disclosure is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two introductory sentences and a clear args list. Every sentence is valuable, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all input parameters and provides usage context. The existence of an output schema likely covers return values, so the input is well-documented. Could mention prerequisites like room existence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Each parameter is described with additional meaning beyond the schema: room_id can be ID or name, query is keyword(s), count has default and max. This fully covers all three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches messages by keyword, and it distinguishes itself from the sibling tool get_channel_messages by noting it is much cheaper for specific searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with get_channel_messages, providing context on when to use this tool. However, it does not mention other siblings or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a direct message to a user.
Args:
username: Username of the recipient
text: Message text to send
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | ||
| text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only states the action but does not mention error handling (e.g., non-existent user), rate limits, or whether it returns a message ID. The output schema is not referenced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a single-line purpose followed by a clean Args listing. Every sentence is necessary and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool like sending a DM, the description covers the basic action and parameters but omits any mention of return values or side effects, even though an output schema exists. It does not reference the schema or provide context for how it fits with siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It provides brief explanations ('Username of the recipient', 'Message text to send') which are slightly more informative than the schema titles but still minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send a direct message to a user', which is a specific verb and resource. It distinguishes from sibling tool 'send_message_in_channel' by specifying the recipient is a user (not a channel).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'send_message_in_channel' or 'send_file'. The description gives no context about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a file (image, document, etc.) to a channel or user.
Args:
channel: Channel name, channel ID, or @username for DM
file_path: Absolute path to the file to upload
message: Optional text message to send with the file
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | ||
| file_path | Yes | ||
| message | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should fully disclose behavior. It only explains parameter meanings and omits details like file size limits, error handling, required permissions, or what happens on failure. The return value is not described despite an output schema existing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and well-organized, with a clear paragraph followed by an Args list. Every sentence provides useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters and an output schema, the description adequately covers basic usage but lacks details on return values, error conditions, and prerequisites. It is minimally complete for functional use but not robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning by clarifying channel formats (name, ID, @username), file_path as absolute path, and message as optional. However, it does not specify whether file_path refers to a local or remote resource.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends files (image, document, etc.) to a channel or user, using specific verbs and resources. It distinguishes from sibling text-sending tools like send_message_in_channel and send_direct_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to specify the channel and file path, and mentions optional message. However, it does not explicitly contrast with alternative tools for sending files vs. text, though the context is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a message to a RocketChat channel.
Args:
channel: Channel name (e.g., 'general') or channel ID
text: Message text to send
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | ||
| text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose behavioral traits such as permission requirements, idempotency, rate limits, or any side effects beyond the basic action of sending a message.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and front-loaded with the purpose. The Args section is somewhat redundant with the schema but adds minimal value. No unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with 2 parameters and an output schema exists, but the description does not mention return values or any constraints. Lacks behavioral context to fully inform agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description adds some meaning: for 'channel', it clarifies it accepts a name (e.g., 'general') or ID; for 'text', it simply restates 'Message text to send'. Partial improvement over schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action: 'Send a message to a RocketChat channel.' It uses a specific verb (send) and identifies the resource (RocketChat channel), and it distinguishes from the sibling tool 'send_direct_message'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like send_direct_message or search_messages. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0create_channeldelete_messagedownload_attachmentget_channel_messagesget_unreadget_user_infolist_all_roomslist_userssearch_messagessend_direct_messagesend_filesend_message_in_channelScored across 12 tools
Each tool targets a distinct operation: creating channels, sending messages to channels or DMs, sending files, retrieving and searching messages, user info, listing rooms and users, and deleting messages. There is no overlapping functionality; even the two send message tools are clearly differentiated by target (channel vs DM).
Most tools follow a consistent verb_noun pattern (e.g., create_channel, delete_message, send_direct_message). The exception is 'get_unread', which is less descriptive and deviates from the pattern (could be 'get_unread_rooms'). Otherwise, naming is predictable and clear.
With 12 tools, the set is well-scoped for a chat server. It covers essential operations without being overwhelming. The count falls within the ideal range and each tool serves a clear purpose.
The tool surface covers core CRUD operations for messages and channels, plus user info and file sharing. Minor gaps exist: no tool for editing or deleting channels, no message editing, and no channel metadata retrieval. These are not critical but would enhance completeness.
MCP server for Sendbird — chat users, channels, members, and messages from your AI client.
Real-time chat for AI agents. Claude Code, Cursor, Cline and Codex join channels over MCP.
The official Planning Center MCP server for interacting with your ministry's data.
Remote MCP server to read and manage your Atako AI agents, messages, files, and integrations.
