Detect 50+ technologies on any website. CMS, JS frameworks, analytics, hosting, CDN, payments. Confidence scores and evidence.
Single tool 'website_detect_tech_stack' has a well-structured description (280+ chars) explaining WHAT it does, WHEN to use it, and what NOT to use it for. Input schema is present with proper type and description. Output schema is documented with example JSON showing structured response with technologies array, categories, and summary. Naming follows verb_noun pattern (detect_tech_stack). However, the tool lacks explicit parameter validation constraints (e.g., URL format regex), error handling guidance, and does not document what happens on invalid/unreachable URLs. Description is strong but could be more concise for LLM token efficiency.
Use this when you need to identify what technologies a website uses. Returns structured JSON with categorized detections, confidence levels, and evidence for each technology found. 1. technologies (array) -- each entry has name, category, confidence, evidence 2. categories detected: CMS (WordPress, Shopify, Wix, Webflow), JS Frameworks (React, Next.js, Vue, Angular, Svelte), CSS (Tailwind, Bootstrap), Analytics (Google Analytics, GTM, Facebook Pixel, Hotjar, Mixpanel), Hosting (Vercel, Netlify, AWS, Railway), CDN (Cloudflare), Payments (Stripe, PayPal), Support (Intercom, Crisp, Zendesk) 3. summary.totalDetected (number) -- count of technologies found 4. summary.categories (object) -- count per category Example output: {"technologies":[{"name":"React","category":"JS Framework","confidence":"high","evidence":"react-dom in bundle"},{"name":"Tailwind CSS","category":"CSS","confidence":"high","evidence":"tailwind classes in HTML"},{"name":"Vercel","category":"Hosting","confidence":"medium","evidence":"x-vercel-id header"}],"summary":{"totalDetected":8,"categories":{"JS Framework":2,"CSS":1,"Hosting":1,"Analytics":3,"Payments":1}}} Use this BEFORE sales outreach (to personalize pitch by tech stack), competitive analysis, or security audits. Essential for qualifying leads by technology fit and understanding competitor architecture. Do NOT use for full company data -- use company_enrich_from_domain instead. Do NOT use for SEO analysis -- use seo_audit_page instead. Do NOT use for website content -- use web_scrape_to_markdown instead.
No error handling guidance in tool description. Missing recovery hints for common failures (unreachable URL, timeout, invalid domain format). LLM cannot determine retry strategy or fallback actions.
URL parameter lacks format constraint. Description says 'e.g. https://example.com or example.com' but no regex pattern or validation rule is declared. LLM may pass malformed URLs (spaces, special chars, invalid protocols).
Output schema documented via example JSON only; no formal JSON Schema definition visible in source. Example shows structure but lacks type declarations, required fields, or field descriptions for downstream tool chaining.
Tool description is 280+ chars, approaching upper efficiency bound (1024 max). Consider condensing use-case guidance to 150-200 chars to reduce token overhead while preserving clarity.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2025-06-18+ | v2 |