Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

web_techstack

Detect what a public website is built with by fetching its URL and fingerprinting its frameworks, CMS, analytics, CDNs, and server headers.

Instructions

Tech stack — detect what a website is built with. Fetches a public URL and fingerprints the web technologies it is built with — a BuiltWith / Wappalyzer-style detector. Returns a list of detected technologies, each with its categories, a confidence (high, medium, low), an optional version, and the evidence that matched. Covers JavaScript frameworks and libraries (React, Vue.js, Angular, Svelte, jQuery), web frameworks / static site generators (Next.js, Nuxt.js, Gatsby, Remix, SvelteKit, Astro, Hugo), CMS and website builders (WordPress, Drupal, Joomla, Ghost, Wix, Squarespace, Webflow), e-commerce (Shopify, WooCommerce, Magento, BigCommerce), analytics, ad pixels, and tag managers (Google Analytics, Google Tag Manager, Meta Pixel, LinkedIn, Bing, TikTok/Pinterest/Reddit pixels, Segment, Hotjar, Microsoft Clarity), CDNs, UI frameworks and fonts, payments (Stripe, PayPal, Klarna), live chat, marketing automation, A/B testing, consent management, CAPTCHAs (reCAPTCHA, hCaptcha, Turnstile), video, and search. It also inspects response headers to identify the web server (nginx, Apache, IIS), the CDN / hosting provider (Cloudflare, CloudFront, Fastly, Vercel, Netlify), and the server-side language / framework (PHP, ASP.NET, Ruby on Rails, Django, Laravel, Express). Results are directional, not exhaustive. The render fetch strategy is one of browser (headless browser that executes JavaScript — the default, so client-injected scripts like analytics, tag managers and pixels are detected), auto (HTTP, escalating to a real browser only when blocked or JS-rendered), or http (HTTP only, no JavaScript — fastest, but sees only the server HTML); defaults to browser. Only public pages are supported; respect each site's terms of use and robots directives. Also returns unmatched_evidence (when present) — third-party script/stylesheet host domains and a <meta generator> value the detector saw on the page but doesn't yet have a named signature for; useful for spotting a vendor worth requesting coverage for. is_infrastructure flags a URL whose host looks like backend CDN/DNS/cloud-vendor infrastructure rather than a real, human-navigable website. reachable is false only when the target could not be fetched at all (even after an automatic www./plain-HTTP retry) — technologies may still be partially populated from DNS-based signals alone in that case, and failure_reason explains what happened.

Input Schema

NameRequiredDescriptionDefault
requestYesTarget URL (and optional render strategy)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.17.5
    • addedInput schema / properties / request / properties
      Added value: +{
+  "render": {
+    "enum": [
+      "browser",
+      "auto",
+      "http"
+    ],
+    "type": "string"
+  },
+  "url": {
+    "type": "string"
+  }
+}
    • addedInput schema / properties / request / required
      Added value: +[
+  "url"
+]
  2. Addedv1.5.0

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so well: it states the default render strategy (browser), the escalation behavior of auto, the automatic www./plain-HTTP retry, that technologies may be partially populated from DNS signals when reachable=false, and that failure_reason explains the failure. It also discloses the public-pages-only constraint and the 'directional, not exhaustive' limitation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded correctly with the purpose, but the middle is a sprawling vendor enumeration (React, Vue, Angular … Turnstile, video, search) that is informative yet far longer than needed to convey coverage. The paragraph-sized block buries the useful edge-case semantics (reachable, is_infrastructure) at the end.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must document returns — and it does: technologies with categories/confidence/version/evidence, plus unmatched_evidence, is_infrastructure, reachable and failure_reason. For a single-parameter detector with nested output, nothing an agent needs to call or interpret it is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema names url and render, but it does not explain what each enum value does. The description adds real meaning: browser executes JavaScript (so client-injected scripts are seen), auto escalates only when blocked, http is fastest but sees only server HTML, and browser is the default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource — 'detect what a website is built with' / 'fingerprints the web technologies' — and the BuiltWith/Wappalyzer analogy pins the concept immediately. No sibling in the list (web_scrape, web_capabilities, datasets_techstack_*) does the same job, so an agent can select this without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied by the purpose; there is no explicit 'use this instead of web_scrape / web_capabilities when…' routing, nor when-not conditions. The render-strategy tradeoffs (browser vs auto vs http) are useful operational guidance but live at the parameter level rather than addressing tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools