Loading ToolBench
The MarkdownLM MCP server defines 3 tools with explicit schemas and detailed descriptions. All tools have clear names starting with action verbs (query_, validate_, resolve_), comprehensive descriptions (ranging from 180-280 chars, within the production baseline of 194 avg), and properly typed input schemas. However, there are critical gaps: (1) NO documented output schemas for any tool, the rubric requires documenting return types for A+ tools; (2) parameters lack type constraints (enums, min/max) despite schema definitions; (3) descriptions are procedurally heavy but lack clarity on WHAT data is returned; (4) error handling guidance is minimal. The tools are well-intentioned (knowledge base queries, code validation, gap resolution) but lack production-grade output documentation and error recovery patterns.
MANDATORY: Call this tool before writing any code, proposing any pattern, or making any architectural or dependency decision. It queries this team's private knowledge base of documented rules, stack decisions, and architectural constraints. Do NOT rely on general knowledge — your team's rules override defaults. Returns the matching documented rules with their sources. If no documentation exists for the topic, a gap is automatically logged for the developer to review, and you MUST call resolve_gap next. The 'category' field is required — pick the single best-fit value from the allowed enum that describes the domain of your query.
Call this when query_knowledge_base returned no documented guidance for a decision you need to make. Logs the undocumented decision as a knowledge gap so the developer can review and document it. Returns how you should proceed based on the team's configured gap policy: "ask_user" = stop and ask the developer for a decision before continuing; "infer" = MarkdownLM has auto-resolved the gap, use the returned resolution value; "agent_decide" = proceed with your best judgement and document your reasoning. Do NOT call this if query_knowledge_base returned matching rules — it is only for genuinely undocumented decisions.
Call this after writing or editing any non-trivial function, module, or API endpoint. Checks the code snippet against this team's documented rules for the given category. Returns a pass/fail verdict plus a list of violations — each with the rule violated, the problematic location, and a concrete fix suggestion. Fix all violations before presenting the code to the developer. Do NOT skip this step even if query_knowledge_base returned no results — the validation engine runs a broader rule check.
No documented output schemas for any tool. LLMs cannot infer what fields to expect in responses (e.g., does query_knowledge_base return {rules: [], sources: []} or {matched: {}, gaps: []}?). This violates the pattern:tool requirement and forces LLMs to hallucinate field names.
Parameters lack formal constraints. The 'category' enum is properly defined, but numeric/string bounds are missing. E.g., 'query' parameter has no length limit guidance, and descriptions don't specify min/max for code snippets in validate_code.
Error handling is silent. Descriptions mention 'Returns a pass/fail verdict' and 'Returns how you should proceed' but provide zero guidance on failure modes: What if the API is unreachable? What if the knowledge base is empty? What should the LLM do? Violates pattern:recovery-guide.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 64 | - | v1 |
Descriptions are prescriptive ('MANDATORY', 'Do NOT rely on general knowledge') but lack clarity on response structure. The lengthy imperative statements (e.g., 'MANDATORY: Call this tool before...') consume tokens without explaining what the LLM will receive back.
No pagination or result limiting guidance. If a knowledge base query returns 500 matching rules, there's no documented max, no pagination parameters, no truncation mechanism.