Includes an embedded Express web server to handle OAuth authentication callbacks
Employs Jest for testing the MCP server functionality
Uses TypeScript SDK for implementing the Model Context Protocol
Uses Zod for runtime type validation of API responses and requests
Click on "Install 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., "@Swit MCP Server post 'Weekly standup meeting notes are ready' to the engineering channel"
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.
░██████╗░██╗░░░░░░░██╗██╗████████╗ ███╗░░░███╗░█████╗░██████╗░
██╔════╝░██║░░██╗░░██║██║╚══██╔══╝ ████╗░████║██╔══██╗██╔══██╗
╚█████╗░░╚██╗████╗██╔╝██║░░░██║░░░ ██╔████╔██║██║░░╚═╝██████╔╝
░╚═══██╗░░████╔═████║░██║░░░██║░░░ ██║╚██╔╝██║██║░░██╗██╔═══╝░
██████╔╝░░╚██╔╝░╚██╔╝░██║░░░██║░░░ ██║░╚═╝░██║╚█████╔╝██║░░░░░
╚═════╝░░░░╚═╝░░░╚═╝░░╚═╝░░░╚═╝░░░ ╚═╝░░░░░╚═╝░╚════╝░╚═╝░░░░░https://developers.swit.io 에서 새 앱 생성
클라이언트 ID, 시크릿 발급
리다이렉트 URI: http://localhost:3000/callback 설정
~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"swit": {
"command": "npx",
"args": ["-y", "swit-mcp"],
"env": {
"SWIT_CLIENT_ID": "your-client-id",
"SWIT_CLIENT_SECRET": "your-client-secret"
}
}
}
}Claude Desktop에서 첫 Swit 도구 실행 시 OAuth 웹서버가 자동 시작
swit-oauth-start 도구 실행하여 인증 URL 획득
브라우저에서 Swit 계정으로 로그인
토큰이 자동으로 저장되며 swit-oauth-status로 확인 가능
Related MCP server: MCP Google Suite
swit-oauth-status - OAuth 인증 상태 확인 및 토큰 정보 조회
swit-oauth-start - OAuth 인증 시작 (브라우저 인증 URL 반환)
swit-workspace-list - 접근 가능한 워크스페이스 목록 조회
swit-channel-list - 지정된 워크스페이스의 채널 목록 조회 (필터링 지원)
swit-message-create - 채널에 새 메시지 전송 (텍스트/HTML 지원)
swit-message-comment-create - 기존 메시지에 댓글 작성
🎯 활용 예시: Claude에게 "Swit의 개발팀 채널에 프로젝트 진행 상황을 알려줘"라고 요청하면 자동으로 메시지를 전송할 수 있습니다.
MCP SDK: Model Context Protocol TypeScript SDK
OAuth: @swit-api/oauth 패키지 사용
Type Safety: Zod를 활용한 런타임 타입 검증
Web Server: OAuth 콜백 처리를 위한 Express 내장 웹서버
Testing: Jest + Nock을 활용한 HTTP mocking 테스트
Retrieve list of channels
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ||
| offset | No | ||
| limit | No | ||
| type | No | ||
| activity | No | ||
| disclosure | No | ||
| name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only says 'list of channels' but omits critical behavior such as pagination (offset/limit), filtering options, and that workspace_id is required. The read-only nature is implied but not explicit.
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 at 3 words, which is efficient but under-specified. No structure or front-loading of key 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 complexity (7 params, no annotations, no output schema), the description is severely incomplete. It does not address pagination, filtering, or required fields, leaving the agent underinformed.
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 has 7 parameters with 0% description coverage. The description adds no meaning to any parameter, failing to explain 'workspace_id', 'offset', 'limit', 'type', 'activity', 'disclosure', or 'name'.
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 'Retrieve list of channels' clearly states the action and resource. It distinguishes from siblings like 'swit-project-list' and 'swit-workspace-list', but is somewhat vague about scope (e.g., for which workspace or user).
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 mention of prerequisites, filters, or scenarios where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create comment on message
| Name | Required | Description | Default |
|---|---|---|---|
| message_id | Yes | ||
| content | Yes | ||
| body_type | No | plain | |
| assets | No | ||
| external_asset_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'Create', implying mutation, but provides no details on side effects (e.g., notifications, idempotency, error behavior). With no annotations, more 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 but too brief for the tool's complexity. It lacks structure and does not prioritize key information like required vs optional parameters.
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 is severely incomplete. It fails to document parameter meanings, behavioral details, or return values.
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 no meaning to the 5 parameters. Schema coverage is 0%, and the description does not explain fields like 'assets', 'external_asset_type', or the expected format of 'content'.
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 'Create comment on message' and distinguishes from the sibling 'swit-message-comment-list'. It is specific to creating a comment resource.
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. There is no mention of prerequisites, constraints (e.g., message must exist), 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.
Retrieve list of comments on message
| Name | Required | Description | Default |
|---|---|---|---|
| message_id | Yes | ||
| offset | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits but does not. It states 'Retrieve list' but omits details like pagination behavior (offset/limit handling), ordering, error cases (e.g., empty list), or whether comments are nested. The description lacks transparency about what happens when parameters are omitted.
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 short (6 words), which is concise but lacks structure. It front-loads the core action, but every sentence should earn its place. Here, the brevity sacrifices necessary details like pagination, making it borderline under-specified.
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 3 parameters (one required), no output schema, and no annotations, the description is incomplete. It does not explain the return format, pagination behavior, or how to handle the response. An agent cannot reliably invoke this tool without additional knowledge.
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 to parameters. However, it adds no context beyond parameter names. 'message_id' is somewhat self-explanatory, but 'offset' and 'limit' are not explained regarding format, defaults, or whether offset is 0-based. The description does not compensate for the lack of schema descriptions.
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 'Retrieve list of comments on message' clearly states the verb 'Retrieve' and the resource 'list of comments on message', which differentiates it from sibling tools like swit-message-comment-create (create comment) and other list tools (e.g., swit-project-list). It is specific and unambiguous.
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. There is no mention of required context, prerequisites, or when not to use it. Sibling tools are present (e.g., create comment, channel list) but are not referenced for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send message to channel
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | ||
| content | No | ||
| body_type | No | plain | |
| assets | No | ||
| attachments | No | ||
| external_asset_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks any behavioral information such as side effects, authentication needs, idempotency, or error scenarios. For a mutation tool, this is insufficient.
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 minimal at 4 words but sacrifices completeness. For a tool with multiple parameters and complex behavior, it is under-specified, not optimally 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 6 parameters, lack of output schema, and no annotations, the description is severely incomplete. It fails to provide enough context for the agent to understand the tool's full behavior and requirements.
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 does not explain any parameters. With 6 parameters and 0% schema description coverage, the agent must rely solely on parameter names, which are not descriptive (e.g., 'assets', 'attachments'). No additional meaning is provided.
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 'Send message to channel' clearly states the verb and resource, distinguishing it from siblings like 'swit-message-comment-create' which deals with comments. However, it could be more specific about the type of message or 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?
No usage guidelines are provided. The description does not specify when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. The agent receives no guidance on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Logout from OAuth authentication and delete stored tokens. Use when re-authentication is required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description discloses the destructive action of deleting tokens. It is clear about the side effect, though it could mention if any server-side invalidation occurs.
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?
Two concise sentences, front-loaded with the main action. Every word adds value, with no 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?
For a simple tool with no parameters, no output schema, and clear purpose, the description fully covers what an agent needs to know.
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 zero parameters, schema coverage is 100%. The description adds no parameter info as none are needed, meeting baseline for no-param tools.
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 uses specific verb 'logout' and resource 'OAuth authentication', clearly stating it deletes stored tokens. It distinguishes itself from other OAuth tools like swit-oauth-start and swit-oauth-status.
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?
Explicitly states 'Use when re-authentication is required', providing clear context. Although it doesn't mention alternatives, the verb 'logout' is self-explanatory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start OAuth authentication. Returns authentication URL that can be opened in browser.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the core behavior (returns a URL to open in browser) but does not detail side effects, state changes, or how to handle the returned URL.
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 with no filler. Every word adds value.
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 parameters and no output schema, the description is adequate but could benefit from notes about the OAuth flow, token handling, or that the URL must be visited to complete authentication.
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, so the input schema fully covers them. The description adds no additional parameter meaning, but with zero parameters, baseline 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 it 'Starts OAuth authentication' and returns an authentication URL. The verb and resource are specific, but it does not explicitly differentiate from siblings like swit-oauth-status or swit-oauth-logout, though the purpose is distinct enough.
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 use when initiating OAuth, but provides no explicit guidance on when to use versus alternatives, no prerequisites, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check OAuth authentication status
| 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 full burden for behavioral disclosure. It does not state that the tool is read-only, idempotent, or what the output represents (e.g., token expiry, user info). The minimal description leaves the agent guessing about 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?
The description is a single, concise sentence that clearly communicates the tool's purpose. No wasted words; every part 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 the simplicity of the tool (no parameters, no output schema), the description is minimally adequate. However, it fails to describe what the status response contains, which would be helpful for an agent interpreting the result.
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 zero parameters and schema coverage is 100%. Per the calibration, baseline for 0 params is 4. The description adds no parameter information, but none is 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 'Check' and resource 'OAuth authentication status'. It effectively distinguishes from sibling tools like swit-oauth-start and swit-oauth-logout, which handle initiation and logout respectively.
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 is provided on when to use this tool versus alternatives. While the purpose is clear, the description lacks any context about prerequisites or scenarios where checking status is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve list of projects
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | ||
| offset | No | ||
| limit | No | ||
| activity | No | ||
| disclosure | No | ||
| name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description omits critical behavioral traits such as pagination, authentication requirements, or data access limits. For a list tool, this is a significant gap.
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 concise sentence, but it is overly brief and lacks necessary detail. Appropriate length is not the same as being complete.
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 six parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain parameter semantics, return structure, or any behavioral expectations.
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 six parameters with 0% description coverage, and the tool description adds no meaning or context for any of them (workspace_id, offset, limit, activity, disclosure, name). The agent has no insight into parameter usage.
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 'Retrieve' and the resource 'list of projects', establishing its basic function. It differentiates from sibling tools like 'swit-channel-list' and 'swit-workspace-list' through the resource type, but lacks additional scope or filtering 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?
No guidance is provided on when to use this tool versus alternatives. The description implies it is for projects, but there is no explicit context for selection or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve list of workspaces
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | ||
| limit | No | ||
| name | No |
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 read-only nature, pagination, sorting, or error handling. The agent has no insight into side effects or limitations.
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 only one sentence, but it is too sparse to be informative. While brief, it fails to provide enough detail to guide proper tool usage.
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 absence of annotations and output schema, plus three unexplained parameters, the description is incomplete. It does not cover pagination, filtering, or the structure of the returned data.
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 has 0% description coverage, and the tool description does not explain any of the three parameters (offset, limit, name). The agent cannot infer their meaning or usage.
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 states 'Retrieve list of workspaces', clearly indicating the resource (workspaces) and action (retrieve list). However, it does not distinguish from sibling tools like swit-channel-list or swit-project-list, which follow the same pattern.
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 (e.g., swit-channel-list). There is no mention of prerequisites, filtering, or context.
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.
swit-channel-listswit-message-comment-createswit-message-comment-listswit-message-createswit-oauth-logoutswit-oauth-startswit-oauth-statusswit-project-listswit-workspace-listScored across 9 tools
Each tool has a clear and distinct purpose: channel management, message operations (create, comment), OAuth flow (start, status, logout), and listing of projects and workspaces. There is no overlap in functionality.
All tools use the 'swit-' prefix with snake_case. Most follow a noun-verb pattern (e.g., 'swit-channel-list', 'swit-project-list'), while some have compound nouns (e.g., 'swit-message-comment-create'). The pattern is mostly consistent but has minor deviations.
With 9 tools covering channels, messages, comments, projects, workspaces, and OAuth, the count is appropriate for a collaboration server. Each tool serves a necessary function without redundancy.
The tool set includes list operations for channels, projects, and workspaces, as well as message creation and commenting. However, it lacks update/delete for messages and channels, and does not provide retrieval of individual messages or search functionality, leaving notable gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
The Stytch MCP server is a reference implementation that demonstrates remote MCP server authentication and authorization using Stytch Connected Apps. It provides OAuth 2.1-compliant authorization (including PKCE), Dynamic Client Registration, and validates Stytch-issued access tokens to enable AI agents to securely interact with external services through permissioned access, supporting scopes like openid, email, profile, and manage:project_data.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TykanN/swit-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
