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

Pregúntale a tu asistente sobre qué está construido un sitio web y quién está detrás.

Un servidor del Model Context Protocol para la API Tech Lookup de StackScan. Apunta Claude, Cursor o cualquier otro cliente MCP hacia él y podrás preguntar cosas como:

¿Sobre qué está construido example.com?
¿Quién está detrás de vercel.com? ¿Dónde están, en qué sector, cuál es su LinkedIn?
¿Cuántos sitios usan Klaviyo y en qué países?

De solo lectura por diseño. Nada de esto escribe en ningún sistema tuyo.

Instalación

Necesitas una cuenta de StackScan. Inicia sesión, abre API Tokens en el panel, crea un token y copia el UUID de tu espacio de trabajo desde la misma página.

Claude Desktop (extensión)

Descarga stackscan.mcpb desde la página de lanzamientos y arrástralo a Settings > Extensions. Te pedirá tu token de API y el ID de tu espacio de trabajo, e instalará el resto por sí mismo.

Claude Desktop (configuración manual)

Settings → Developer → Edit Config, y añade:

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

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 y otros

Misma forma: command: npx, args: ["-y", "@stackscan/mcp-server"] y las dos variables de entorno. Consulta la documentación de MCP de tu cliente para saber dónde vive su archivo de configuración.

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

Herramientas

Herramienta	Qué hace	Coste
`check_credits`	Saldo restante y asignación de este mes	gratis
`lookup_company`	La empresa detrás de un dominio: nombre, sector, ciudad, país, LinkedIn	1 crédito
`lookup_domain_technologies`	Tecnologías en UN dominio, al completo: categoría y uso global de cada una (`limit`, por defecto 50, máx. 100)	1 crédito
`lookup_technology`	Cuántos sitios usan una tecnología y dónde están	1 crédito
`lookup_companies`	Las empresas detrás de hasta 20 dominios, como tabla compacta	1 crédito por dominio con datos
`lookup_domains_technologies`	Las tecnologías en hasta 20 dominios, como tabla compacta. Filtro opcional `category`	1 crédito por dominio con datos

Una búsqueda que no encuentra nada no se cobra. Tampoco check_credits.

Amplitud frente a profundidad

Hay dos herramientas de tecnologías y responden a preguntas distintas. lookup_domains_technologies es la vista de amplitud: muchos dominios, solo nombres de tecnologías, ideal para «¿cuáles de estos usan Shopify?». lookup_domain_technologies es la vista de profundidad: un dominio, cada tecnología con su categoría y cuántos sitios la usan globalmente. La herramienta por lotes informa de cuántas tecnologías ha omitido por dominio, para que el modelo pueda ofrecer profundizar.

Por qué las herramientas por lotes se detienen en 20

Los endpoints REST que hay detrás aceptan 100 dominios por petición, y estas herramientas, deliberadamente, no. El resultado de una herramienta va directamente al contexto del modelo, y cien cargas completas de empresa son decenas de miles de tokens, que desplazan la conversación que realmente estás manteniendo; el modelo tendría que releer todo eso para responder cualquier cosa. Veinte filas compactas son una tabla sobre la que un modelo puede razonar.

Además, rechaza en lugar de truncar. Si un lote costara más de lo que permite el límite de tu sesión, no cobra nada y te dice cuántos puedes permitirte. Descartar dominios silenciosamente devolvería una respuesta que parece completa y no lo es.

Si de verdad necesitas cientos de dominios, para eso está el endpoint REST.

Configuración

Variable	Obligatoria	Por defecto	Notas
`STACKSCAN_API_TOKEN`	sí	ninguna	Dashboard → API Tokens
`STACKSCAN_TENANT_ID`	sí	ninguna	El UUID de tu espacio de trabajo, en la misma página
`STACKSCAN_API_BASE`	no	`https://api.stackscan.com`	Rara vez necesario
`STACKSCAN_SESSION_LOOKUP_CAP`	no	`25`	Ver más abajo

El límite de sesión es un límite de gasto, y es deliberado

El límite propio de StackScan es un límite de frecuencia: peticiones por minuto. Eso detiene una ráfaga. No hace nada para impedir que un agente paciente gaste silenciosamente todo un saldo de créditos durante una tarde, que es un modo de fallo que no tienen los humanos que hacen clic en botones.

Así que este servidor mantiene su propio contador: 25 búsquedas que consumen créditos por sesión por defecto; a partir de ahí, rechaza y explica por qué. Los fallos y check_credits nunca cuentan, porque nunca se cobran. Cada resultado correcto lleva un pie de página con las búsquedas restantes y tu último saldo conocido, para que el modelo pueda dosificarse en lugar de descubrir el límite al chocar con él.

Si pretendes llegar más alto, súbelo deliberadamente ("STACKSCAN_SESSION_LOOKUP_CAP": "200") en lugar de enterarte después.

Desarrollo

npm install
npm run build

test-stdio.mjs es un cliente JSON-RPC mínimo que maneja el servidor a través de una tubería stdio real, para que puedas probarlo sin un host MCP:

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

Nunca escribas en stdout en este servidor. stdout es el canal JSON-RPC; cualquier otra cosa en él corrompe el protocolo. Los diagnósticos van a stderr.

Notas para quien lea el código fuente

Hay tres cosas de la API upstream que condicionaron este código y con las que es fácil equivocarse:

Un fallo es HTTP 200, no 404. La API responde «no hay datos para ese dominio» con 200 {"success": false, "error": "No data available"}. Un cliente que confíe en el código de estado lee la carga ausente y falla. Todas las respuestas pasan por un único punto que separa un fallo de un error, de modo que solo un error real se notifica como tal.

Las respuestas en caché también se cobran. La caché de respuestas de la API protege su base de datos, no tu cartera: una búsqueda repetida dentro de la ventana de caché cuesta el mismo crédito. Por eso el saldo local se decrementa en cada acierto, en lugar de intentar adivinar qué llamadas fueron gratuitas.

Hay dos URL base activas. La dirección principal de la API es api.stackscan.com/v1/.... Las rutas antiguas app.stackscan.com/api/v1/... todavía se sirven y, deliberadamente, no se redirigen, porque una redirección eliminaría el cuerpo en POST. Si tu configuración todavía menciona el host antiguo, este servidor lo detecta y sigue usando la forma de ruta antigua, de modo que una actualización no te romperá nada.

Política de privacidad

La política de privacidad de StackScan está en www.stackscan.com/privacy. Lo que significa para este servidor en concreto:

Qué se recopila. Los dominios y nombres de tecnologías que consultas, enviados a api.stackscan.com por HTTPS junto con tu token de API y el ID de tu espacio de trabajo. Nada más sale de tu máquina. Este servidor no lee archivos, no abre puertos y no guarda ningún almacén local; el único estado que mantiene es un contador de búsquedas y un saldo de créditos, ambos en memoria y ambos desaparecen cuando el proceso termina.

Cómo se usa y se almacena. Las búsquedas se registran en tu espacio de trabajo para poder medir los créditos y dar soporte a la cuenta. Los resultados provienen de los propios datos de rastreo de StackScan, no de nada que envíes.

Terceros. Los términos de búsqueda no se venden ni se comparten con fines publicitarios. Llegan a los proveedores de infraestructura sobre los que StackScan opera, tal como se indica en «Sharing With Service Providers» en la política, y a ningún otro sitio.

Retención. Cubierto en «Data Retention» en la política. Elimina tu cuenta y el historial de búsquedas asociado desaparece con ella.

Contacto. hello@stackscan.com, o www.stackscan.com/contact.

Enlaces

Licencia

MIT. Consulta LICENSE.

La licencia cubre solo este cliente, aproximadamente 500 líneas que hacen peticiones HTTP. Los datos de StackScan a los que accede son un servicio de pago y no están cubiertos por ella.

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

Instalación

Claude Desktop (extensión)

Claude Desktop (configuración manual)

Claude Code

Cursor, Windsurf y otros

Herramientas

Amplitud frente a profundidad

Por qué las herramientas por lotes se detienen en 20

Configuración

El límite de sesión es un límite de gasto, y es deliberado

Desarrollo

Notas para quien lea el código fuente

Política de privacidad

Enlaces

Licencia

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

echolocofficial