MCP Feishu Project Manager

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes focused on different aspects of project management (roles, views, work items, metadata), but get_view_detail and get_view_detail_by_name have significant overlap as both retrieve work item lists from views using different identifiers. The descriptions clarify the difference (view_id vs view_name), but the core functionality is similar, which could cause some confusion.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with clear, descriptive names (get_flow_roles, get_view_detail, get_view_list, etc.). The naming convention is uniform throughout the set, making it easy to understand each tool's purpose at a glance.
Tool Count4/5
With 6 tools, the count is reasonable for a project management server, covering key operations like retrieving roles, views, and work items. However, it feels slightly thin as it lacks update, create, or delete operations, which are common in such domains, limiting it to read-only functionality.
Completeness2/5
The tool set is severely incomplete for a project manager server, as it only provides read operations (get_*). There are no tools for creating, updating, or deleting work items, views, or roles, which are essential for managing a project lifecycle. This will likely cause agent failures when trying to perform basic project management tasks.
Average 3.2/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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 mentions pagination behavior (page_num and page_size with defaults), which is useful context beyond just listing parameters. However, it doesn't describe important behavioral aspects like whether this is a read-only operation, what permissions might be required, rate limits, error conditions, or the format/structure of the returned work item list. For a tool with 3 parameters and no annotations, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with a clear purpose statement followed by parameter explanations. The two-sentence structure is efficient with zero waste. However, the parameter explanations could be slightly more integrated with the purpose statement rather than presented as a separate 'Args:' section, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is partially complete. It covers the purpose and parameter semantics adequately but lacks behavioral context and usage guidelines. Without annotations or output schema, the description should ideally provide more information about what the tool returns and how it behaves, but it does the minimum viable job for a read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides meaningful semantic information for all 3 parameters beyond what the schema offers. The schema has 0% description coverage (only titles), while the description explains: 'view_id: 视图标识id' (view identification ID), 'page_num: 页码，默认为1' (page number, default 1), and 'page_size: 每页数量，默认为20' (items per page, default 20). This adds crucial context about parameter purposes and default values that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '根据视图id获取指定视图下的工作项列表' (Get work item list under specified view based on view ID). It specifies the verb '获取' (get) and resource '工作项列表' (work item list) with the scope '指定视图下' (under specified view). However, it doesn't explicitly differentiate from sibling tools like get_view_list or get_work_item_detail, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling tools like get_view_list (which might list views rather than items within a view) or get_view_detail_by_name (which appears to do similar functionality by name instead of ID). There's no context about prerequisites, when this tool is appropriate, or what alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 describes what the tool returns (metadata about field meanings) but doesn't mention whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or response format. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with a clear purpose statement followed by bullet points for usage context and parameter explanation. The structure is logical and front-loaded with the main purpose. Every sentence adds value, though the formatting could be slightly cleaner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 1 parameter with 0% schema description coverage and no output schema or annotations, the description does an adequate job explaining the parameter semantics and general purpose. However, it doesn't describe the return format, error handling, or behavioral constraints that would be important for a metadata retrieval tool. The description is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds valuable semantic information beyond the input schema. While the schema only shows an enum with values 'story', 'version', 'issue', the description explains what these values represent in the domain context: '分别对应需求、版本、缺陷' (corresponding to requirement, version, defect respectively). This translation of technical keys to business concepts is helpful context that the schema alone doesn't provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取工作项类型元数据' (Get work item type metadata) and explains that this metadata provides field meanings and information in work item details. It specifies the resource (work item type metadata) and verb (get), but doesn't explicitly differentiate from sibling tools like get_work_item_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by mentioning that the metadata helps understand fields in work item details, but it doesn't explicitly state when to use this tool versus alternatives like get_work_item_detail or other sibling tools. There's no guidance on prerequisites, exclusions, or specific scenarios for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does ('获取流程角色配置详情') and lists parameter values, without describing any behavioral traits like whether it's read-only, requires authentication, has rate limits, or what the output format might be. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the tool's purpose followed by parameter details. It uses two sentences efficiently, with no wasted words. However, the structure could be slightly improved by separating the purpose and parameter sections more clearly, but it remains concise and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (single parameter with enum), no annotations, and no output schema, the description is partially complete. It explains the parameter semantics well, but lacks behavioral context and usage guidelines. For a retrieval tool, it should ideally describe the output or behavior more, but the parameter coverage helps balance this. It meets a minimum viable level but has clear gaps in overall context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema. The schema has 0% description coverage, only providing an enum without explanations. The description explicitly defines the parameter 'work_item_type_key' and maps each enum value to its semantic meaning: 'story' to '需求' (requirement), 'version' to '版本' (version), and 'issue' to '缺陷' (defect). This compensates fully for the low schema coverage, making the parameter usage clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取流程角色配置详情' (Get process role configuration details). It specifies the verb '获取' (get) and the resource '流程角色配置详情' (process role configuration details), which is specific and meaningful. However, it doesn't differentiate this tool from its siblings (e.g., get_view_detail, get_work_item_detail), which are also retrieval tools, so it doesn't fully distinguish itself in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 lists the parameter values but doesn't explain the context or prerequisites for invoking it, such as when process role details are needed compared to other details available from sibling tools. There's no mention of alternatives or exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions pagination behavior (default page_num=1, page_size=20) which is useful, but doesn't cover other important aspects like authentication requirements, rate limits, error conditions, or what happens when the view doesn't exist. For a tool with 4 parameters and no annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured. It starts with the core purpose, then lists parameters with clear explanations. Each parameter description earns its place by adding value beyond the schema. The formatting with 'Args:' section makes it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no annotations, and no output schema, the description does a good job with parameters but lacks completeness. It doesn't explain what the tool returns (work item list format), error conditions, or authentication requirements. For a data retrieval tool with pagination, more behavioral context would be helpful, though the parameter documentation is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics beyond the input schema. While schema description coverage is 0%, the description explains: 1) view_name is required, 2) work_item_type_key has specific enum values with Chinese translations ('story'='需求', 'version'='版本', 'issue'='缺陷'), 3) page_num defaults to 1, 4) page_size defaults to 20. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '根据视图名称获取指定视图下的工作项列表' (Get work item list under specified view by view name). It specifies the verb ('获取' - get) and resource ('工作项列表' - work item list), but doesn't differentiate from sibling tools like 'get_view_detail' or 'get_view_list', which likely have similar functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention sibling tools like 'get_view_detail' or 'get_view_list', nor does it explain what distinguishes this tool from them. There's no context about prerequisites or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes a read operation ('获取' - get) but doesn't mention any behavioral traits such as permissions required, rate limits, pagination, or what the output looks like (e.g., list format, fields included). For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by a parameter explanation. There's no wasted text, and the structure is logical. However, the use of both Chinese and English in the Args section might slightly reduce clarity for non-bilingual agents, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) but lack of annotations and output schema, the description is moderately complete. It covers the purpose and parameter semantics well, but fails to address behavioral aspects like output format or operational constraints. This makes it adequate for basic use but insufficient for full agent understanding without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema. The schema only provides an enum for work_item_type_key with values 'story', 'version', 'issue', but the description explains these correspond to '需求' (requirement), '版本' (version), and '缺陷' (defect) in Chinese, clarifying the business context. With 0% schema description coverage and 1 parameter, this compensation is effective, though it could note if the parameter is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取当前飞书项目下的某一类型工作项的所有视图列表' (Get all view lists for a specific type of work item in the current Feishu project). It specifies the verb ('获取' - get) and resource ('视图列表' - view lists), with context about the project and work item type. However, it doesn't explicitly differentiate from sibling tools like get_view_detail or get_view_detail_by_name, which appear to fetch individual views rather than lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying the work item type parameter and its possible values, suggesting this tool is used to retrieve views filtered by work item type. However, it doesn't provide explicit guidance on when to use this tool versus alternatives (e.g., get_view_detail for single views) or any prerequisites. The context is clear but lacks comparative or exclusionary statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states what the tool does (retrieves details) but doesn't mention whether this is a read-only operation, what permissions might be required, whether there are rate limits, what format the details come in, or any error conditions. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with a clear structure: purpose statement followed by parameter explanations. The Chinese text is efficient with no wasted words. It could be slightly improved by front-loading the most critical information more explicitly, but overall it's well-structured and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 required parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does and documents the parameters well, but lacks information about the return format, error handling, or behavioral constraints. Without annotations or output schema, the agent won't know what to expect from the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics beyond the input schema. While the schema has 0% description coverage, the description explains: 1) what 'work_item_type_key' represents ('工作项类型' - work item type), 2) the meaning of each enum value ('story'对应需求, 'version'对应版本, 'issue'对应缺陷), and 3) how to format 'work_item_ids' ('多个ID之间用逗号分隔' - multiple IDs separated by commas). This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取指定工作项的详情信息' (Get details of specified work items). It specifies the verb ('获取' - get) and resource ('工作项的详情信息' - work item details), making the purpose unambiguous. However, it doesn't distinguish this tool from potential sibling tools that might also retrieve work item information, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. While sibling tools like 'get_view_detail' or 'get_work_item_type_meta' exist, there's no indication of when this specific tool is appropriate versus those others. The description only explains what the tool does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-feishu-proj MCP server](https://glama.ai/mcp/servers/Roland0511/mcp-feishu-proj/badges/card.svg)](https://glama.ai/mcp/servers/Roland0511/mcp-feishu-proj)

Score Badge

Copy to your README.md:

[![mcp-feishu-proj MCP server](https://glama.ai/mcp/servers/Roland0511/mcp-feishu-proj/badges/score.svg)](https://glama.ai/mcp/servers/Roland0511/mcp-feishu-proj)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Roland0511/mcp-feishu-proj'

If you have feedback or need assistance with the MCP directory API, please join our Discord server