SiteVerdict

Official

by siteverdict

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Detect website technology stack

detect_tech_stack

Read-only

Identify technologies behind one or many websites from public signals, returning CMS, ecommerce, analytics, hosting, CDN, email and DNS providers with confidence scores and filters by technology.

Instructions

Detects the technology stack of one or many websites from public signals: homepage HTML, script/stylesheet URLs, HTTP headers, cookie names, public DNS (MX, SPF, DMARC, NS, CNAME), TLS issuer and robots.txt. Returns per site the technologies found (category, confidence 0-100, version, evidence) plus convenience fields cms, ecommerce, analytics, advertising, hosting, cdn, emailProviders and dnsProvider. Covers 1,000+ technologies (CMS, ecommerce and Shopify apps, analytics, tag managers, ad pixels, consent tools, CRM, chat, payments, CDN, hosting, email providers). Filters build lists such as "Shopify stores not using Klaviyo" (onlySitesUsing / excludeSitesUsing). mode "http" (default) is fast and cheap; "browser" also catches tags injected by tag managers. Respects robots.txt and never bypasses bot protection: blocked sites return status "blocked" and are not charged. It analyses only the sites you pass; it cannot list every site using a technology. Runs an Apify Actor on the caller's own Apify account (billed by Apify pay-per-event, capped per run).

Input Schema

Name	Required	Description	Default
`mode`	No	"browser" renders in headless Chrome (more tags, costs more). Prefer http.	http
`urls`	Yes	Domains or URLs, e.g. ["example.com", "https://shop.example.co.uk"]
`checkDns`	No	Look up MX/NS/SPF/DMARC records to detect the email and DNS providers.
`checkTls`	No	Read the TLS certificate issuer and expiry date.
`matchAll`	No	onlySitesUsing must ALL match (default: any).
`extraPaths`	No	Extra paths per site, e.g. ["/pricing", "/cart"]
`minConfidence`	No	Drop detections below this confidence (0-100).
`onlyCategories`	No	Keep only these categories, e.g. ["Booking & scheduling"]
`onlySitesUsing`	No	Keep only sites using these technologies, e.g. ["Shopify"]
`includeEvidence`	No	Include evidence strings (more tokens).
`excludeSitesUsing`	No	Drop sites using these, e.g. ["Klaviyo"]

Output Schema

Name	Required	Description
`run`	Yes
`tool`	Yes
`items`	Yes	Result records (trimmed for context). Records often carry a recordType discriminator.
`notes`	Yes
`dryRun`	Yes	true = built-in SAMPLE data from this server, NOT a real lookup
`status`	Yes	"running" = still working; call get_run_results with run.runId later
`summary`	Yes
`truncated`	Yes	true = more records exist than are included here (see datasetUrl)
`datasetUrl`	No
`disclaimer`	No
`itemsTotal`	Yes
`sampleData`	Yes	true = the Actor returned fictional sample rows (e.g. no credentials configured); never present as real

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.1Oct 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond readOnlyHint/openWorldHint, it discloses cost behavior (Apify pay-per-event, capped per run), that blocked sites are not charged, that robots.txt is respected and bot protection is never bypassed, and that includeEvidence costs tokens. Those are exactly the operational facts an agent needs before spending money on a run.

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

Conciseness4/5

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

The capability statement is front-loaded and the paragraph is dense with operational facts rather than filler. The middle sentence enumerating output convenience fields is somewhat list-heavy, but it is scoped to a single paragraph and nothing is redundant.

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?

For an 11-parameter, open-world, billed scrapter-style tool, the description covers inputs, output shape (even though an output schema exists), cost, rate/blocking behavior, and the hard capability limit. An agent has everything needed to decide and call correctly.

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%, so the baseline is 3; the description earns a bump by explaining how onlySitesUsing/excludeSitesUsing combine to build filtered lists and by framing mode as a coverage-vs-cost choice. It still doesn't add syntax or interaction detail for checkDns/checkTls/minConfidence beyond what the schema states.

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 ('Detects the technology stack of one or many websites') and immediately enumerates the exact signals used: homepage HTML, script/stylesheet URLs, headers, cookies, DNS records, TLS issuer, robots.txt. This is clearly distinguishable from siblings like check_domain_email_health or audit_tracking_consent, which cover narrower slices.

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

Usage Guidelines4/5

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

Gives concrete when-to-use guidance for the mode tradeoff ('http' fast/cheap vs 'browser' catches tag-manager-injected tags) and a when-not statement: 'It analyses only the sites you pass; it cannot list every site using a technology.' It also shows a real filtering workflow ("Shopify stores not using Klaviyo"). It does not name any sibling tool as an alternative, which keeps it short of a 5.

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

Deploy Server