Loading ToolBench
MCP server for deploying live HTTPS websites in seconds. Instant subdomains ($1 USDC) or custom .xyz domains ($10 USDC) on Base chain.
The server has 7 well-named tools with reasonable descriptions and mostly complete parameter schemas. However, there are significant gaps in error handling guidance, output schema documentation, and parameter constraint enforcement. The deploy_site tool has the most complete definition with 13 parameters and clear descriptions. Several tools lack sufficient detail about expected outputs and error recovery paths. Naming is generally strong (verb_noun pattern), but descriptions could be more explicit about when to use each tool vs alternatives.
Check if a custom domain name is available for registration via Porkbun. Rate limited to 1 check per 10 seconds. For instant subdomains, no pre-check is needed.
Check the status of a SiteLauncher order by transaction hash. Useful for custom domain orders that take time to complete (DNS propagation, SSL setup).
Deploy a website via SiteLauncher. Requires a USDC payment transaction hash on Base chain. The agent must send 1 USDC to the SiteLauncher wallet BEFORE calling this tool.
Check how many custom domain registrations are available today. Porkbun limits to 10 registrations per day.
Check SiteLauncher service health and whether dry_run mode is active.
List available parent domains for instant subdomain deployment.
List all websites owned by a specific wallet address.
Output schemas are not documented. No tool explicitly declares what fields the response contains. LLMs cannot plan downstream tool calls or extract necessary IDs without knowing response structure.
Error handling provides no recovery guidance. All tools catch errors and return text responses, but do not indicate whether errors are retryable, user-fixable, or fatal. An LLM receives 'API error 429' with no context on what to do next.
deploy_site description does not warn that this is an irreversible, payment-backed operation. Should include dry-run capability or explicit confirmation semantics. Currently reads like a simple info call.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 9 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 61 | - | v1 |
check_availability and domain_capacity lack context on rate limits and constraints. The description mentions '1 check per 10 seconds' and 'Porkbun limits to 10 per day', but does not explain what happens if the limit is exceeded or when it resets.
list_domains and domain_capacity have empty or trivial input schemas ({}). While valid, they provide no validation anchors and suggest the tools may be discovery-only with no parameters. If they are purely read-only, this is acceptable but should be explicitly noted.
deploy_site parameter 'tx_hash' is required but description does not explain the dependency: agent must first send USDC payment, obtain hash, then call deploy. This multi-step sequencing is not discoverable from the tool definition alone.
No input validation or constraint documentation for string parameters. 'site_name' could be any string, but likely has length/character restrictions. 'primary_color' is documented as hex but no pattern validation is visible.
check_status and list_sites descriptions do not explain when results might be empty or delayed. If a deployment is in-progress, does check_status block or return partial data? This impacts agent retry logic.