Loading ToolBench
MCP server for the Madrileno auction platform, providing tools to query repository metadata, module information, source code, and change history anchored to a specific Git commit
This Scala MCP server provides 6 well-defined read-only tools for exploring a Madrileno project repository. Tool names follow verb_noun conventions and are action-oriented (madrileno_overview, madrileno_module, madrileno_doc, madrileno_source, madrileno_changes, madrileno_diff). All tools have non-empty descriptions ranging from 70-140 characters. Input schemas are explicit with proper JSON Schema typing via Scala case classes derived with io.circe.Codec.AsObject and Schema. Parameter descriptions are present and technically detailed. However, output schemas are not documented in tool definitions, descriptions could be more LLM-optimized for selection context, and error handling lacks recovery guidance. The server demonstrates solid engineering (input validation, pinned git refs for reproducibility, shadow clone management) but misses some production-grade patterns around error messaging and output documentation.
List files changed between two commits (defaults to since=origin/main or pinned ref, and target=pinned ref)
Get a diff between two commits (defaults to since=origin/main or pinned ref, target=pinned ref); format may be 'unified' (default), 'stat', or 'names-only'
Read the ScalaDoc comment for a public definition, identified by simple name (case-class, object, trait, def, etc.)
List files in a Scala module under src/main/scala/madrileno/<name>
Get an overview of the Madrileno project: repository URL, pinned commit, and package name
Read source code of a file, identified by relative path from repo root (e.g. src/main/scala/madrileno/user/domain/User.scala)
Output schemas are not documented. Tool definitions show input schemas (case classes) but provide no schema documentation for return types. LLMs cannot plan downstream calls or extract required fields without knowing the output structure.
Error messages lack recovery guidance. The code validates inputs and produces error messages (e.g., 'name must match [A-Za-z0-9_-]+'), but responses do not suggest next steps when failures occur. Pattern requires: 'Try search_users() first' or 'Available options: ...'. LLM cannot self-correct without actionable error context.
Tool descriptions lack dependency hints and selection context. Descriptions state WHAT tools do but omit WHEN to use them relative to other tools. E.g., madrileno_doc does not explain 'Call madrileno_module first to discover available definitions.' This forces LLMs to reason about sequencing without guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | 2026-07-28+ | v2 |
No output pagination or result limiting documented. Tools like madrileno_changes and madrileno_diff may return large diffs or file lists without stated limits. If a module has 1000 files, does madrileno_module cap results? Without pagination tokens or limits stated in descriptions, LLMs risk context exhaustion.
madrileno_doc parameter 'name' is ambiguous. Description says 'definition name to look up' but does not clarify: Must it be a fully qualified name (e.g., 'com.example.User')? A simple name (e.g., 'User')? A method signature (e.g., 'User#apply')? LLM cannot reliably construct valid lookups.