集成 Slack 的 Devin AI 的 MCP 服务器
这是一个基于 TypeScript 的 MCP 服务器，用于集成 Devin AI 和 Slack。该服务器支持：
创建 Devin 会话并自动将任务发布到 Slack
向 Devin 会话和相应的 Slack 线程发送消息
通过增强的 Slack 集成管理会话
自动将 Devin 任务发布到 Slack 并提及@Devin
维护 Devin 会话和 Slack 线程之间的线程上下文
使用 Slack Bot 令牌进行身份验证
create_devin_session - 创建新的 Devin 会话并发布到 Slack
将任务发布到指定的 Slack 频道并提及@Devin
返回会话详细信息和 Slack 消息信息
send_message_to_session - 使用可选的 Slack 线程向 Devin 会话发送消息
可以同时发布到 Slack 线程（如有提供）
get_devin_session - 获取带有可选 Slack 消息历史记录的会话详细信息
list_devin_sessions - 列出所有 Devin 会话
get_organization_info - 获取有关您的 Devin 组织的信息
Related MCP server: Slack MCP Server
安装依赖项：
pnpm install构建服务器：
pnpm run build对于使用自动重建的开发：
pnpm run watch该服务器通过 MCP 服务器配置文件进行配置。将以下内容添加到您的配置中：
"devin-mono": {
"command": "node",
"args": ["/path/to/mcp-devin/build/index.js"],
"env": {
"DEVIN_API_KEY": "your-devin-api-key",
"DEVIN_ORG_NAME": "Your Organization",
"SLACK_BOT_TOKEN": "xoxb-your-slack-bot-token",
"SLACK_DEFAULT_CHANNEL": "general"
}
}必须在env部分设置以下环境变量：
DEVIN_API_KEY ：您的 Devin API 密钥
DEVIN_ORG_NAME ：（可选）您的组织名称，默认为“默认组织”
DEVIN_BASE_URL ：（可选）Devin API 的基本 URL，默认为“ https://api.devin.ai/v1 ”
SLACK_BOT_TOKEN ：您的 Slack Bot 用户 OAuth 令牌（以 xoxb- 开头）
SLACK_DEFAULT_CHANNEL ：默认的 Slack 消息发布频道。您可以使用以下任一方式：
频道ID（例如C123ABC456 ）
频道名称（例如general或#general ）
要与 Claude Desktop 一起使用，请添加服务器配置：
在 MacOS 上： ~/Library/Application Support/Claude/claude_desktop_config.json在 Windows 上： %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"@kazuph/mcp-devin": {
"command": "/path/to/@kazuph/mcp-devin/build/index.js"
}
}
}由于 MCP 服务器通过 stdio 进行通信，调试起来可能比较困难。我们推荐使用MCP Inspector ，它以包脚本的形式提供：
pnpm run inspector检查器将提供一个 URL 来访问浏览器中的调试工具。
Create a new Devin session for code development and post the task to Slack. Note: This is the recommended approach as it will automatically post your task to Slack as @Devin mention. Please craft your request to Devin in the same language that the user is using to communicate with you, maintaining language consistency throughout the experience.
| Name | Required | Description | Default |
|---|---|---|---|
| idempotent | No | Enable idempotent session creation | |
| machine_snapshot_id | No | Optional machine snapshot ID | |
| max_acu | No | Optional compute limit override | |
| prompt | Yes | Task description for Devin | |
| slack_channel | No | Optional Slack channel ID to post to (default: from config) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool posts to Slack automatically and requires language consistency, which are valuable behavioral traits. However, it doesn't cover important aspects like whether this is a mutating operation, what permissions are needed, rate limits, or what happens on failure, leaving gaps for a creation 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 appropriately sized with two sentences that each serve distinct purposes: the first states the core functionality, the second provides implementation guidance. It's front-loaded with the main action and avoids unnecessary repetition, though the second sentence could be slightly more concise.
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 has 5 parameters, no annotations, and no output schema, the description provides adequate context about the creation and Slack posting behavior. However, it lacks information about what the tool returns (session ID, status, etc.), error conditions, or dependencies, making it incomplete for a creation tool with multiple parameters.
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 documents all 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, such as explaining how 'prompt' should be structured or when to use 'machine_snapshot_id'. This meets the baseline for high schema coverage.
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 creates a new Devin session for code development and posts the task to Slack, providing a specific verb ('create') and resource ('Devin session'). It distinguishes from siblings like 'get_devin_session' or 'list_devin_sessions' by focusing on creation rather than retrieval, though it doesn't explicitly contrast with 'send_message_to_session'.
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 clear context on when to use this tool: it's the 'recommended approach' for creating sessions that automatically post to Slack as @Devin mentions. It includes guidance on language consistency, but doesn't explicitly state when not to use it or mention alternatives like using other session tools without Slack integration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about an existing Devin session and optionally fetch associated Slack messages
| Name | Required | Description | Default |
|---|---|---|---|
| fetch_slack_info | No | Whether to fetch associated Slack messages (if available) | |
| session_id | Yes | The ID of the Devin session |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves information, which implies read-only behavior, but fails to disclose critical traits such as authentication requirements, rate limits, error conditions, or what 'information' includes beyond Slack messages, leaving significant gaps for an 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, well-structured sentence that front-loads the core purpose ('Get information about an existing Devin session') and efficiently adds the optional feature ('and optionally fetch associated Slack messages'), with zero wasted words or 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 the lack of annotations and output schema, the description is incomplete for a tool with 2 parameters and behavioral complexity. It doesn't explain what 'information' is returned, how errors are handled, or prerequisites like session existence, leaving the agent with insufficient context for reliable 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?
The schema description coverage is 100%, with clear descriptions for both parameters (session_id and fetch_slack_info). The description adds minimal value beyond the schema by mentioning 'optionally fetch associated Slack messages', which aligns with fetch_slack_info, but doesn't provide additional context like format or constraints, meeting the baseline for high schema coverage.
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 with specific verbs ('Get information about an existing Devin session') and resources ('Devin session', 'associated Slack messages'), distinguishing it from siblings like create_devin_session (creates new), list_devin_sessions (lists multiple), and send_message_to_session (sends 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 by mentioning 'existing Devin session' (suggesting it's for retrieval rather than creation) and 'optionally fetch associated Slack messages' (hinting at an alternative use case), but it lacks explicit guidance on when to use this versus alternatives like list_devin_sessions or detailed exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the current Devin organization
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying it's likely read-only, but doesn't confirm if it requires authentication, has rate limits, or what specific information is returned. For a tool with zero annotation coverage, this is inadequate.
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 with no wasted words. It's front-loaded with the core purpose and appropriately sized for a simple tool, making it highly efficient and easy to parse.
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 (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on return values, authentication, or error handling, which could be helpful for an agent. It meets the bare minimum but has clear gaps.
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 tool has 0 parameters, and the schema description coverage is 100% (as there are no parameters to describe). The description doesn't need to add parameter semantics, so a baseline score of 4 is appropriate, as it avoids redundancy while being complete for this case.
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 resource ('information about the current Devin organization'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get_devin_session' or 'list_devin_sessions' that might also retrieve organizational data, so it doesn't reach the highest score.
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. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone. This is a significant gap in helping the agent select the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Devin sessions
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of sessions to return | |
| offset | No | Number of sessions to skip |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It doesn't mention whether this is a read-only operation, what permissions might be required, whether results are paginated (though parameters suggest they might be), or what format the returned sessions will have. The description adds almost no behavioral context beyond the basic action.
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 - a single sentence with no wasted words. It's front-loaded with the essential information (the action and resource) and contains no unnecessary elaboration. This is an example of efficient communication where every word earns its place.
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 that there are no annotations and no output schema, the description is incomplete for a tool that presumably returns session data. For a list operation with pagination parameters, the description should ideally mention what information sessions contain, whether results are ordered, or what authentication might be required. The minimal description leaves significant gaps in understanding the tool's behavior and output.
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 100% schema description coverage, the input schema already fully documents both parameters (limit and offset). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 for high schema coverage situations where the schema does the heavy lifting.
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 ('all Devin sessions'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential siblings like 'get_devin_session' or explain what distinguishes 'list' from 'get' operations in this context.
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. With siblings like 'get_devin_session' (presumably for retrieving a specific session) and 'send_message_to_session' (for interacting with sessions), the description offers no context about when listing all sessions is appropriate versus using more targeted tools.
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 an existing Devin session and optionally to the associated Slack thread
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Message to send to Devin | |
| session_id | Yes | The ID of the Devin session | |
| slack_channel | No | Optional Slack channel ID to post to | |
| slack_thread_ts | No | Optional Slack thread timestamp to reply to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the action 'send a message' but doesn't describe what happens after sending (e.g., does Devin respond, is it async, are there rate limits, what permissions are needed). For a communication tool with zero annotation coverage, this leaves significant gaps in understanding the tool's 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, efficient sentence that front-loads the core purpose and includes the optional Slack functionality. Every word earns its place with no redundancy or unnecessary elaboration.
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 annotations and no output schema, the description adequately covers the basic action but lacks details on behavioral outcomes, error conditions, or response format. For a tool that sends messages (potentially involving async interactions or notifications), more context on what to expect after invocation would be helpful.
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 documents all 4 parameters thoroughly. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain the relationship between slack_channel and slack_thread_ts or provide usage examples). Baseline 3 is appropriate when the schema does the heavy lifting.
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 'send' and the resource 'message to an existing Devin session', with additional optional functionality 'to the associated Slack thread'. It distinguishes from siblings like create_devin_session (creation vs. communication) and get/list sessions (retrieval vs. action).
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 when you have an existing session (vs. create_devin_session for new sessions) and want to communicate with it, but doesn't explicitly state when to use this tool versus alternatives like whether it's for real-time interaction or notifications. No explicit exclusions or detailed context are provided.
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. Dates show when Glama detected each change.
v1.0.0create_devin_sessionget_devin_sessionget_organization_infolist_devin_sessionssend_message_to_sessionEach tool has a clearly distinct purpose with no ambiguity. create_devin_session initiates sessions, get_devin_session retrieves session details, list_devin_sessions enumerates sessions, send_message_to_session communicates with sessions, and get_organization_info provides organizational context. The boundaries between session management, communication, and organization info are well-defined.
All tools follow a consistent verb_noun pattern with snake_case throughout. The verbs (create, get, list, send) are appropriately descriptive and consistently applied, making the naming predictable and readable across the tool set.
With 5 tools, this server is well-scoped for managing Devin sessions and organization info. Each tool earns its place by covering essential operations: session creation, retrieval, listing, messaging, and organization details, without unnecessary bloat or missing functionality.
The tool set provides strong coverage for session lifecycle management (create, get, list, message) and organization info, with no dead ends. A minor gap exists in the lack of session deletion or update tools, but agents can likely work around this, and core workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A simple Typescript MCP server built using the official MCP Typescript SDK and smithery/cli. This…
A TypeScript MCP server for Home Assistant, enabling programmatic management of entities, automati…
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Devopness MCP server for DevOps happiness! Empower AI Agents to deploy apps and infra, to any cloud.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kazuph/mcp-devin'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
