Loading ToolBench
MCP server for Agent-Staff providing Feishu (Lark) data integration: read/write multi-dimensional tables, list/read files, log records with field type conversion, and send messages. Supports department-aware operations and company-wide data aggregation.
Server has 5 tools with basic descriptions and some parameter schemas, but significant gaps in definition quality. Tool names are action-oriented (get_, log_, list_, read_, attach_), which is good. However, parameter descriptions are sparse or missing entirely. get_company_data and list_files have empty input schemas ({}), violating the requirement that every parameter needs a description. Descriptions exist but are lengthy (200+ chars) and lack clarity on when to use each tool vs. alternatives. No output schemas documented. Error handling guidance is absent. The server reads from and writes to Feishu tables, but the tool interface does not match the chat data model, agents must know table names and field mappings rather than working with natural language.
Attach a file as evidence/attachment to a record in a table. Links a file token to a record's attachment field.
Read department tables and return field definitions, records, and automatic summaries (sum for numeric fields, count for records, latest for dates). Dates unified to YYYY-MM-DD format. For CEO (company-wide), merges all departments.
Recursively list files in the department's Feishu storage folder (up to 3 levels deep). Returns file names, types, tokens, and nested folder contents.
Write a record to a department table. Automatically converts field types: dates in YYYY-MM-DD format to Feishu timestamps, numbers to float. Skips unrecognized fields to avoid API errors.
Read file contents. Supports PDF (via pdftotext), scanned PDFs/images (via tesseract OCR), and Feishu native documents (docx/wiki via lark-cli markdown). Returns up to 15000 characters; longer files are truncated with a note.
get_company_data and list_files have empty input schemas ({}). This prevents LLMs from understanding what parameters are available or required.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., record_id, file_token) without knowing the response structure. This violates the pattern:tool requirement.
Descriptions are 200+ characters and lack clarity on when to use each tool. get_company_data description mentions 'CEO (company-wide), merges all departments' but does not explain how to invoke this behavior or what parameter controls it. Descriptions should be 50-200 chars and answer WHAT, WHEN, and WHAT IT RETURNS.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
No error handling guidance. If log_record fails due to invalid field type or missing table, the tool returns an error but does not tell the LLM what to do next (retry, ask user, call list_files first). This violates pattern:recovery-guide.
Tool interface requires knowledge of internal table names and field mappings (e.g., 'log_record' requires 'table' and 'data' object with field names). This does not match the chat data model, users say 'log a sale' not 'write to sales_records table with fields [amount, date, customer_id]'. Agents must infer or discover schema.