Loading ToolBench
NoStale MCP server — search_wiki/get_document/list_traceability/list_stale_documents/ask_wiki over Streamable HTTP
NoStale MCP server has 5 tools with clear verb-noun naming (search_wiki, get_document, list_traceability, list_stale_documents, ask_wiki). All tools have descriptions (avg ~100 chars, within baseline 34-392 range). Input schemas are present with types and descriptions for all parameters. However, output schemas are NOT documented, critical gap for LLM planning. Parameter descriptions are adequate but lack explicit constraints (e.g., 'limit' has min/max in schema but no format guidance in description text). Error handling is minimal, no recovery guidance or actionable error messages visible in source. Tool composition is sound (each does one thing), but ask_wiki's rate-limiting caveat is mentioned in description without structured guidance on retry behavior.
Synthesized, cited answer over the wiki (calls the configured LLM). Prefer search_wiki when you can compose the answer yourself — this is rate-limited.
Fetch the full content of one generated PRD/TDD. Defaults to approved documents only.
List doc_artifacts currently stale/needs_review/regenerating for a project — useful for documentation maintenance.
List traceability_links rows — feature ↔ TDD ↔ PRD ↔ source files.
Hybrid (lexical+vector) search over the ingested codebase/docs corpus. No LLM call — cheap, safe to call often.
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., what fields does search_wiki return? Is there pagination?). Critical for agent reasoning.
Error handling lacks recovery guidance. No visible error classification (retryable vs user-fixable vs fatal) or actionable error messages. ask_wiki mentions rate-limiting but provides no structured guidance on retry behavior or fallback.
Parameter descriptions lack explicit format/constraint guidance. 'limit' has min/max in schema (1-50) but description does not state the range. LLMs cannot read JSON Schema constraints, they rely on description text.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
list_traceability and list_stale_documents lack pagination parameters (limit, offset, cursor). Large result sets will blow context window. Baseline pattern requires pagination for list tools.
Tool descriptions do not explain WHEN to use each tool vs alternatives. E.g., search_wiki vs ask_wiki distinction is mentioned ('Prefer search_wiki when you can compose the answer yourself') but not in search_wiki's description. Agents need explicit selection guidance.