Loading ToolBench
MCP server that turns a GitHub repo into ready-to-review release announcements (X/Twitter, Reddit, profile README, awesome lists, MCP directories) plus a publish-readiness checklist.
Three well-named tools with comprehensive descriptions (194 - 280 chars, above baseline 194 avg). All parameters have types and descriptions. Input schemas are complete with min/max constraints. Tool annotations present (readOnlyHint, destructiveHint, idempotentHint, openWorldHint). Error handling returns structured JSON with actionable messages. Main gaps: output schemas not formally documented in code; no pagination support despite tools returning potentially large results (README truncated at 12000 chars, but no limit stated for rootFiles or checklist items); no confirmation pattern for multi-step operations.
Gather a repository's facts (README, latest release notes, metadata) and return a complete writing brief: source material plus strict per-target writing instructions. The calling LLM then writes the final draft texts from this brief. Targets available: - x_post: X/Twitter announcement (Japanese + English, ~160 chars) - reddit_draft: understated Reddit post draft (English, title + body) - profile_readme_row: GitHub profile README table row - awesome_mcp_pr: awesome-mcp list entry + PR title/body - directory_listing: MCP directory (mcp.so etc.) descriptions + tags Args: - owner (string): GitHub user/org name - repo (string): repository name - targets (string[], optional): subset of targets; defaults to all five Returns: a Markdown brief. After calling this tool, write the requested draft texts following the brief's rules exactly. All output is draft-only for human review — never post anywhere automatically.
Run a pre-publication checklist against a public GitHub repository and report pass/warn/fail per item. Checks: LICENSE present (MIT expected), README present with setup instructions and usage examples, GitHub Release created, 3+ Topics set, About description set, .gitignore present. Args: - owner (string): GitHub user/org name - repo (string): repository name Returns: a Markdown checklist report plus structured JSON ({ repo, passed, total, items: [{id, label, status, detail}] }). Each failing item includes a concrete fix suggestion.
Fetch public information about a GitHub repository: description, topics, license, stars, latest release (tag + notes), README content, and root file list. Use this when you need raw facts about a repository before writing about it or checking it. Args: - owner (string): GitHub user/org name - repo (string): repository name Returns: structured JSON with repo metadata, latestRelease (or null), readme text (truncated at 12000 chars), and rootFiles. Errors: returns a clear message for unknown repos (404) and API rate limits (retry later or set GITHUB_TOKEN env var).
Output schemas not formally documented. Tools return structuredContent but no JSON Schema definition visible for response fields (repo metadata structure, readiness report format, brief structure). LLMs cannot reliably extract nested fields without explicit schema.
No pagination or result limits documented for list-like outputs. fetch_repo_info returns rootFiles array and README (truncated at 12000 chars), but no limit stated for rootFiles count or pagination support. Large repos could return unbounded arrays.
No confirmation or dry-run pattern for multi-target announcement generation. build_announcement_brief generates content for up to 5 targets (X, Reddit, GitHub, awesome-mcp, directory). Tool description says 'draft-only for human review, never post anywhere automatically', but no explicit confirmation step or dry-run mode in schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2025-06-18+ | v2 |
GitHub API rate limit handling relies on environment variable (GITHUB_TOKEN) but no tool parameter to override or provide token. Error message mentions 'set GITHUB_TOKEN env var', but agents cannot dynamically inject credentials at runtime.
Error responses are text-only. errorResult() returns { content: [{ type: 'text', text: 'Error: ...' }], isError: true } but no structured error classification (retryable vs user-fixable vs fatal). LLM cannot distinguish 'retry later' (rate limit) from 'user must fix' (invalid repo name).