de en es ja ko ru zh

StackScan MCP Server

Name: StackScan MCP Server
Author: stackscan

Official

by stackscan

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

StackScan MCP-Server

Frag deinen Assistenten, was eine Website verwendet und wer dahintersteckt.

Ein Model Context Protocol-Server für die StackScan Tech Lookup API. Richte Claude, Cursor oder einen anderen MCP-Client darauf aus und du kannst Dinge fragen wie:

Worauf basiert example.com?
Wer steckt hinter vercel.com? Wo sind sie, welche Branche, was ist ihr LinkedIn?
Wie viele Websites nutzen Klaviyo, und in welchen Ländern?

Von Natur aus schreibgeschützt. Nichts hier schreibt in eines deiner Systeme.

Installation

Du benötigst ein StackScan-Konto. Melde dich an, öffne API Tokens im Dashboard, erstelle ein Token und kopiere deine Workspace-UUID von derselben Seite.

Claude Desktop (Erweiterung)

Lade stackscan.mcpb von der Releases-Seite herunter und ziehe es dann auf Einstellungen > Erweiterungen. Es fragt nach deinem API-Token und deiner Workspace-ID und installiert den Rest selbst.

Claude Desktop (manuelle Konfiguration)

Einstellungen → Entwickler → Konfiguration bearbeiten, dann füge hinzu:

{
  "mcpServers": {
    "stackscan": {
      "command": "npx",
      "args": ["-y", "@stackscan/mcp-server"],
      "env": {
        "STACKSCAN_API_TOKEN": "your-token",
        "STACKSCAN_TENANT_ID": "your-workspace-uuid"
      }
    }
  }
}

Starte Claude Desktop neu. Die Tools erscheinen unter dem Verbindungssymbol.

Claude Code

claude mcp add stackscan \
  --env STACKSCAN_API_TOKEN=your-token \
  --env STACKSCAN_TENANT_ID=your-workspace-uuid \
  -- npx -y @stackscan/mcp-server

Cursor, Windsurf und andere

Gleiche Form: command: npx, args: ["-y", "@stackscan/mcp-server"] und die beiden Umgebungsvariablen. Schau in der MCP-Dokumentation deines Clients nach, wo sich seine Konfigurationsdatei befindet.

Related MCP server: mcp-gtm-tech-stack-signal-scraper

Tools

Tool	Was es tut	Kosten
`check_credits`	Verbleibendes Guthaben und die Zuteilung dieses Monats	kostenlos
`lookup_company`	Das Unternehmen hinter einer Domain: Name, Branche, Stadt, Land, LinkedIn	1 Credit
`lookup_domain_technologies`	Technologien auf EINER Domain, vollständig: Kategorie und globale Nutzung für jede (`limit`, Standard 50, max 100)	1 Credit
`lookup_technology`	Wie viele Websites eine Technologie nutzen und wo sie sich befinden	1 Credit
`lookup_companies`	Die Unternehmen hinter bis zu 20 Domains, als kompakte Tabelle	1 Credit pro Domain mit Daten
`lookup_domains_technologies`	Die Technologien auf bis zu 20 Domains, als kompakte Tabelle. Optionaler `category`-Filter	1 Credit pro Domain mit Daten

Eine Suche, die nichts findet, wird nicht berechnet. Auch check_credits nicht.

Breite vs. Tiefe

Es gibt zwei Technologie-Tools, die unterschiedliche Fragen beantworten. lookup_domains_technologies ist die Breiten-Ansicht: viele Domains, nur Technologienamen, ideal für „Welche davon nutzen Shopify?“. lookup_domain_technologies ist die Tiefen-Ansicht: eine Domain, jede Technologie mit ihrer Kategorie und wie viele Websites sie weltweit nutzen. Das Batch-Tool meldet, wie viele Technologien es pro Domain ausgelassen hat, damit das Modell anbieten kann, tiefer zu gehen.

Warum die Batch-Tools bei 20 aufhören

Die dahinterliegenden REST-Endpunkte akzeptieren 100 Domains pro Anfrage, und diese Tools tun das bewusst nicht. Ein Tool-Ergebnis geht direkt in den Kontext des Modells, und hundert vollständige Unternehmens-Payloads sind Zehntausende von Tokens, die das Gespräch, das du tatsächlich führst, verdrängen, und das Modell muss dann alles erneut lesen, um irgendetwas zu beantworten. Zwanzig kompakte Zeilen sind eine Tabelle, über die ein Modell nachdenken kann.

Es verweigert auch eher, als dass es abschneidet. Wenn ein Batch mehr kosten würde, als dein Sitzungslimit erlaubt, berechnet es nichts und teilt dir mit, wie viele du dir leisten kannst. Domains stillschweigend wegzulassen würde eine Antwort liefern, die vollständig aussieht und es nicht ist.

Wenn du wirklich Hunderte von Domains benötigst, dafür ist der REST-Endpunkt da.

Konfiguration

Variable	Erforderlich	Standard	Hinweise
`STACKSCAN_API_TOKEN`	ja	keiner	Dashboard → API Tokens
`STACKSCAN_TENANT_ID`	ja	keiner	Deine Workspace-UUID, dieselbe Seite
`STACKSCAN_API_BASE`	nein	`https://api.stackscan.com`	Selten benötigt
`STACKSCAN_SESSION_LOOKUP_CAP`	nein	`25`	Siehe unten

Das Sitzungslimit ist ein Ausgabenlimit, und es ist beabsichtigt

StackScans eigenes Limit ist ein Ratenlimit: Anfragen pro Minute. Das stoppt einen Burst. Es tut nichts, um einen geduldigen Agenten davon abzuhalten, über einen Nachmittag hinweg stillschweigend ein ganzes Guthaben auszugeben, was eine Fehlerart ist, die Menschen, die auf Schaltflächen klicken, nicht haben.

Dieser Server führt daher einen eigenen Zähler: standardmäßig 25 Guthaben verbrauchende Suchanfragen pro Sitzung, danach verweigert er und erklärt warum. Fehlversuche und check_credits zählen nie dagegen, weil sie nie berechnet werden. Jedes erfolgreiche Ergebnis enthält eine Fußzeile mit verbleibenden Suchanfragen und deinem letzten bekannten Guthaben, damit das Modell sich selbst einteilen kann, anstatt das Limit durch Erreichen zu entdecken.

Wenn du höher gehen willst, erhöhe es bewusst ("STACKSCAN_SESSION_LOOKUP_CAP": "200") anstatt es hinterher herauszufinden.

Entwicklung

npm install
npm run build

test-stdio.mjs ist ein minimaler JSON-RPC-Client, der den Server über eine echte stdio-Pipe steuert, sodass du ihn ohne einen MCP-Host testen kannst:

export STACKSCAN_API_TOKEN=...
export STACKSCAN_TENANT_ID=...
node test-stdio.mjs check_credits lookup_company:stripe.com

Schreibe niemals in stdout in diesem Server. stdout ist der JSON-RPC-Kanal; alles andere darauf beschädigt das Protokoll. Diagnosen gehen an stderr.

Hinweise für alle, die den Quellcode lesen

Drei Dinge über die vorgelagerte API haben diesen Code geprägt und sind leicht falsch zu verstehen:

Ein Fehlversuch ist HTTP 200, nicht 404. Die API antwortet auf „keine Daten für diese Domain“ mit 200 {"success": false, "error": "No data available"}. Ein Client, der dem Statuscode vertraut, liest die fehlende Nutzlast und stürzt ab. Jede Antwort durchläuft eine Stelle, die einen Fehlversuch von einem Fehler trennt, sodass nur ein echter Fehler als Fehler gemeldet wird.

Zwischengespeicherte Antworten werden weiterhin berechnet. Der Antwort-Cache der API schützt seine Datenbank, nicht dein Portemonnaie: Eine wiederholte Suche innerhalb des Cache-Fensters kostet dasselbe Guthaben. Deshalb verringert sich das lokale Guthaben bei jedem Treffer, anstatt zu raten, welche Aufrufe kostenlos waren.

Zwei Basis-URLs sind aktiv. Die Heimat der API ist api.stackscan.com/v1/.... Die älteren Pfade app.stackscan.com/api/v1/... werden weiterhin bedient und bewusst nicht umgeleitet, da eine Umleitung den Body bei POST verwerfen würde. Wenn deine Konfiguration noch den alten Host nennt, erkennt dieser Server das und verwendet weiterhin die alte Pfadform, sodass ein Upgrade dich nicht bricht.

Datenschutzerklärung

StackScans Datenschutzerklärung befindet sich unter www.stackscan.com/privacy. Was das für diesen Server konkret bedeutet:

Was gesammelt wird. Die Domains und Technologienamen, die du nachschlägst, werden über HTTPS an api.stackscan.com gesendet, zusammen mit deinem API-Token und deiner Workspace-ID. Sonst verlässt nichts deinen Rechner. Dieser Server liest keine Dateien, öffnet keine Ports und führt keinen lokalen Speicher; der einzige Zustand, den er hält, ist ein Suchzähler und ein Guthaben, beide im Speicher und beide verschwunden, wenn der Prozess endet.

Wie es verwendet und gespeichert wird. Suchanfragen werden gegen deinen Workspace protokolliert, damit Guthaben gemessen und das Konto unterstützt werden kann. Ergebnisse stammen aus StackScans eigenen Crawl-Daten, nicht aus etwas, das du sendest.

Dritte. Suchbegriffe werden nicht verkauft oder für Werbung geteilt. Sie erreichen die Infrastrukturanbieter, auf denen StackScan läuft, wie unter „Weitergabe an Dienstanbieter“ in der Richtlinie dargelegt, und sonst niemanden.

Aufbewahrung. Unter „Datenaufbewahrung“ in der Richtlinie abgedeckt. Lösche dein Konto und die zugehörige Suchhistorie verschwindet damit.

Kontakt. hello@stackscan.com oder www.stackscan.com/contact.

Lizenz

MIT. Siehe LICENSE.

Die Lizenz deckt nur diesen Client ab, etwa 500 Zeilen, die HTTP-Anfragen stellen. Die StackScan-Daten, die er erreicht, sind ein kostenpflichtiger Dienst und werden davon nicht abgedeckt.

Available Tools

6 tools

check_creditsCheck credit balanceA

Read-only

Check the StackScan credit balance. Free - does not consume a credit. Call this before a batch of lookups so you know how many you can afford.

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

The annotations already declare readOnlyHint=true, which the description reinforces. It adds valuable behavioral information by stating 'Free - does not consume a credit', a detail not captured in the annotations. This goes beyond the annotation's simple read-only hint.

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

Conciseness5/5

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

The description is two sentences with no redundant information. It leads with the core action, then provides the usage context and the cost-saving behavior. Every sentence earns its place.

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 a tool with zero parameters and no output schema, the description fully covers what it does, when to use it, and the critical behavior of not consuming credits. Nothing needed to call it correctly 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?

The input schema has no parameters, so there is no parameter description to provide. Per the rubric, a zero-parameter tool receives a baseline score of 4 because no parameter explanations are needed.

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?

The description uses a specific verb 'check' and a clear resource 'credit balance', making the tool's purpose unmistakable. It is clearly distinguished from the sibling lookup tools, which all involve looking up data rather than managing credits.

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?

The description explicitly states when to use the tool ('before a batch of lookups') and explains the benefit ('so you know how many you can afford'). While it does not mention alternatives, none are relevant for checking credit balance, so the guidance is sufficient.

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

lookup_companiesLook up the companies behind many domainsA

Read-only

Look up the companies behind up to 20 domains in ONE call, returned as a compact table. Prefer this over repeated lookup_company calls whenever you have several domains in hand - it is one request instead of many, and costs the same per resolved domain. Duplicates and www. variants collapse and are charged once. Costs 1 credit per domain that HAS data; misses and malformed domains are free.

Name	Required	Description	Default
`domains`	Yes	Bare domains, e.g. ["example.com","stripe.com"]. Maximum 20.

TDQS

A4.7/5.0

Behavior5/5

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

The annotations only indicate read-only and open-world hints. The description adds valuable behavioral detail: results come as a compact table, duplicates and www variants collapse and are charged once, and misses/malformed domains are free. Pricing behavior is disclosed clearly and does not contradict the annotations.

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

Conciseness5/5

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

The description is compact and front-loaded with the core purpose followed by usage guidance and cost details. Every sentence earns its place, and the key differentiator (one call for up to 20 domains) appears immediately.

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 a single-parameter read-only tool with no output schema, the description covers purpose, scope, batching behavior, deduplication, pricing, and free cases. Nothing essential for an agent to decide whether and how to call it is missing.

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 coverage is 100%, and the schema already documents that domains are an array of strings, bare domains, with maxItems 20. The description reinforces this but adds no new parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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?

The description states a specific verb ('Look up'), a clear resource (companies behind domains), and a distinguishing scope (up to 20 domains in one call). It also differentiates from the singular sibling by emphasizing the batch capability, so an agent can immediately tell it apart.

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

Usage Guidelines5/5

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

It explicitly says to prefer this over repeated lookup_company calls when several domains are already known, and explains the efficiency and cost equivalence. This provides direct routing guidance versus the main alternative.

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

lookup_companyLook up the company behind a domainA

Read-only

Given a domain, return the company behind it: name, industry, city, country, address and LinkedIn URL. Use this when asked who owns or operates a website, or to enrich a domain into firmographics. Costs 1 credit.

Name	Required	Description	Default
`domain`	Yes	Bare domain, e.g. example.com (no scheme, no path)

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already provide readOnlyHint and openWorldHint, so the description does not need to re-state safety. It adds useful behavioral context beyond annotations, including the one-credit cost and the specific firmographic fields returned, which are not present in the schema or annotations.

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

Conciseness5/5

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

The description is three short, purposeful sentences with no filler. It front-loads the core behavior and output, then states the use case and cost, all in under 40 words.

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 a low-complexity, single-parameter, read-only lookup, the description is complete: it explains input, output fields, when to use it, and cost. The schema fully covers the parameter format, and the annotations cover safety, so no critical information is missing.

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 coverage is 100%, with the single 'domain' parameter already documented as a bare domain with no scheme or path. The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.

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?

The description clearly states a specific verb-resource pair: given a domain, return the company behind it. It lists the exact output fields (name, industry, city, country, address, LinkedIn URL), making its purpose unmistakable and distinguishing it from domain-technology and technology lookups.

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?

The description explicitly says when to use it: when asked who owns or operates a website, or to enrich a domain into firmographics. It does not explicitly name alternatives or exclusions, but the stated use cases are clear enough for an agent to select this tool.

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

lookup_domains_technologiesList technologies across many domainsA

Read-only

Look up the technologies on up to 20 domains in ONE call, returned as a compact table. Prefer this over repeated lookup_domain_technologies calls whenever you have several domains in hand - it is one request instead of many and costs the same per resolved domain. Answers questions like 'which of these run Shopify?'. Pass category to narrow to one kind of technology. For the full detail on ONE domain (every technology with its category and global usage), use lookup_domain_technologies instead. Duplicates and www. variants collapse and are charged once. Costs 1 credit per domain that HAS data; misses and malformed domains are free.

Name	Required	Description
`domains`	Yes	Bare domains, e.g. ["example.com","stripe.com"]. Maximum 20.
`category`	No	Only return technologies in this TOP-LEVEL group, e.g. "E-commerce & Sales" or "Hosting & Infrastructure". This is the part BEFORE the slash in lookup_domain_technologies output. The part after it, such as "Payment Processing", is a sub-category and matches nothing. Case-insensitive. Omit for all categories.
`per_domain`	No	Technologies to show per domain (default 10, max 50). Raising it does not cost extra credits, only context.

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description adds meaningful behavioral details: duplicate and www. variants collapse, credits are charged per domain with data, malformed domains are free, and raising per_domain does not cost extra credits. These are non-obvious traits an agent would not otherwise know.

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

Conciseness5/5

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

The description is longer than average but every sentence carries actionable information. It is front-loaded with purpose and usage guidance, followed by edge-case behavior and pricing, with no filler or repetition.

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

Completeness4/5

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

The description covers the tool's purpose, main alternative, parameter nuances, batching behavior, deduplication, and credit cost. The only mild gap is that the 'compact table' return format is not specified in more detail, but the examples and references to lookup_domain_technologies provide enough orientation.

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 goes further by clarifying that category means the part before the slash in lookup_domain_technologies output and that the sub-category after the slash matches nothing, plus that per_domain affects only context, not cost. This adds real value beyond the schema.

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?

The description opens with a specific verb and resource: 'Look up the technologies on up to 20 domains in ONE call', and immediately names the sibling tool it should not be confused with. It clearly distinguishes itself from lookup_domain_technologies by scope and level of detail.

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

Usage Guidelines5/5

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

The description explicitly says to prefer this tool over repeated lookup_domain_technologies calls whenever several domains are in hand, and tells the agent to switch to lookup_domain_technologies when full detail on a single domain is needed. It also explains when category should be used and when it should be omitted.

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

lookup_domain_technologiesList a domain's technology stackA

Read-only

Given a domain, list the technologies detected on it (analytics, hosting, ecommerce platform, frameworks and so on), each with its category and how many sites overall use it. Use this to answer 'what is this site built with?'. Costs 1 credit.

Name	Required	Description	Default
`limit`	No	Max technologies to return (default 50, cap 100). 50 is the full stack for over 99.9% of domains.
`domain`	Yes	Bare domain, e.g. example.com (no scheme, no path)

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, covering the safe read-only nature. The description adds valuable context beyond annotations by disclosing the cost ('Costs 1 credit') and the output structure (category and usage count). This provides useful operational insight not present in the structured annotations.

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

Conciseness5/5

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

The description is two sentences with no wasted words. It front-loads the core purpose, then adds the use case and cost information. Everything earns its place and is easy to parse.

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?

Even though there is no output schema, the description explains what is returned (technologies with category and usage count). It also covers the required input (domain), the optional limit is in the schema, and the cost is disclosed. For a simple read-only lookup tool, nothing critical is missing.

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?

The input schema has 100% description coverage for both parameters (domain and limit), so the schema already documents them thoroughly. The description does not add any additional parameter-specific meaning beyond what the schema provides, which is the baseline for a high-coverage schema.

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?

The description clearly states the tool's function: given a domain, list the technologies detected on it, including category and usage count. This distinguishes it from siblings like lookup_technology (which looks up a specific technology) and lookup_domains_technologies (plural, likely for multiple domains) by explicitly referencing 'a domain' and the technologies detected on it.

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?

The description provides an explicit use case: 'Use this to answer what is this site built with?'. This tells the agent when to use it, but it does not mention alternatives or when not to use it, so it falls 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.

lookup_technologySize a technology's adoptionA

Read-only

Given a technology name, return how widely it is used and its top countries by adoption. Use this to size a market or compare platforms, e.g. 'how many sites run Shopify, and where?'. Costs 1 credit.

Name	Required	Description	Default
`technology`	Yes	Technology name as StackScan knows it, e.g. Shopify, Klaviyo, Cloudflare

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already mark the tool as read-only and open-world, so the description only needs to add context beyond that. It usefully discloses the 1-credit cost and clarifies the output content (adoption breadth plus top countries). No contradiction with annotations.

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

Conciseness5/5

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

Three short sentences with no filler: the core behavior is front-loaded, a practical use case follows, and the credit cost is a useful closing note. Every sentence earns its place.

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

Completeness4/5

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

For a one-parameter read-only lookup with no output schema, the description covers input, expected output, example usage, and cost. It could be slightly more precise about what 'how widely it is used' means (e.g., site count, percentage), but the description is sufficient for an agent to call the tool correctly.

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%, and the schema already explains that 'technology' is a StackScan-specific name with examples. The tool description adds an example use case but no additional format, normalization, or edge-case guidance, so the baseline score of 3 is appropriate.

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?

The description opens with a specific verb and resource: 'Given a technology name, return how widely it is used and its top countries by adoption.' The example 'how many sites run Shopify, and where?' makes the purpose concrete, and the technology focus clearly distinguishes it from sibling tools that target companies or domains.

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?

The description gives two explicit use cases — 'size a market or compare platforms' — and provides an illustrative query. It does not explicitly state when not to use this tool or contrast it with sibling alternatives, but the usage context is strong enough for most cases.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.3.0Aug 26, 2026

Changedlookup_companies1 field changed

changedInput schema / properties / domains / description

Previous value: -"Bare domains, e.g. [\"shopify.com\",\"stripe.com\"]. Maximum 20."New value: +"Bare domains, e.g. [\"example.com\",\"stripe.com\"]. Maximum 20."

Changedlookup_company1 field changed

changedInput schema / properties / domain / description

Previous value: -"Bare domain, e.g. shopify.com (no scheme, no path)"New value: +"Bare domain, e.g. example.com (no scheme, no path)"

Changedlookup_domain_technologies3 fields changed

changedInput schema / properties / domain / description

Previous value: -"Bare domain, e.g. shopify.com (no scheme, no path)"New value: +"Bare domain, e.g. example.com (no scheme, no path)"

changedInput schema / properties / limit / description

Previous value: -"Max technologies to return (default 25, cap 50)"New value: +"Max technologies to return (default 50, cap 100). 50 is the full stack for over 99.9% of domains."

changedInput schema / properties / limit / maximum
```
Previous value: -50New value: +100
```

Addedlookup_domains_technologies

5 tool updatesv0.1.0Aug 4, 2026
- First observedcheck_credits
- First observedlookup_companies
- First observedlookup_company
- First observedlookup_domain_technologies
- First observedlookup_technology

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.5/5.0

Scored 2026-08-26 07:10 across 6 tools

Disambiguation5/5

Each tool serves a distinct purpose: credit check, single/multi-company lookup, single/multi-technology lookup, and a standalone technology market lookup. The batch variants are explicitly differentiated from their single counterparts, and descriptions clearly guide when to use each, eliminating ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern: check_credits, lookup_company, lookup_domain_technologies, lookup_technology, lookup_companies, lookup_domains_technologies. The plural versions naturally extend the singular ones, and the pattern is uniform across the entire set.

Tool Count5/5

Six tools is a well-scoped set for a domain intelligence API. Each tool covers a distinct operation (balance, single/batch company lookup, single/batch tech lookup, tech market lookup) without redundancy or bloat, fitting comfortably within the ideal 3-15 range.

Completeness4/5

The surface covers the core read-only lifecycle: single and batch lookups for both companies and technologies, a technology market tool, and a credit checker. Minor gaps exist (e.g., no way to list all technologies or search companies by name), but they are edge cases that agents can work around.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

forency
io.github.cheevahagadog
Detect the tech stack behind any website: CMS, ecommerce, analytics, CRM, payments, hosting.
Browser Automation Web Scraping
11
https://forency.io/api/mcp
Web & Developer Data ToolsOAuth
io.github.projectworks007
Website tech stacks, domain WHOIS/DNS/SSL, sitemaps, PDF text, GitHub trending and more.
Web Scraping Networking & Infrastructure Developer Tools
1
https://mcp.apify.com/?tools=highbrow_fame/pdf-text-extractor,highbrow_fame/domain-whois-dns-ssl,highbrow_fame/website-tech-stack,highbrow_fame/sitemap-url-extractor,highbrow_fame/domain-authority-rank,highbrow_fame/rss-feed-reader,highbrow_fame/openstreetmap-places,highbrow_fame/github-trending-repos,highbrow_fame/weather-api,highbrow_fame/github-repo-api
TechSpy
com.hi-daniel.techspy
Detect any website's tech stack, DNS and email security, subdomains and sitemap from your agent.
Networking & Infrastructure Penetration Testing Web Scraping
1
https://techspy.hi-daniel.com/api/mcp
Company ResearchOAuth
io.github.kiskecske24
Website tech stack (7,600+ technologies) and screenshots for any company site, via Apify.
Web Scraping Browser Automation Research & Data
1
https://mcp.apify.com/?tools=Kadi_Bence/tech-stack-detector,Kadi_Bence/website-screenshot

Related MCP Servers

BuiltWith MCP Server
Web Scraping Search Developer Tools
Cyreslab-AI
A
license
Not graded
quality
C
maintenance
Enables querying the BuiltWith API to discover and analyze website technology stacks, including frameworks, analytics tools, CMS platforms, and other technologies used by any domain.
Updated a month ago (2026-09-18 23:24 UTC)
2
MIT
mcp-gtm-tech-stack-signal
Web Scraping CRM Marketing
mambalabsdev
A
license
A
quality
A
maintenance
Detects a company's technology stack from its public web presence. Returns structured tech signals for sales targeting and competitive analysis.
Updated 4 days ago (2026-10-20 20:04 UTC)
1
251 npm
1
MIT
techstack-detective-mcp
Web Scraping Research & Data
emily397
F
license
Not graded
quality
C
maintenance
Provides AI agents with tools to detect Shopify apps, WordPress plugins, DNS/email/SaaS footprint, and estimate SaaS spend for competitive intelligence and vendor research.
Updated 4 months ago (2026-06-18 05:15 UTC)
-
echolocofficial
Research & Data Search
echoloc-ai
A
license
A
quality
C
maintenance
Company technographics: search 760,000+ companies by the technologies they use — with direction of change (adopting / replacing / evaluating) — enrich any domain with firmographics and hiring signals, and browse a 10,000+ technology catalog. Remote server at https://api.echoloc.ai/mcp (Streamable HTTP); free API key: 100 requests/month, no card. Docs: https://echoloc.ai/for-agents
Updated 3 months ago (2026-07-29 23:15 UTC)
3
MIT

StackScan MCP-Server

Installation

Claude Desktop (Erweiterung)

Claude Desktop (manuelle Konfiguration)

Claude Code

Cursor, Windsurf und andere

Tools

Breite vs. Tiefe

Warum die Batch-Tools bei 20 aufhören

Konfiguration

Das Sitzungslimit ist ein Ausgabenlimit, und es ist beabsichtigt

Entwicklung

Hinweise für alle, die den Quellcode lesen

Datenschutzerklärung

Links

Lizenz

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

echolocofficial