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

Спросите своего ассистента, на чём работает веб-сайт и кто за ним стоит.

Сервер Model Context Protocol для StackScan Tech Lookup API. Направьте на него Claude, Cursor или любой другой MCP-клиент, и вы сможете задавать вопросы вроде:

На чём построен example.com?
Кто стоит за vercel.com? Где они находятся, какая отрасль, какой у них LinkedIn?
Сколько сайтов используют Klaviyo и в каких странах?

По замыслу — только чтение. Ничто здесь не пишет в ваши системы.

Установка

Вам нужна учётная запись StackScan. Войдите, откройте API Tokens в панели управления, создайте токен и скопируйте UUID рабочей области с той же страницы.

Claude Desktop (расширение)

Скачайте stackscan.mcpb со страницы релизов, затем перетащите его в Settings > Extensions. Он запросит ваш API-токен и ID рабочей области и установит остальное сам.

Claude Desktop (ручная настройка)

Settings → Developer → Edit Config, затем добавьте:

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

Перезапустите Claude Desktop. Инструменты появятся под значком коннекторов.

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 и другие

Та же схема: command: npx, args: ["-y", "@stackscan/mcp-server"] и две переменные окружения. Обратитесь к документации вашего клиента по MCP, чтобы узнать, где находится его файл конфигурации.

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

Инструменты

Tool	What it does	Cost
`check_credits`	Остаток баланса и выделенный объём на этот месяц	бесплатно
`lookup_company`	Компания за доменом: название, отрасль, город, страна, LinkedIn	1 кредит
`lookup_domain_technologies`	Технологии на ОДНОМ домене, полностью: категория и глобальное использование для каждой (`limit`, по умолчанию 50, максимум 100)	1 кредит
`lookup_technology`	Сколько сайтов используют технологию и где они находятся	1 кредит
`lookup_companies`	Компании, стоящие за доменами (до 20), в виде компактной таблицы	1 кредит за домен с данными
`lookup_domains_technologies`	Технологии на доменах (до 20) в виде компактной таблицы. Необязательный фильтр `category`	1 кредит за домен с данными

Поиск, который ничего не находит, не тарифицируется. Как и check_credits.

Широта против глубины

Есть два инструмента для работы с технологиями, и они отвечают на разные вопросы. lookup_domains_technologies — это широкий взгляд: много доменов, только названия технологий, идеально для вопроса «какие из них используют Shopify?». lookup_domain_technologies — это глубокий взгляд: один домен, каждая технология с её категорией и тем, сколько сайтов используют её в мире. Пакетный инструмент сообщает, сколько технологий он пропустил по каждому домену, чтобы модель могла предложить углубиться.

Почему пакетные инструменты останавливаются на 20

Стоящие за ними REST-эндпоинты принимают 100 доменов на запрос, а эти инструменты намеренно — нет. Результат работы инструмента попадает прямо в контекст модели, а сотня полных массивов данных о компаниях — это десятки тысяч токенов, которые вытесняют ваш реальный разговор, и модели затем приходится перечитывать всё это, чтобы ответить на любой вопрос. Двадцать компактных строк — это таблица, с которой модель может работать.

Он также отказывается, а не усекает. Если пакет будет стоить больше, чем позволяет лимит вашей сессии, он не списывает ничего и сообщает, сколько вы можете себе позволить. Молча отбрасывая домены, можно было бы вернуть ответ, который выглядит полным, но не является таковым.

Если вам действительно нужны сотни доменов, для этого и существует REST-эндпоинт.

Конфигурация

Variable	Required	Default	Notes
`STACKSCAN_API_TOKEN`	да	нет	Dashboard → API Tokens
`STACKSCAN_TENANT_ID`	да	нет	UUID вашей рабочей области, та же страница
`STACKSCAN_API_BASE`	нет	`https://api.stackscan.com`	Нужно редко
`STACKSCAN_SESSION_LOOKUP_CAP`	нет	`25`	См. ниже

Лимит сессии — это лимит расходов, и это осознанное решение

Собственный лимит StackScan — это частотный лимит: запросов в минуту. Он останавливает всплеск. Но он не мешает терпеливому агенту незаметно потратить весь кредитный баланс в течение дня — это режим отказа, которого нет у людей, нажимающих кнопки.

Поэтому этот сервер ведёт собственный счётчик: 25 запросов, расходующих кредиты, на сессию по умолчанию, после чего он отказывает и объясняет почему. Промахи и check_credits никогда не учитываются, потому что они никогда не тарифицируются. Каждый успешный результат содержит нижний колонтитул с оставшимся количеством запросов и вашим последним известным балансом, чтобы модель могла рассчитывать свой темп, а не обнаруживать лимит, наткнувшись на него.

Если вы собираетесь поднять лимит, увеличьте его осознанно ("STACKSCAN_SESSION_LOOKUP_CAP": "200"), а не узнавайте об этом задним числом.

Разработка

npm install
npm run build

test-stdio.mjs — это минимальный JSON-RPC клиент, который управляет сервером через настоящий stdio-канал, так что вы можете опробовать его без MCP-хоста:

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

Никогда не пишите в stdout в этом сервере. stdout — это канал JSON-RPC; всё остальное в нём портит протокол. Диагностика идёт в stderr.

Примечания для тех, кто читает исходный код

Три особенности вышестоящего API сформировали этот код, и в них легко ошибиться:

Промах — это HTTP 200, а не 404. API отвечает на «нет данных для этого домена» кодом 200 {"success": false, "error": "No data available"}. Клиент, доверяющий коду состояния, читает отсутствующую полезную нагрузку и падает. Каждый ответ проходит через одно место, которое отделяет промах от сбоя, поэтому как ошибка сообщается только настоящий сбой.

Кэшированные ответы по-прежнему тарифицируются. Кэш ответов API защищает его базу данных, а не ваш кошелёк: повторный запрос в пределах окна кэша стоит тот же кредит. Именно поэтому локальный баланс уменьшается при каждом попадании, а не пытается угадать, какие вызовы были бесплатными.

Два базовых URL активны. Домашний адрес API — api.stackscan.com/v1/.... Более старые пути app.stackscan.com/api/v1/... по-прежнему обслуживаются и намеренно не перенаправляются, потому что перенаправление потеряло бы тело запроса при POST. Если в вашей конфигурации всё ещё указан старый хост, этот сервер обнаружит это и продолжит использовать старую форму пути, так что обновление вас не сломает.

Политика конфиденциальности

Политика конфиденциальности StackScan находится на www.stackscan.com/privacy. Вот что она означает конкретно для этого сервера:

Что собирается. Домены и названия технологий, которые вы ищете, отправляются на api.stackscan.com по HTTPS вместе с вашим API-токеном и ID рабочей области. Больше ничего не покидает вашу машину. Этот сервер не читает файлы, не открывает порты и не ведёт локальное хранилище; единственное состояние, которое он хранит, — это счётчик запросов и кредитный баланс, оба в памяти, и оба исчезают при завершении процесса.

Как это используется и хранится. Запросы регистрируются в журнале вашей рабочей области, чтобы можно было учитывать кредиты и поддерживать аккаунт. Результаты берутся из собственных данных обхода StackScan, а не из того, что отправляете вы.

Третьи стороны. Поисковые запросы не продаются и не передаются для рекламы. Они попадают к поставщикам инфраструктуры, на которой работает StackScan, как указано в разделе «Sharing With Service Providers» политики, и больше никуда.

Хранение. Описано в разделе «Data Retention» политики. Удалите свою учётную запись — и связанная история запросов исчезнет вместе с ней.

Контакт. hello@stackscan.com или www.stackscan.com/contact.

Ссылки

Лицензия

MIT. См. LICENSE.

Лицензия покрывает только этот клиент — примерно 500 строк, которые выполняют HTTP-запросы. Данные StackScan, к которым он обращается, являются платным сервисом и не покрываются ею.

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

Установка

Claude Desktop (расширение)

Claude Desktop (ручная настройка)

Claude Code

Cursor, Windsurf и другие

Инструменты

Широта против глубины

Почему пакетные инструменты останавливаются на 20

Конфигурация

Лимит сессии — это лимит расходов, и это осознанное решение

Разработка

Примечания для тех, кто читает исходный код

Политика конфиденциальности

Ссылки

Лицензия

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

echolocofficial