Loading ToolBench
Model Context Protocol server for BuiltWith API integration
Server has well-structured tool definitions with explicit schemas, descriptions, and proper annotations. Both tools follow verb_noun naming (domain_lookup, technology_search) and include comprehensive parameter documentation. Output schemas are defined in DOMAIN_LOOKUP_OUTPUT_SCHEMA and TECHNOLOGY_SEARCH_OUTPUT_SCHEMA, which is above the community median. However, several parameter descriptions lack actionable constraint details (e.g., 'offset' has no explanation of format or how to obtain it), and error handling is minimal in the visible code. The server demonstrates good foundational quality but lacks depth in parameter guidance and error recovery patterns.
Get technology stack information for a specific domain
Find domains using a specific technology, via the BuiltWith Lists API. Supports filtering by additional required technologies, country, and recency, plus pagination for large result sets. Note: this requires a BuiltWith plan with list credits (Pro tier or above).
Parameter 'offset' in technology_search lacks actionable constraint description. The description states 'Pagination cursor. Pass the nextOffset value from a previous response...' but does not explain the format, required length, or what happens if an invalid offset is passed. LLMs cannot infer cursor format and may generate invalid values.
Error handling is not visible in the tools/call handler beyond a generic switch statement. No recovery guidance is provided for common failure modes (e.g., 'API key missing', 'quota exhausted', 'invalid domain format'). A bare error response gives the LLM nothing actionable, it should indicate whether to retry, ask the user, or try an alternative approach.
Parameter 'country' in technology_search accepts comma-separated ISO codes but lacks validation examples and error guidance. The description says 'e.g., "US" or "AU,NZ"', both are informal examples that LLMs may treat as the only valid options. Should replace with formal enum or clear validation rule and error handling for invalid codes.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | C | 62 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
technology_search description mentions 'requires a BuiltWith plan with list credits (Pro tier or above)' but no error message or permission check is visible in the code. If called without the required plan, the API will fail. The tool should detect this permission error and return guidance like 'This requires a Pro plan or above. Visit https://builtwith.com/plans to upgrade.'
Output schema for technology_search includes optional fields (locations, firstDetected, lastDetected, monthlySpend, skuCount, estimatedRevenue, socialFollowers, employeeCount, meta) that are not marked as required. The schema should clarify which fields are always present vs conditional on includeMeta=true or detailed=true. Without this, LLMs may assume fields exist when they do not, causing parsing errors.
No rate limiting or quota guidance is visible in the tool definitions. The technology_search tool may consume list credits rapidly, but there is no warning or rate-limit error handling. Agents in a retry loop could exhaust the user's quota. The description should warn about credit consumption and suggest batching or filtering to reduce calls.