Loading ToolBench
MCP server — search code, find libraries, and evaluate dependencies across all of GitHub, PyPI, and npm
fossick-mcp demonstrates solid tool design with clear naming (verb_noun pattern), comprehensive parameter descriptions, and well-documented schemas. All 7 tools follow consistent patterns and include detailed descriptions (avg 180+ chars). Parameters are well-typed with constraints. However, output schemas are not explicitly documented in the source code, and error handling guidance is minimal. Tool composition is excellent, each tool has a single responsibility and chains naturally (search_repos → repo_tree → get_file). No security issues detected (read-only operations, no secrets in params). Naming is precise and action-oriented.
Goto-definition: find where a symbol is defined in one repo or across all of GitHub. Queries GitHub's code-search index for files containing the symbol name, parallel-fetches candidate files, parses each with tree-sitter, and queries the AST for declaration nodes (class, function, struct, trait, interface, etc.) whose name matches exactly.
Read file content from one file in a GitHub repository. Returns full file with line numbers, supports line range slicing (start_line/end_line) and substring/regex match filtering with context lines. Truncates files over 500 lines unless a range or match is specified.
Check freshness and see recent releases. Lists repository tags and releases to determine if a library is actively maintained.
Browse a repository's layout and structure. Returns a tree view of files and directories in a repository.
Search code across GitHub repositories. Find real-world usage patterns with support for regex, boolean operators, and qualifiers like repo:, language:, path:.
Output schemas not documented in source code. While input schemas are comprehensive, return types and field structures are not explicitly defined, forcing LLMs to infer response structure.
Error handling lacks recovery guidance. Tools do not document what errors are retryable, what user actions are needed, or what to do if a search returns no results.
Pagination parameters (page, per_page) lack explicit constraints in descriptions. Max values are mentioned (100) but min values, default behavior, and total count return are not documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Search for packages on PyPI and npm by name. Direct package lookups when you already know the package name.
Search repositories by topic, stars, language, or trending. Discover libraries by querying GitHub's repository search index with optional sorting and filtering.
get_file tool accepts both line-range slicing and regex matching, but does not document mutual exclusivity or precedence rules. LLMs may pass conflicting parameters.
find_symbol 'kind' parameter is marked 'reserved for future use' but still exposed. This creates ambiguity, should LLMs pass it or omit it? Either remove or document current behavior.