Skip to main content
Glama
Sign In
Site Audit MCP Server

Site Audit MCP Server

by steadfeed-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Website tech-stack detector

detect_tech_stack
Idempotent

Identify CMS, JavaScript frameworks, analytics, marketing tags, and CDNs from public URLs and response headers to understand a site’s technology stack.

Instructions

Detect CMS, JavaScript frameworks, analytics, marketing tags and CDNs from public HTML and response headers, using curated fingerprints.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "urls": "<urls>"
    },
    "name": "detect_tech_stack"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlsYesPublic http(s) URLs of the homepages or pages to check (1-50).
dryRunNoPreview with built-in sample data; no website is contacted and the cost is minimal.
maxCostUsdNoOptional hard cap in USD for this call. The underlying Actor stops when the cap is reached. Minimum 0.05 (the Apify per-run minimum). Default: a small amount computed from the number of URLs, never below 0.05.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare openWorldHint=true, idempotentHint=true and destructiveHint=false, so the outbound-fetch and repeatability profile is largely covered structurally. The description adds methodology context ("curated fingerprints"), which explains why results are heuristic rather than exhaustive, but it says nothing beyond annotations about cost exposure or how the scan behaves across the 1-50 URLs.

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?

A single front-loaded sentence naming the verb, the detectable technologies and the data sources, with no filler. It is tightly written, though its density means the source constraint ("public HTML") is easy to skim past.

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

Completeness3/5

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

With three fully documented parameters and a clear read-mostly profile this is close to complete, but there is no output schema, so the description is the only place an agent could learn the shape of the result (per-URL detections, confidence, evidence). It also omits that the call consumes credits, a material fact for a paid scan invoked over up to 50 URLs.

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

Parameters3/5

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

Schema description coverage is 100%, so urls, dryRun and maxCostUsd are each fully documented in the schema, including the 1-50 limit, the 0.05 USD Apify minimum and the default cost heuristic. The description contributes no additional parameter meaning, which is the expected baseline when the schema does the work.

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

Purpose4/5

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

Uses a specific verb ("Detect") with an enumerated resource set (CMS, JavaScript frameworks, analytics, marketing tags, CDNs) and names the evidence source (public HTML and response headers). An agent can tell this is a technology-fingerprinting scan rather than a performance or accessibility audit, but the description never explicitly contrasts itself with the sibling audit_* tools.

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 phrase "from public HTML and response headers," which signals that reachable, publicly served pages are required. There is no explicit when-to-use statement, no exclusion (e.g., authenticated or non-HTML targets), and no pointer to a sibling tool for adjacent needs such as speed or accessibility.

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