Loading ToolBench
Zero-config domain availability MCP for Claude & ChatGPT. AI-powered suggestions via Qwen 7B. RDAP → GoDaddy → WHOIS fallback chain with premium/auction detection. Stdio + HTTP transports.
Domain-search-mcp has 12 tools with descriptions and schemas visible in src/toolset.ts and tool-specific files. All tools declare input parameters with types and descriptions. However, critical gaps undermine quality: (1) output schemas are NOT documented anywhere, tools return unspecified structures that LLMs cannot plan around; (2) descriptions are generic and lack actionable guidance for when/why to use each tool; (3) no error handling patterns visible, tools will fail silently or with opaque errors; (4) parameters lack constraints (enums, ranges, regexes), LLMs can pass invalid values without self-correction; (5) several tools operate on overlapping domains (suggest_domains, suggest_domains_smart, hunt_domains, name_project) without clear differentiation. The baseline for fair (C-grade, 60-69) is 'descriptions present but could be better' + 'schemas incomplete' + 'limited error handling', this server meets that exactly. Average per-tool score is 58.
Check AI inference endpoint health and capabilities
Extract context from projects for domain suggestions
Check many domains at once efficiently
Check social handle availability
Compare pricing across registrars
Find domains about to expire (federated cache)
Find valuable domains for investment
Generate project names based on description and constraints
Output schemas not documented. LLMs cannot see what fields tools return, blocking downstream parameter mapping and forcing guesswork about result structure.
Descriptions under 100 characters and lack actionable 'when-to-use' guidance. E.g., 'Check availability across multiple TLDs' does not explain when to call search_domain vs bulk_search. LLMs cannot distinguish overlapping tools.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Check availability across multiple TLDs
Generate available name variations
AI-powered domain suggestions with Qwen 2.5-7B
Get TLD information and recommendations
No enum constraints on 'tlds' (array), 'platforms' (array), 'style' (string), 'criteria' (object). LLMs will hallucinate invalid values like tlds: ['xyz', 'invalid-tld']. Should declare valid TLD list, platforms list, style options explicitly.
No documented error handling or recovery guidance. Tools will fail (network error, API rate limit, invalid input) but provide no actionable error message telling LLM what to do next.
Tool name collision risk: suggest_domains, suggest_domains_smart, hunt_domains, name_project all generate domain/name suggestions but differ in method (rule-based, AI-powered, investment-focused, project-focused). Descriptions do not clarify which to use when, forcing LLM to guess.
'criteria' parameter in hunt_domains is a bare object with no documented shape. LLMs cannot construct valid criteria objects without seeing an example or schema of what 'length', 'pattern', etc. mean.
'constraints' parameter in name_project is also a bare object. Same issue as criteria, no schema, no field definitions, no valid values documented.
No pagination parameters on tools that return lists (suggest_domains, hunt_domains, expiring_domains, check_socials). If results are large, LLMs have no way to fetch next page, response may be truncated silently, wasting context.
ai_health tool accepts no parameters and has minimal documentation. Unclear what 'health' means, latency? Model availability? Uptime? LLM cannot decide when to call it.
No indication which tools are read-only vs. which modify state (all marked READ_ONLY here, but verify in code). If some tools have side effects (e.g., reporting domains to cache backend), agents need to know which are safe to retry.