Loading ToolBench
Multi-AI Rules MCP Server - One source of truth for AI coding rules across all AI assistants
CodingBuddy provides 7 tools with basic schemas and descriptions, but the definitions lack depth and clarity needed for reliable LLM usage. Tool names are reasonably descriptive (verb-noun format), but descriptions are sparse (most under 100 characters, below the 194-char baseline for A+ tools). Input schemas are present but minimal, only 1-2 parameters per tool with terse descriptions. No output schemas are documented. Error handling guidance is absent. Parameter constraints (enums, ranges) are not declared. The server operates on STDIO only, which is a hard transport penalty. Overall, this is a D-tier server with functional but incomplete definitions.
Get detailed profile of a specific AI agent
Get project configuration including tech stack, architecture, conventions, and language settings
Get skill content by name
List all available skills with descriptions
Parse workflow mode keyword from prompt and return mode-specific rules with project language setting
Search for rules and guidelines
Analyze the project and suggest config updates based on detected changes (new frameworks, dependencies, patterns)
No output schemas documented for any tool. Callers cannot know the structure of responses, whether fields are strings, arrays, objects, or nested. This violates the pattern:tool-description requirement and forces LLMs to guess or infer from experience.
Tool descriptions are consistently short (32-111 chars, baseline 194 chars p50). Descriptions lack WHAT/WHEN/WHY guidance. E.g., 'Get skill content by name' (23 chars) tells an LLM nothing about when to use this vs search_rules. Descriptions should be 50-200 chars and answer: What does it do? When should the LLM call it? What does it return?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 15 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Parameter descriptions are minimal and lack constraints. E.g., 'skillName' has a 26-char description with no enum of valid names, no format guidance, no error handling for invalid names. 'query' parameter in search_rules lacks min/max length, pattern, or pagination limits. Baseline: params should specify format, range, allowed values, and dependencies.
list_skills and similar listing tools lack pagination. No limit, offset, page_size, or next_cursor parameters documented. Baseline: list tools must support pagination to avoid context explosion. Without pagination, returning 500 skills blows the context window.
No error handling guidance. Tools do not document what to do if a skill is not found, if a project root is invalid, or if mode parsing fails. Baseline: errors should be actionable (e.g., 'Skill not found. Call list_skills() to see available skills.').
STDIO-only transport. Server is not remotely accessible and cannot be tested by hosted MCP clients (ChatGPT, Claude, Cursor). STDIO caps protocol readiness at 50/100 and makes the server unsuitable for production agent deployments. Migrate to HTTP or SSE.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools are marked READ_ONLY in the spec, but this is not reflected in MCP schema annotations. LLMs cannot distinguish safe vs unsafe operations from schema alone.