Loading ToolBench
Feishu/Lark OpenAPI MCP Server - provides access to Feishu/Lark APIs through the Model Context Protocol
The server exposes only 1 tool: openplatform_developer_document_recall. While the tool has a description and basic input schema, critical quality gaps significantly limit its usefulness. The tool name does not follow verb-noun conventions (missing clear action verb), the description is generic and lacks actionable context, the input schema is minimal (single string parameter with no validation), and there is no visible output schema documentation. The tool appears to be a thin wrapper around a recall/search capability but does not provide guidance on what 'recall' means operationally, what fields are returned, pagination support, or error recovery paths. Code review shows the tool is implemented (src/mcp-tool/document-tool/recall/index.ts) but the actual implementation is not visible in the provided source, making it impossible to verify error handling, output structure, or whether the implementation matches the schema declaration.
Recall for relevant documents in all of the Feishu/Lark Open Platform Developer Documents based on user input.
Tool name violates verb-noun naming convention. 'openplatform_developer_document_recall' uses a noun-heavy structure without a clear leading action verb (e.g., search_, get_, retrieve_). LLMs rely on the leading verb to infer intent. A name like 'search_developer_documents' or 'recall_lark_documentation' would be immediately actionable.
Description is generic and lacks WHAT/WHEN/WHY context. 'Recall for relevant documents in all of the Feishu/Lark Open Platform Developer Documents based on user input.' does not explain: What format are results in? How many documents are returned? What does 'relevant' mean? When should the LLM call this vs. other tools? Is it paginated? Does it support filters? Description is 152 characters, within the acceptable range (p10=34, p90=392), but is uninformative.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 25 | - | v1 |
Input schema is minimal and lacks validation. Single parameter 'query' of type string with description 'user input' is far too vague. No constraints on length, no enum options, no pattern validation, no guidance on what constitutes a valid query. Baselines show avg param annotation is 72 chars; this is 11 chars. A production tool needs: required/optional, min/max length, example format, or accepted query syntax.
No output schema documented. The tool returns results but there is no visible documentation of the response structure, field types, or content. LLMs cannot plan downstream operations without knowing what fields to expect. Critical fields like document_id, title, url, relevance_score, etc., should be explicitly declared with types.
No pagination or result limiting documented. If the tool returns lists of documents, there is no visible limit, offset, page_size parameter, or indication of how many results are returned. Returning unbounded lists can exhaust context windows. Baselines show paginated results are standard in production tools.
No error handling guidance. If a query returns no results, or is malformed, or the service times out, there is no visible error categorization, recovery guidance, or actionable error messages. The tool declaration does not indicate retryable vs. fatal errors.
Tool implementation file is referenced (src/mcp-tool/document-tool/recall/index.ts) but actual implementation code is not provided in the source snippet. Cannot verify that the implementation matches the schema, that output structure is as promised, or that error handling is present. This caps per-tool score at 50 for tooling audit purposes.