Slack 통합을 갖춘 Devin AI용 MCP 서버
Devin AI와 Slack을 통합하는 TypeScript 기반 MCP 서버입니다. 이 서버를 통해 다음과 같은 기능을 사용할 수 있습니다.
Devin 세션 생성 및 Slack에 작업 자동 게시
Devin 세션 및 해당 Slack 스레드에 메시지 보내기
향상된 Slack 통합을 통한 세션 관리
@Devin 언급과 함께 Devin 작업을 Slack에 자동으로 게시합니다.
Devin 세션과 Slack 스레드 간의 스레드 컨텍스트를 유지합니다.
인증을 위해 Slack Bot 토큰을 사용합니다.
create_devin_session - 새로운 Devin 세션을 생성하고 Slack에 게시합니다.
@Devin 언급과 함께 지정된 Slack 채널에 작업을 게시합니다.
세션 세부 정보 및 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
종속성 설치:
지엑스피1
서버를 빌드하세요:
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
