mcp-digger has 10 tools with basic descriptions and some parameter documentation, but significant gaps prevent higher scores. Tool names follow verb_noun convention (dig-*), which is good. However, most tools lack detailed parameter descriptions, output schemas are not documented, and error handling guidance is absent. The server targets .NET/NuGet exploration, a narrow domain, but definitions don't guide LLMs on when to use each tool vs. alternatives. Descriptions average ~60 chars (below the 194-char baseline), and parameter annotations are sparse or missing entirely.

• Document output schemas for all tools. Example: dig-list should return {packages: [{name: string, version: string, description: string}], total: number}. This enables LLMs to chain tools correctly.
• Expand tool descriptions to 100 - 200 chars. Explain WHAT the tool does, WHEN to use it (vs. similar tools), and what it returns. Example: 'Get type signatures and method definitions for a package. Use this after dig-package-overview to explore specific APIs. Returns method names, parameters, and return types.'
• Add parameter descriptions for all inputs. Specify format (e.g., 'NuGet package name, case-insensitive'), constraints (e.g., 'max 256 chars'), and whether the parameter is required or optional. Example: 'packageName: Name of the NuGet package to inspect (required, case-insensitive, e.g., "Newtonsoft.Json")'.
• Add error handling guidance to tool descriptions. Document common failure modes and recovery steps. Example: 'If package not found, call dig-list to see available packages. If config is invalid, call dig-init to reinitialize.'
• For dig-file, clarify whether filePath is required or optional, and what happens if omitted. If optional, document the default behavior (e.g., 'returns all files in package' vs. 'returns error').