MCP-FEISHU는 Windsurf IDE 통합을 위해 특별히 설계된 마이크로서비스 컨트롤 플레인(MCP) 서버입니다. Feishu OpenAPI에서 API 정보를 가져와 IDE의 MCP 클라이언트에 제공하여 개발 환경 내에서 원활한 API 통합 및 관리를 지원합니다.
API 사양을 검색하기 위해 Feishu OpenAPI에 연결합니다.
API 정보를 MCP 리소스로 노출합니다.
API 검색 및 탐색을 위한 도구를 제공합니다.
Windsurf IDE 내에서 API 테스트 및 통합을 지원합니다.
표준화된 통신을 위한 모델 컨텍스트 프로토콜(MCP)을 구현합니다.
Related MCP server: Lark MCP Server
지엑스피1
pnpm startnpx @modelcontextprotocol/inspector node dist/index.jspnpm buildWindsurf IDE 설정에서 다음 구성으로 새 MCP 서버를 추가합니다.
"mcpServers": {
"feiShuServer": {
"command": "node",
"args": ["/Program Files/project/mcp-feishu/dist/index.js"],
"env": {
"APP_ID": "",
"APP_SECRET": "",
"TABLE_ID": "",
"APP_TOKEN": ""
}
}
}MCP-FEISHU 서버는 다음 리소스를 제공합니다.
api://projects - 모든 API 프로젝트 나열
api://projects/{projectId} - 특정 프로젝트에 대한 세부 정보를 가져옵니다.
api://projects/{projectId}/apis - 프로젝트의 모든 API 나열
api://projects/{projectId}/apis/{apiId} - 특정 API에 대한 세부 정보를 가져옵니다.
서버는 다음과 같은 도구를 제공합니다.
get_defect_link - 특정 결함에 대한 링크를 가져옵니다.
get_recently_updated_defect_list - 최근 업데이트된 결함 목록을 가져옵니다.
# Run in development mode with hot reloading
npm run devMIT
| Name | Required | Description | Default |
|---|---|---|---|
| ID | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | ||
| startDate | Yes | ||
| endDate | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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.
get_defect_linkget_recently_updated_defect_listScored across 2 tools
The two tools have clearly distinct purposes: one retrieves a specific defect link, while the other fetches a list of recently updated defects. There is no overlap or ambiguity between them.
Both tools follow a consistent verb_noun pattern with 'get_' prefix and snake_case naming. The naming is predictable and uniform across the set.
With only 2 tools, the server feels thin for a domain like defect management in Feishu. This minimal set lacks essential operations like creating, updating, or deleting defects, making it under-scoped.
The tool surface is severely incomplete for defect management. It only provides read-only access to defects (link and list), missing critical CRUD operations such as create, update, delete, or search, which will cause agent failures in handling defect workflows.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP server for InsForge BaaS — database, storage, edge functions, and deployments
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
MCP server for interacting with the Supabase platform
