Feishu MCP Server

by ZYHB

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose focused on specific operations for Feishu's Bitable (multidimensional table) feature. The tools are well-differentiated by their action (create, delete, get, update, search, copy) and scope (single vs. batch operations), with no overlapping functionality that would cause confusion.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with 'bitable' as the common domain identifier (e.g., create_bitable_record, batch_update_bitable_records). The naming is uniform, using snake_case throughout, making it predictable and easy to understand the tool's purpose at a glance.
Tool Count5/5
With 9 tools, this server is well-scoped for managing Feishu Bitable applications and records. It covers essential CRUD operations for both single and batch processing, along with app management (create and copy), which is appropriate for the domain without being overly complex or insufficient.
Completeness5/5
The tool set provides complete coverage for the Bitable domain, including full CRUD lifecycle for records (create, get, update, delete, search) in both single and batch forms, plus app creation and copying. There are no obvious gaps; agents can perform all expected operations without dead ends.
Average 3/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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 the 1000-record limit (useful context) but doesn't describe authentication needs, rate limits, error handling, or what happens when the limit is exceeded. For a batch creation 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 sized with clear sections for purpose, parameters, and return value. Each sentence adds value, though the parameter explanations could be more detailed given the 0% schema coverage. The structure is logical and front-loaded with the core purpose.
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 3 parameters with 0% schema coverage and no annotations, the description provides basic parameter semantics but lacks behavioral context. The presence of an output schema reduces the need to explain return values, but for a batch creation tool, more guidance on usage, constraints, and error scenarios would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists all three parameters with brief explanations, adding meaning beyond the bare schema. However, it doesn't provide format details (e.g., what fields dictionary contains, token format) or constraints beyond the 1000-record limit mentioned in the purpose section.
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 verb ('批量创建' - batch create) and resource ('多维表格记录' - multi-dimensional table records) with a specific scope ('最多1000条' - up to 1000 records). It distinguishes from the sibling 'create_bitable_record' by indicating batch capability, though it doesn't explicitly mention this distinction.
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 on when to use this tool versus alternatives like 'create_bitable_record' (single record creation) or other batch operations. The description mentions the 1000-record limit but doesn't explain when batch creation is preferred over individual creation or how it relates to other batch operations in the sibling list.
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 states the tool performs batch deletion but doesn't mention critical aspects like whether deletions are permanent, require specific permissions, have rate limits, or affect related data. The phrase '删除结果' (deletion result) is vague and doesn't explain what the output contains (e.g., success/failure status, error details).
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 well-structured with clear sections for purpose, parameters, and return value. It uses bullet-like formatting in Chinese. However, the '返回' (return) section is overly vague ('删除结果' - deletion result) and could be more informative. Overall, it's appropriately sized with no redundant information.
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 (batch deletion with 3 parameters), no annotations, and an output schema (which should document return values), the description is moderately complete. It covers the basic purpose and parameters but lacks behavioral context (e.g., idempotency, error handling). The output schema existence reduces the need to detail return values, but the description should still guide usage relative to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists all three parameters (app_token, table_id, record_ids) with brief Chinese explanations that add basic meaning beyond the schema's English titles. However, it doesn't provide format details (e.g., token format, ID structure), constraints (e.g., max records in batch), or examples. The value added is minimal but covers all parameters.
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 action ('批量删除' - batch delete) and resource ('多维表格记录' - bitable records). It distinguishes from siblings like batch_create_bitable_records and batch_update_bitable_records by specifying the delete operation. However, it doesn't explicitly differentiate from single-record deletion tools like update_bitable_record (which might include deletion).
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 when batch deletion is preferred over single-record deletion, nor does it reference sibling tools like batch_update_bitable_records (which might handle deletions differently) or create_bitable_record (for creation). No context about prerequisites or constraints is given.
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. It mentions the 1000-record limit (useful context) but lacks critical behavioral details: authentication requirements, error handling, whether updates are atomic, rate limits, or what happens with partial failures. For a batch mutation tool, 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?
Well-structured with clear sections for purpose, parameters, and return. The purpose statement is front-loaded. Some redundancy exists (e.g., '参数:' could be omitted in a more concise format), but overall it's efficient with minimal waste.
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 complexity (batch mutation with 3 parameters, no annotations) and an output schema exists (so return values are covered), the description is moderately complete. It covers basic purpose and parameters but lacks behavioral context and usage guidance, making it adequate but with clear gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists all three parameters with brief explanations, adding meaning beyond the bare schema. However, it doesn't detail the structure of 'records' (beyond mentioning record_id and fields) or provide examples, leaving gaps in parameter understanding.
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 action ('批量更新' - batch update) and resource ('多维表格记录' - multi-dimensional table records), with a specific scope of up to 1000 records. It distinguishes from siblings like 'batch_create_bitable_records' and 'update_bitable_record' by emphasizing batch operations, though it doesn't explicitly name alternatives.
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 explicit guidance on when to use this tool versus alternatives like 'update_bitable_record' (single record update) or 'batch_create_bitable_records'. The description mentions the 1000-record limit but doesn't provide context for choosing between batch and single operations or other sibling tools.
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 states it creates a record but doesn't mention permissions required, whether it's idempotent, error handling, or rate limits. The description is minimal and doesn't provide adequate behavioral context for a mutation tool.
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 well-structured with clear sections for parameters and returns, and reasonably concise. However, the '返回' section could be more informative given it has an output schema, and some sentences could be more 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?
For a 3-parameter mutation tool with no annotations, the description is minimally adequate but has significant gaps. It covers basic purpose and parameters but lacks usage guidance, behavioral context, and comprehensive parameter semantics. The existence of an output schema helps, but overall completeness is limited.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists all three parameters with brief explanations and an example for 'fields', adding some semantic context beyond the schema. However, with 0% schema description coverage, this only partially compensates - it doesn't explain parameter formats, constraints, or provide comprehensive examples for all parameters.
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 action ('创建单条记录' - create a single record) and resource ('在多维表格中' - in a multi-dimensional table), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'batch_create_bitable_records' or 'create_bitable_app', which would be needed for 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. With multiple sibling tools available (e.g., batch_create_bitable_records, create_bitable_app, search_bitable_records), there's no mention of when this single-record creation is preferred over batch operations or other related tools.
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. While it correctly identifies this as an update operation, it doesn't mention important behavioral aspects like authentication requirements, error handling, whether the update is idempotent, what happens with invalid fields, or any rate limits. The description only states what the tool does at a basic functional level.
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 well-structured with clear sections for purpose, parameters, and return value. It's appropriately sized for a 4-parameter tool, with no redundant information. Every sentence serves a purpose, though the parameter explanations could be more informative.
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 that this is a mutation tool with no annotations, 4 parameters (including a nested object), and an output schema exists, the description is moderately complete. It covers the basic purpose and parameters but lacks important behavioral context for a write operation. The existence of an output schema means the description doesn't need to explain return values in detail, which helps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description attempts to compensate by listing all 4 parameters with brief explanations. However, the explanations are minimal ('多维表格的token', '数据表ID', '记录ID', '要更新的字段字典') and don't provide format requirements, constraints, or examples. The description adds some value over the bare schema but doesn't fully compensate for the complete 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 verb ('更新' meaning 'update') and resource ('多维表格中的单条记录' meaning 'single record in a multi-dimensional table'), which is specific and unambiguous. It distinguishes from batch operations by specifying 'single record', but doesn't explicitly differentiate from other sibling tools like batch_update_bitable_records beyond this implicit distinction.
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. There are multiple sibling tools for batch operations and other bitable functions, but the description doesn't mention any of them or provide context about when this single-record update is preferred over batch operations or other related tools.
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 must fully disclose behavioral traits. It states the tool copies an app and returns JSON, but lacks details on permissions required, whether it's a read-only or mutation operation, potential side effects (e.g., if the original app is affected), rate limits, or error handling. For a tool that likely involves data duplication and creation, 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 structured with clear sections for parameters and returns. It uses bullet points effectively, avoiding unnecessary verbosity. However, the initial line '复制多维表格应用' could be more front-loaded with additional context, and the structure, while good, isn't perfectly optimized for immediate comprehension.
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 (copying an app with 3 parameters), no annotations, and an output schema (which handles return values), the description is moderately complete. It covers parameters well but lacks behavioral details like permissions or side effects. The output schema reduces the need to explain returns, but overall completeness is adequate with noticeable 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 significant meaning beyond the input schema, which has 0% description coverage. It explains each parameter: 'app_token' as the token of the app to copy, 'name' as the name for the new app, and 'folder_token' as an optional folder token for specifying the creation location. This clarifies the purpose and usage of all parameters, compensating well 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: '复制多维表格应用' (copy a multi-dimensional table application). It specifies the verb (copy) and resource (multi-dimensional table app), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'create_bitable_app', which might create a new app from scratch rather than copying an existing one.
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 prerequisites (e.g., needing an existing app to copy), compare it to 'create_bitable_app' for creating new apps, or specify scenarios where copying is preferred over creating. This lack of context leaves the agent without usage direction.
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 support and optional filtering, but doesn't cover important aspects like authentication requirements (app_token usage), rate limits, error conditions, whether this is a read-only operation, or what happens with invalid parameters. The description is insufficient for a tool with 5 parameters and no annotation coverage.
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 well-structured with clear sections for purpose, parameters, and returns. It's appropriately sized with no redundant information. The Chinese formatting with clear section headers makes it easy to parse, though the English translation in parentheses could be more consistent.
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 5 parameters, no annotations, but does have an output schema, the description covers the basic purpose and parameters adequately. However, for a search tool with filtering and pagination capabilities, it should provide more context about filter syntax, pagination behavior, and typical use cases. The existence of an output schema reduces the need to describe return values, but behavioral context is still lacking.
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?
With 0% schema description coverage, the description provides valuable semantic information about all 5 parameters: it explains app_token identifies the table, table_id specifies which table, page_size range (1-500), page_token usage for pagination, and filter as optional condition. This compensates well for the lack of schema descriptions, though it doesn't provide format examples for the filter object.
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 as '查询多维表格记录' (search multi-dimensional table records) with the specific action '查询' (search/query) on the resource '多维表格记录' (multi-dimensional table records). It distinguishes from siblings like create/update/delete operations, though it doesn't explicitly differentiate from batch_get_bitable_records which might 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?
The description provides no guidance on when to use this tool versus alternatives like batch_get_bitable_records or other sibling tools. It mentions pagination support but doesn't explain when paginated search is preferable over batch operations or other retrieval methods.
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 full burden. It states it creates an application and returns JSON with app_token, which implies a write operation with a specific output. However, it lacks critical behavioral details: it doesn't mention permissions needed, whether this is idempotent, rate limits, or what happens if the name already exists. For a creation tool with zero 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 front-loaded: the first line states the purpose clearly, followed by parameter and return sections. Every sentence adds value, with no wasted words. However, the structure could be slightly more polished (e.g., bullet points), but it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (returns JSON with app_token), the description doesn't need to explain return values in detail. It covers the basic purpose and parameters adequately. However, as a creation tool with no annotations, it should ideally mention more about behavioral aspects like permissions or idempotency to be fully complete.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics: it explains that 'name' is the multi-dimensional table name and 'folder_token' is optional for specifying the creation location. This clarifies beyond the schema's basic titles, though it doesn't detail format constraints (e.g., length limits for name). With 0% coverage, this is good but not exhaustive.
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 verb '创建' (create) and resource '多维表格应用' (multi-dimensional table application), making the purpose explicit. It distinguishes from siblings like 'copy_bitable_app' or 'create_bitable_record' by specifying it creates an application rather than copying or creating records. However, it doesn't explicitly contrast with all siblings, so it's not a perfect 5.
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 prerequisites, when this tool is appropriate versus other creation tools, or any exclusions. The agent must infer usage from the tool name and context alone.
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. It mentions the 100-record limit, which is useful behavioral context. However, it lacks critical details: authentication requirements, rate limits, error handling (e.g., what happens if some IDs are invalid), response format specifics, or whether it's idempotent. For a batch operation with zero 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 well-structured with clear sections (purpose, parameters, return) and uses minimal sentences. Each part earns its place: the purpose statement includes the key constraint (100-record limit), and parameter/return sections are directly helpful. Slight room for improvement in flow, but overall 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 3 parameters with 0% schema coverage and an output schema exists (so return values are documented elsewhere), the description does an adequate job. It covers the purpose and parameters semantically. However, for a batch read tool with no annotations, it should ideally include more behavioral context like error handling or performance notes to be fully complete.
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?
Schema description coverage is 0%, so the description must compensate. It lists all three parameters with brief Chinese explanations that add meaning: 'app_token' as the table's token, 'table_id' as the data table ID, and 'record_ids' as a list of record IDs. This clarifies their roles beyond schema titles. However, it doesn't specify formats (e.g., ID length/pattern) or constraints beyond the implied array for record_ids.
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 action ('批量获取' = batch get) and resource ('多维表格记录' = multi-dimensional table records), with the specific scope of '最多100条' (up to 100 records). It distinguishes from siblings like 'search_bitable_records' by focusing on retrieval by specific IDs rather than searching. However, it doesn't explicitly contrast with individual record retrieval tools.
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 when needing to fetch multiple records by their IDs (up to 100), but doesn't explicitly state when to use this versus alternatives like 'search_bitable_records' for filtering or individual get operations. No guidance on prerequisites, error conditions, or performance considerations is provided.
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:

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

Score Badge

Copy to your README.md:

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

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/ZYHB/yuppie-mcp-feishu'

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