MCP Chatwork Server
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@MCP Chatwork Serversend a message to room 12345 saying the meeting starts in 10 minutes"
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.
MCP Chatwork Server
This is a Model Context Protocol (MCP) server for Chatwork. It allows AI agents to read context from Chatwork rooms and messages.
Features
List Rooms: Retrieve a list of rooms the user is participating in.
List Messages: Fetch messages from a specific room.
Send Message: Send a message to a specific room.
Get Room Members: Get the list of members in a room.
Create Task: Create a task in a room.
Get My Tasks: Get the list of tasks assigned to the current bot account.
Delete Message: Delete a message from a room.
Complete Task: Mark a task as done.
Leave Room: Leave a room.
Prerequisites
Node.js (v18 or higher)
A Chatwork API Token
Installation
Clone the repository:
git clone git@github.com:vfa-khuongdv/mcp-chatwork.git cd mcp-chatworkInstall dependencies:
npm installBuild the server:
npm run build
Configuration
The server requires the CHATWORK_API_TOKEN environment variable to be set.
Usage
With Claude Desktop (or other MCP Clients)
Add the following configuration to your MCP client settings (e.g., claude_desktop_config.json):
{
"mcpServers": {
"chatwork": {
"command": "node",
"args": ["/path/to/mcp-chatwork/dist/index.js"],
"env": {
"CHATWORK_API_TOKEN": "your_chatwork_api_token"
}
}
}
}or
{
"mcpServers": {
"chatwork": {
"command": "npx",
"args": ["-y", "@duongkhuong/mcp-chatwork"],
"env": {
"CHATWORK_API_TOKEN": "your_chatwork_api_token"
}
}
}
}Manual Testing
You can run the server directly via stdio (though it is designed to communicate with an MCP client):
export CHATWORK_API_TOKEN="your_token"
npm startTools
list_rooms
Returns a list of rooms with details like room ID, name, unread count, etc.
list_messages
Returns messages for a given room.
Arguments:
room_id(number): The ID of the room.force(boolean): Iftrue, fetches the latest 100 messages regardless of read status.
send_message
Allows the agent to send messages to a room.
Arguments:
room_id(number): The ID of the room.body(string): The message content.
get_room_members
Get the list of members in a room.
Arguments:
room_id(number): The ID of the room.
create_task
Assign a task to a user in a Chatwork room.
Arguments:
room_id(number): The ID of the room.body(string): The task description.to_ids(array of numbers): List of user IDs to assign the task to.limit(string, optional): Due date in unix time or "YYYY-MM-DD" format.
get_my_tasks
List tasks assigned to the current bot account.
Arguments:
assigned_by_account_id(number, optional): Filter by user ID who assigned the task.status(string, optional): Task status ("open", "done"). Defaults to "open".
delete_message
Delete a message from a room.
Arguments:
room_id(number): The ID of the room.message_id(string): The ID of the message to delete.
complete_task
Mark a task as done.
Arguments:
room_id(number): The ID of the room.task_id(string): The ID of the task.
leave_room
Leave a room.
Arguments:
room_id(number): The ID of the room.
License
MIT
Available Tools
9 toolscomplete_taskC
Mark a task as done.
| Name | Required | Description | Default |
|---|---|---|---|
| room_id | Yes | The unique identifier of the Chatwork room. | |
| task_id | Yes | The unique identifier of the task. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states the action without mentioning reversibility, permissions, or side effects.
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 sentence is concise and front-loaded. No unnecessary words, though it could be slightly more descriptive without losing efficiency.
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 two-parameter tool with no output schema, the description is adequate. It covers the core action but lacks details on return values or side effects.
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 100%, so the schema already explains parameters. The description adds no additional meaning beyond the schema.
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 'Mark a task as done' clearly states the action on a specific resource. It distinguishes from siblings like create_task and delete_message, but does not explicitly differentiate.
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. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_taskB
Assign a task to a user in a Chatwork room.
| Name | Required | Description | Default |
|---|---|---|---|
| room_id | Yes | The unique identifier of the Chatwork room. | |
| body | Yes | Task description/body. | |
| to_ids | Yes | Array of account IDs to assign the task to. | |
| limit | No | Task due date (Unix timestamp). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the basic action without mentioning side effects (e.g., notifications), required permissions, idempotency, or return value. This lack of detail is insufficient for a mutation tool.
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, focused sentence that is front-loaded with the verb and resource. Every word is necessary, and there is no extraneous 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?
Given the tool's simplicity and the schema's full coverage, the description provides a high-level understanding. However, the lack of an output schema and missing details about success/error responses leaves some gaps for an agent.
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 input schema has 100% description coverage, documenting all four parameters. The tool description adds no additional meaning beyond what is in the schema. Baseline score of 3 is appropriate.
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's purpose: 'Assign a task to a user in a Chatwork room.' It uses a specific verb ('assign') and identifies the resource ('task') and context ('Chatwork room'). This distinguishes it from sibling tools like 'complete_task' or 'delete_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 provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusion criteria. While the purpose is clear, there is no explicit usage context, requiring the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_messageB
Delete a message from a room.
| Name | Required | Description | Default |
|---|---|---|---|
| room_id | Yes | The unique identifier of the Chatwork room. | |
| message_id | Yes | The unique identifier of the message to delete. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description fails to disclose that deletion is irreversible, requires specific permissions, or what happens if the message doesn't exist. Insufficient for a destructive operation.
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?
Single sentence is concise but lacks additional context. It does not provide value beyond the obvious, though it is not overly verbose.
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?
No output schema, so description should explain return behavior or confirmation. It omits what the tool returns after deletion, making it incomplete for an agent.
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?
Input schema covers 100% of parameters with descriptions. The description adds no extra meaning beyond stating the action; baseline score of 3 is appropriate.
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 explicitly states the action 'Delete' and the resource 'message from a room', making the purpose clear. It effectively distinguishes from siblings like send_message and list_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 on when to use this tool versus alternatives, such as leaving a room or completing a task. No prerequisites or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_my_tasksB
List tasks assigned to the current bot account.
| Name | Required | Description | Default |
|---|---|---|---|
| assigned_by_account_id | No | Filter by the account ID who assigned the task. | |
| status | No | Task status (open or done). | open |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only states 'list tasks' without disclosing potential behavioral traits such as read-only nature, pagination, or rate limits. It relies on the verb 'list' to imply safety, but does not explicitly state mutability.
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 sentence that is concise and front-loaded, with no wasted 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?
For a simple list tool with two optional parameters and no output schema, the description covers the basic purpose but leaves out details about response format and possible limitations.
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 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides for the two 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 verb (list) and resource (tasks assigned to the current bot account), distinguishing it from sibling tools like create_task and complete_task.
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 others. The description implies it's for listing tasks assigned to the bot, but does not mention alternatives or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_room_membersB
Get the list of members in a room.
| Name | Required | Description | Default |
|---|---|---|---|
| room_id | Yes | The unique identifier of the Chatwork room. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description simply says 'get' implying a read operation, but it does not disclose potential edge cases (e.g., invalid room_id) or behavioral details like authentication requirements or 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?
Single sentence, no wasted words. However, it is minimal and could benefit from a bit more context without becoming verbose.
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 read tool with one parameter, the description is adequate. However, it does not describe the expected return format (e.g., list of user IDs or objects), which would be helpful since no output schema is provided.
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 100% with one parameter (room_id) already well-described. The description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.
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 action ('Get'), resource ('list of members'), and context ('in a room'). It is specific and distinct from sibling tools like list_messages or list_rooms.
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. There is no mention of prerequisites, exclusion criteria, or suggested usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
leave_roomD
Leave a room.
| Name | Required | Description | Default |
|---|---|---|---|
| room_id | Yes | The unique identifier of the Chatwork room to leave. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and description fails to disclose any behavioral traits such as permissions, side effects, or irreversibility. The agent cannot assess implications of calling this tool.
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 short but at the cost of clarity. No structure, front-loading is irrelevant because there is minimal content. It sacrifices usefulness for brevity.
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?
With no output schema and no annotations, the description fails to explain the tool's effect, return value, or any constraints. Completely inadequate for a tool with only one parameter.
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 100% with a clear description for room_id. Description adds no extra meaning beyond schema, so baseline score of 3 is appropriate.
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 is 'Leave a room.' which is a tautology of the tool name 'leave_room'. It does not add any specificity about what leaving entails or how it differs from other actions.
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 vs alternatives, no prerequisites or context described. The agent has no information about appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_messagesC
Retrieves the list of messages for a specified room.
| Name | Required | Description | Default |
|---|---|---|---|
| room_id | Yes | The unique identifier of the Chatwork room. | |
| force | No | If true, retrieves the latest 100 messages regardless of read status. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose what happens if room_id is invalid, pagination behavior, or effect of 'force' parameter beyond schema description. Lacks details on response format or potential errors.
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?
Single sentence, no redundant information, front-loaded with 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?
Given no output schema and no annotations, the description is too minimal. It omits behavioral context (e.g., what response contains, error handling) and does not clarify the 'force' parameter behavior beyond schema.
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?
Input schema has 100% description coverage for both parameters. Description does not add additional meaning beyond schema definitions, so baseline score is appropriate.
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 verb 'Retrieves', resource 'list of messages', and scope 'for a specified room'. It distinguishes from siblings like 'send_message' and 'delete_message' by targeting listing, though not explicitly differentiating from other get/list 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 'get_room_members' or search tools. No prerequisites or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_roomsB
Retrieves a list of Chatwork rooms the user belongs to.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose all behavioral traits. It only states the action without mentioning read-only nature, pagination, ordering, or any side effects. This is insufficient for safe invocation.
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 sentence of 11 words, front-loaded with the verb, and contains no redundant information. It is maximally concise for the information it conveys.
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 lack of output schema and annotations, the description does not explain what fields are in the returned list (e.g., room IDs, names) or any limitations. This leaves the agent with incomplete information to use the tool effectively.
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 input schema has no parameters, so the description does not need to explain any. The description adds meaning by clarifying that the list is of rooms the user belongs to, which is useful context beyond the empty schema.
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 specifies the action ('Retrieves'), the resource ('list of Chatwork rooms'), and the scope ('the user belongs to'). It effectively distinguishes this tool from siblings like get_room_members (which retrieves members of a specific room) and list_messages (messages in a room).
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 provides no guidance on when to use this tool versus alternatives, no prerequisites, and no context about when not to use it. This leaves the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_messageC
Allows the agent to send messages to a room.
| Name | Required | Description | Default |
|---|---|---|---|
| room_id | Yes | The unique identifier of the Chatwork room. | |
| body | Yes | The message content to send. |
TDQS
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 'sends messages', implying a write operation. It omits side effects, permission requirements, rate limits, or error behavior, leaving significant gaps for an AI agent.
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, efficient sentence with no wasted words. However, it could include brief usage guidelines without harming conciseness, so it is very good but not perfect.
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 two-parameter tool with no output schema, the description fails to mention return behavior, success indications, or error cases. Given the lack of annotations, this is incomplete for safe 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?
Schema coverage is 100%, so both parameters have descriptions in the schema. The description adds no extra meaning beyond what the schema already provides, meeting the baseline but not exceeding it.
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 action (send messages) and the target (a room), effectively distinguishing it from sibling tools like delete_message and list_messages. Though it could specify the platform (Chatwork), the input schema context makes it clear.
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 such as delete_message or list_messages. There are no prerequisites, exclusions, or context for when sending is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
9 tool updates
v1.0.0- First observed
complete_task - First observed
create_task - First observed
delete_message - First observed
get_my_tasks - First observed
get_room_members - First observed
leave_room - First observed
list_messages - First observed
list_rooms - First observed
send_message
TDQS
Scored across 9 tools
Each tool has a clearly distinct purpose: task creation/completion, message deletion, room membership, etc. No two tools could be confused for the same operation.
All tools follow a consistent verb_noun pattern in snake_case (e.g., complete_task, list_rooms). No mixing of conventions.
9 tools cover the core functionalities of a chat server (rooms, messages, tasks) without being excessive or sparse. The number is well-scoped.
The toolset covers essential CRUD operations for messages and tasks, plus room management. A minor gap is the lack of a tool to get details for a single room beyond members, but core workflows are complete.
Maintenance
Related MCP Connectors
Messaging tools for AI agents: send messages, manage chats, groups and channels.
- UproarOAuthchat.uproar
Chat where AI agents are first-class members, with their own identity and permissions.
AI-native task management: list, create, update and archive tasks with rich context for AI agents
Manage Superlist tasks and lists in plain language from any MCP-compatible AI agent.