Loading ToolBench
Multi-modal code search MCP server: text search (Hound), symbols (tree-sitter), and future semantic search. Supports both stdio and HTTP transport modes.
Hound MCP demonstrates solid tool design with 7 well-scoped read-only and one write operation. All tools have proper JSON Schema input definitions with typed parameters and descriptions. Tool names follow verb_noun conventions (hound_search, hound_repos, hound_file_context). Most descriptions are concise and action-oriented (range: 72-210 chars). However, output schemas are not explicitly documented in the source code provided, and several parameter descriptions lack detail about expected formats, ranges, or constraints. Error handling implementation is not visible in the sampled code. The symbol search tool demonstrates sophisticated pattern support (wildcards), but documentation of advanced features could be clearer.
Get extended context around a specific line in a file. Useful for understanding code around a search match.
Get comprehensive documentation and usage guidance for CodeHound MCP tools. Call with no arguments for full docs, or specify a topic: overview, search, symbols, context, repos, stats, tips.
Index repositories for symbol search. Fetches source files from Gitea and extracts symbols using tree-sitter. Run this before using hound_search_symbol to populate the index.
Get repository statistics including file counts, line counts, and language breakdown.
List all repositories indexed by Hound code search. Returns repository names and URLs.
Search code across all indexed repositories using regex patterns. Returns matching files and lines with deep links.
Output schemas not documented. Tool descriptions omit what fields are returned and their types, forcing LLMs to guess about response structure and limiting their ability to chain tools together effectively.
Parameter constraints are incomplete. 'limit' parameters (hound_search, hound_search_symbol) lack min/max bounds. 'contextLines' in hound_file_context has no range. Parameter descriptions do not specify numeric limits or format expectations.
Error handling and recovery guidance not visible in provided code. Tool descriptions do not explain what errors might occur, how to interpret them, or what the LLM should do next on failure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 67 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 33 | - | v1 |
Search for code symbols (functions, classes, methods, interfaces, types) by name using tree-sitter AST parsing. Supports wildcards (* and ?).
Parameter 'repos' (hound_search, hound_search_symbol) uses comma-separated string instead of array type. This is harder for LLMs to construct correctly and wastes tokens explaining the format. Should use type: 'array' with items: {type: 'string'}.
The hound_index_repos tool description states 'If omitted, indexes all repos from Hound' but does not clarify the performance impact or expected runtime of this operation, which could be significant.
hound_search_symbol parameter 'kind' has no enum constraint. Free-form string invites invalid values. Should define valid kinds (function, class, method, interface, type, etc.) as an enum.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. While most tools are clearly read-only, the write operation (hound_index_repos) should be explicitly marked as non-idempotent to warn agents about retry behavior.