Loading ToolBench
Node.js tool for generating and managing GitHub reports with MCP service. Provides GitHub repository data analysis, daily/weekly reporting, and AI-powered insights via Model Context Protocol.
This MCP server has significant definition quality issues. Of 5 tools, all lack meaningful parameter descriptions despite having basic schemas. Tool descriptions are present but minimal (10-30 chars), well below the 50-200 char baseline for A/B grade tools. No output schemas are documented anywhere in the visible code. Error handling is absent, tools return raw API responses or errors with no recovery guidance. The code shows basic MCP registration but no evidence of validation, error classification, or composition patterns. Most critically, tool descriptions lack actionable context about WHEN to use each tool or WHAT it returns, forcing LLMs to guess.
使用 AI 对仓库数据进行智能分析
生成今日 GitHub 仓库活跃度报告
生成本周 GitHub 仓库活跃度报告
获取 GitHub 仓库的历史数据
发送消息到飞书群
All parameter descriptions missing or trivial. 'repo' param in get_repo_data says '仓库名称（可选，不提供则返回所有仓库数据）' (Chinese: 'repo name (optional, if not provided returns all repo data)'), LLMs cannot parse Chinese descriptions reliably, and this is the ONLY description provided. The 'question' param in ai_analysis and 'message' param in send_feishu_message lack ANY description in the visible schema.
Tool descriptions are 10 - 30 characters, far below the 50 - 200 char baseline for B-grade tools. 'get_repo_data' = '获取 GitHub 仓库的历史数据' (~16 chars in English: 'Get GitHub repo history data'). These provide no context on WHEN to call the tool, WHAT it returns, or HOW it differs from ai_analysis. LLMs cannot select tools effectively with such terse descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 39 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 26 | - | v1 |
No documented output schemas. The visible code shows tools like dailyJob() returning a string report, generateAnalysis() returning an OpenAI response, and sendFeishuMessage() returning undefined. The MCP tool_result does not specify what fields are returned, their types, or structure. LLMs cannot plan downstream calls or validate outputs.
No error handling or recovery guidance. fetchRepoStats() calls GitHub API with no try-catch or timeout. If the API returns 403 (rate limit), 404 (repo not found), or hangs, the entire tool fails with a raw error. No actionable guidance for the LLM (e.g., 'Repo not found. Try search_repos() or check spelling.').
Tool 'ai_analysis' description does not clarify that it requires OpenAI API credentials (API_KEY, API_BASE_URL). If these env vars are missing, the tool silently fails. No dependency hint or prerequisite check.
Parameter 'repo' in get_repo_data is optional with unclear behavior. Description says 'returns all repo data' if omitted, but the schema has no properties defined, and no enum or constraint on the repo string (e.g., 'must be owner/repo format'). LLMs will pass arbitrary strings without validation.
Tools generate_daily_report and generate_weekly_report have empty input schemas (no properties). This is acceptable for no-argument tools, but the descriptions do not explain what data they operate on (which repos, what date range, where data is stored). An LLM cannot predict whether calling this tool twice on the same day returns the same or different results, or whether it has side effects.
send_feishu_message declares risk=WRITE but has no confirmation/dry-run option and no guidance on failure recovery. If the Feishu webhook URL is invalid or network fails mid-send, the agent has no way to know if the message was delivered. No idempotency key or deduplication.
Tool names use both English (get_repo_data) and Chinese descriptions. The MCP interface should be exclusively English to work with LLMs trained primarily on English. Chinese descriptions reduce clarity and may not render correctly in all client UIs.