MCP Tool Auditor
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| audit_toolA | Audit a single MCP tool description for LLM reliability. Returns a 0-100 quality score, list of detected smells (vague purpose, missing usage guidelines, opaque params, etc.), and concrete fix suggestions. Use this before publishing any MCP server. |
| rewrite_tool_descriptionA | Rewrite a weak tool description into a high-quality, LLM-optimized version that follows current best practices (clear purpose, usage guidelines, parameter hints, limitations). Returns the improved description ready to paste into your MCP server. |
| audit_tool_listA | Audit an entire list of tools at once. Detects overcrowding (too many tools hurt accuracy), ranks each tool by quality score, and flags the worst offenders. Research shows accuracy drops below 90% when weaker models see more than 10-15 tools. |
| get_best_practicesA | Return the current checklist of MCP tool-description best practices derived from research (2026 papers + real-world agent testing). Use this as a reference when writing new tools. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Audit_tool and audit_tool_list overlap in purpose (auditing descriptions) but are clearly separated by scope (single vs. list). Rewrite and best practices are distinct. The descriptions make the boundaries clear, so confusion is unlikely.
All tool names follow a consistent verb_noun pattern in snake_case (audit_tool, rewrite_tool_description, audit_tool_list, get_best_practices). No mixed casing or stylistic deviations.
Four tools is well-scoped for the server's purpose. Each tool addresses a distinct step in the auditing workflow: reference, single audit, batch audit, and rewrite.
The core workflow is covered: get best practices, audit individual or list, and rewrite weak descriptions. A minor gap is lack of a validation/apply tool after rewriting, but the existing set supports the main use case effectively.