Loading ToolBench
MCP server for StackMap — the curated map of the open-source AI stack. Search 344 human-reviewed repos across 21 topics, 817 typed relationships (complements / alternative / built_with), and the written why behind every connection.
StackMap MCP demonstrates solid tool design with clear naming (verb_noun pattern), comprehensive descriptions (150-250 chars each), and well-structured input schemas using Zod. All 5 tools are explicitly registered with types and descriptions. Output is consistently formatted as markdown cards with structured relationships. However, output schemas are not formally documented in the tool definitions, and error handling lacks recovery guidance. Parameter descriptions are good but could be more prescriptive about constraints and formats.
Describe what you are building; get a starter stack assembled from the curated map — seed repos matched to your description, expanded through human-reviewed "pairs well with" edges, every pick carrying the curator's written why. Deterministic composition over curated data (no LLM in this server) — treat it as a strong draft for your own judgment.
Given repos you already use, suggests what pairs well next — curated complements ranked by curator confidence, each with the written why.
Human-reviewed alternatives for a repo — same job, different tool — each with the written "when to pick which".
Full StackMap entry for a repo: summary, the opinionated curator note (including when NOT to use it), and every typed, human-reviewed relationship with its written why.
Search 200+ curated open-source AI/agent repos by keywords. Matches name, summary, curator note and topics. Returns ranked matches with the human-written "when to use it (and when not)".
Output schemas not formally documented. Tools return markdown text via text() helper, but the structure of returned fields (repo name, stars, curator_note, relationships) is implicit in the card() function, not declared in tool definitions. LLMs cannot plan downstream operations without knowing the response structure.
Error responses lack recovery guidance. When a slug is unknown, the tool returns 'Unknown slug "X". Use search_catalog to find it.' but does not provide actionable next steps or available alternatives. Per pattern:recovery-guide, errors should guide the LLM toward resolution.
Parameter 'limit' in search_catalog lacks description of default behavior. The schema shows 'optional' and 'default 8', but the description does not state what happens if omitted. Per pattern:tool-description, every parameter needs explicit guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
continue_stack tool definition is truncated in source (ends mid-function at 'sor'). Cannot fully assess error handling, output structure, or parameter validation for this tool. Code review required.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) declared. All 5 tools are read-only and idempotent (they query a static catalog), but this is not signaled to the MCP client. Per current spec (2026-07-28), tool annotations enable client-side optimization and safety checks.