Loading ToolBench
Yet Another Repository MCP - A Model Context Protocol server for accessing and searching code repositories with OAuth 2.1 authentication and repository management
YARMCP is a code repository inspection server with 4 tools for listing repos, retrieving metadata, reading files, and searching code. Tool names follow verb_noun convention well (list_repos, get_repo_info, read_file, search_code). Descriptions are present and moderately informative (80-180 chars), exceeding the 10-char minimum but falling short of ideal LLM-optimized 50-200 char range. Input schemas are well-defined with types and descriptions for all parameters. However, output schemas are entirely undocumented, the server provides no details about what fields each tool returns, forcing LLMs to infer response structure. Error handling is basic; the codebase shows validation logic for paths and auth tokens but no evidence of actionable error messages that guide the LLM on recovery steps. The server implements robust security measures (path validation, auth middleware, PKCE support) but does not declare permission scopes or audit trails in tool definitions. Overall, the server is solidly above average for community implementations but lacks the output schema documentation and error recovery guidance expected of production tools.
Get detailed information about a specific repository. Returns metadata including URL, branch, last update time, and current commit.
List all available repositories in the registry. Returns repository names, descriptions, and last update times.
Read a file from a repository. Returns the file content as a string.
Search for code patterns in a repository using ripgrep. Returns matching lines with file paths, line numbers, and search metadata.
Output schemas completely undocumented. All four tools provide descriptions of what they return in prose form, but no formal JSON Schema is provided for responses. LLMs cannot reliably parse unstructured output and must infer field names, types, and nesting from informal English. This violates the pattern:response-shaper and mxe:strip-api-responses principles.
No pagination or result-limiting guidance beyond max_results parameter. list_repos() has no documented limit; a repository registry with hundreds of repos could exhaust LLM context. search_code() defaults max_results to 100, which is reasonable, but no guidance on pagination via offset or cursor for retrieving additional results.
Error handling lacks actionable recovery guidance. The codebase shows validation for paths and auth tokens, but tool descriptions provide no indication of expected error scenarios (e.g., 'repository not found', 'file not readable', 'invalid regex pattern'). LLMs cannot plan recovery without explicit error classification.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No permission scope declarations. Tools implement auth (bearer token, OAuth) but do not declare what permissions they require (e.g., 'read:repository', 'read:files'). This prevents least-privilege agent configurations and clear audit trails.
Tool composition lacks chaining support. get_repo_info() returns 'metadata including URL, branch, last update time, and current commit' but does not formally document whether it returns a field that read_file() or search_code() can use directly. If read_file() requires 'repo_id' but get_repo_info() only returns 'repo_name', the LLM must guess at field mappings.