What can you do with this server?

StackScan MCP Server provides credit-based lookups into the technologies powering websites and the companies behind them, using the StackScan API. * Check credits (check_credits): See remaining balance and monthly allocation for free. * Look up a company (lookup_company): For a domain, get company name, industry, city, country, address, and LinkedIn (1 credit). * Look up domain technologies (lookup_domain_technologies): List detected technologies (analytics, hosting, ecommerce, frameworks, etc.) with category and global usage count for a single domain (1 credit, up to 50 results). * Look up technology adoption (lookup_technology): For a technology name (e.g., Shopify), see how many sites use it and top countries by adoption (1 credit). * Batch company lookups (lookup_companies): Retrieve company info for up to 20 domains in one call, returned as a compact table (1 credit per domain with data). * Batch technology lookups (lookup_domains_technologies): Get technology names for up to 20 domains, optionally filtered by category, also as a compact table (1 credit per domain with data). All operations are read-only. Lookups that return no data (misses) are free. A session cap (default 25 credit-consuming lookups) protects against overuse.

How do I use StackScan MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@StackScan MCP Server What is shopify.com built on?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

StackScan MCP Server

Official

by stackscan

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

StackScan MCP server

Ask your assistant what a website runs, and who is behind it.

A Model Context Protocol server for the StackScan Tech Lookup API. Point Claude, Cursor, or any other MCP client at it and you can ask things like:

What is example.com built on?
Who's behind vercel.com? Where are they, what industry, what's their LinkedIn?
How many sites run Klaviyo, and in which countries?

Read-only by design. Nothing here writes to any system of yours.

Install

You need a StackScan account. Sign in, open API Tokens in the dashboard, create a token, and copy your workspace UUID from the same page.

Claude Desktop (extension)

Download stackscan.mcpb from the releases page, then drag it onto Settings > Extensions. It asks for your API token and workspace ID and installs the rest itself.

Claude Desktop (manual config)

Settings → Developer → Edit Config, then add:

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

Restart Claude Desktop. The tools appear under the connectors icon.

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, and others

Same shape: command: npx, args: ["-y", "@stackscan/mcp-server"], and the two environment variables. Check your client's own MCP docs for where its config file lives.

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

Tools

Tool	What it does	Cost
`check_credits`	Remaining balance and this month's allocation	free
`lookup_company`	The company behind a domain: name, industry, city, country, LinkedIn	1 credit
`lookup_domain_technologies`	Technologies on ONE domain, in full: category and global usage for each (`limit`, default 50, max 100)	1 credit
`lookup_technology`	How many sites run a technology, and where they are	1 credit
`lookup_companies`	The companies behind up to 20 domains, as a compact table	1 credit per domain with data
`lookup_domains_technologies`	The technologies on up to 20 domains, as a compact table. Optional `category` filter	1 credit per domain with data

A lookup that finds nothing is not charged. Neither is check_credits.

Breadth vs depth

There are two technology tools and they answer different questions. lookup_domains_technologies is the breadth view: many domains, technology names only, ideal for "which of these run Shopify?". lookup_domain_technologies is the depth view: one domain, every technology with its category and how many sites use it globally. The batch tool reports how many technologies it left out per domain, so the model can offer to drill in.

Why the batch tools stop at 20

The REST endpoints behind them take 100 domains per request, and these tools deliberately do not. A tool result goes straight into the model's context, and a hundred full company payloads is tens of thousands of tokens, which crowds out the conversation you are actually having, and the model then has to re-read all of it to answer anything. Twenty compact rows is a table a model can reason over.

It also refuses rather than truncates. If a batch would cost more than your session cap allows, it charges nothing and tells you how many you can afford. Quietly dropping domains would hand back an answer that looks complete and is not.

If you genuinely need hundreds of domains, that is what the REST endpoint is for.

Configuration

Variable	Required	Default	Notes
`STACKSCAN_API_TOKEN`	yes	none	Dashboard → API Tokens
`STACKSCAN_TENANT_ID`	yes	none	Your workspace UUID, same page
`STACKSCAN_API_BASE`	no	`https://api.stackscan.com`	Rarely needed
`STACKSCAN_SESSION_LOOKUP_CAP`	no	`25`	See below

The session cap is a spend cap, and it is deliberate

StackScan's own limit is a rate limit: requests per minute. That stops a burst. It does nothing to stop a patient agent quietly spending an entire credit balance over an afternoon, which is a failure mode humans clicking buttons do not have.

So this server keeps its own counter: 25 credit-consuming lookups per session by default, after which it refuses and says why. Misses and check_credits never count against it, because they are never charged. Every successful result carries a footer showing lookups remaining and your last known balance, so the model can pace itself instead of discovering the limit by hitting it.

If you mean to go higher, raise it deliberately ("STACKSCAN_SESSION_LOOKUP_CAP": "200") rather than finding out afterwards.

Development

npm install
npm run build

test-stdio.mjs is a minimal JSON-RPC client that drives the server over a real stdio pipe, so you can exercise it without an MCP host:

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

Never write to stdout in this server. stdout is the JSON-RPC channel; anything else on it corrupts the protocol. Diagnostics go to stderr.

Notes for anyone reading the source

Three things about the upstream API shaped this code and are easy to get wrong:

A miss is HTTP 200, not 404. The API answers "no data for that domain" with 200 {"success": false, "error": "No data available"}. A client that trusts the status code reads the absent payload and crashes. Every response goes through one place that separates a miss from a failure, so only a real failure is reported as an error.

Cached responses are still charged. The API's response cache shields its database, not your wallet: a repeat lookup inside the cache window costs the same credit. That is why the local balance decrements on every hit instead of trying to guess which calls were free.

Two base URLs are live. The API's home is api.stackscan.com/v1/.... The older app.stackscan.com/api/v1/... paths are still served and are deliberately not redirected, because a redirect would drop the body on POST. If your config still names the old host, this server detects it and keeps using the old path shape, so upgrading will not break you.

Privacy Policy

StackScan's privacy policy is at www.stackscan.com/privacy. What it means for this server specifically:

What is collected. The domains and technology names you look up, sent to api.stackscan.com over HTTPS along with your API token and workspace ID. Nothing else leaves your machine. This server reads no files, opens no ports and keeps no local store; the only state it holds is a lookup counter and a credit balance, both in memory and both gone when the process exits.

How it is used and stored. Lookups are logged against your workspace so credits can be metered and the account can be supported. Results come from StackScan's own crawl data, not from anything you send.

Third parties. Query terms are not sold or shared for advertising. They reach the infrastructure providers StackScan runs on, as set out under "Sharing With Service Providers" in the policy, and nowhere else.

Retention. Covered under "Data Retention" in the policy. Delete your account and the associated lookup history goes with it.

Contact. hello@stackscan.com, or www.stackscan.com/contact.

License

MIT. See LICENSE.

The licence covers this client only, roughly 500 lines that make HTTP requests. The StackScan data it reaches is a paid service and is not covered by it.

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.

ParametersJSON Schema

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.

ParametersJSON Schema

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.

ParametersJSON Schema

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.

ParametersJSON Schema

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.

ParametersJSON Schema

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.

ParametersJSON Schema

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

Need Help?

Related Servers

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
Brand Intelligence MCP A
io.github.FoundryNet
Domain & brand intelligence: company enrichment, tech stack detection, brand research.
Marketing Research & Data
2
mcpOAuth
io.github.nerdydata
Search websites by source code, technology stack, analyze domains, and download lead lists.
Web Scraping Browser Automation
2
Boolsai Scan A
ai.boolsai
Live tech-stack scan of any public site — vendors, account IDs, scripts, JSON-LD. 2 tools.
Browser Automation Web Scraping
21

Related MCP Servers

BuiltWith MCP Server
Web Scraping Search Developer Tools
Cyreslab-AI
A
license
Not graded
quality
D
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 year ago (2025-05-14 08:26 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 5 days ago (2026-09-08 14:35 UTC)
1
97 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 3 months ago (2026-06-18 05:15 UTC)
-
lilAgents MCP
Security Networking & Infrastructure
lilAgents
A
license
A
quality
B
maintenance
Provides tools for AI agents to audit websites, including stack detection, DNS snapshots, and security checks.
Updated 2 months ago (2026-07-17 21:47 UTC)
8
12 npm
MIT

StackScan MCP server

Install

Claude Desktop (extension)

Claude Desktop (manual config)

Claude Code

Cursor, Windsurf, and others

Tools

Breadth vs depth

Why the batch tools stop at 20

Configuration

The session cap is a spend cap, and it is deliberate

Development

Notes for anyone reading the source

Privacy Policy

Links

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers