Skip to main content
Glama

Find Companies By Tech Stack

find_companies_by_tech_stack

Use ONLY when the user explicitly wants to discover companies BY THEIR INSTALLED TECHNOLOGY — e.g. "find DTC brands using Shopify and Klaviyo", "who runs Snowflake AND Looker", "US e-commerce companies using HubSpot". For hiring-signal discovery (companies posting jobs that mention a tech), use theirstack_search instead — that surfaces investment intent, whereas this surfaces installed base.

That installed base is what TheirStack DETECTS from job-posting text, not from crawling storefronts, so it only sees companies that hire and name the tool in their JDs — treat a company's absence as "not detected here," not "not using it" (a storefront-sniffing method like BuiltWith/Wappalyzer would surface more).

For ecommerce-platform tools, results may include the platform's SERVICE PROVIDERS (agencies, ISVs) alongside actual merchants — job mentions don't distinguish "we run on Shopify" from "we sell to Shopify merchants," so inspect domains/industries to filter. Recruiting agencies are always excluded (company_type = direct_employer), matching theirstack_search.

Costs 1.5 Sliq credits per company returned; a failed search is free.

In chat, STATE THE COUNT AND THE COST in the same reply as the results — every time, without stopping to ask first. Use the user's number when they gave one, otherwise the default: "pulled 25 companies — 37.5 credits; say if you want more, max 100." Price the companies actually returned: fewer than limit costs less. Because this endpoint pages, prefer one page at the user's number over silently walking offset past it — every extra page is more credits.

When this runs in an agent, every company with a domain is saved to the Output tab as a company row (deduped by domain) carrying its firmographics and matched technologies. To filter them, record a verdict on each saved row with record_search_results, under the domain it was saved with.

The tool resolves each technology name to a TheirStack catalog slug (calling /v0/catalog/technologies per name; popularity tiebreak; exact name match wins), then queries /v1/companies/search with company_technology_slug_and so EVERY supplied technology must be present on the returned company. { "companies": [ { "id": str, "name": str, "domain": str | None, "industry": str | None, "employee_count": int | None, "country_code": str | None, "linkedin_url": str | None, "technologies_found": [ {"slug": str, "name": str, "confidence": str, "jobs": int, "last_date_found": str}, ... ], }, ... ], "count": int, # number of companies in this page "total_matches": int, # universe size for this query (or None) "created_identifiers": [str], # domains this call newly added to the list }

On upstream failure (timeout / 5xx / connection error), returns {"companies": [], "count": 0, "theirstack_available": False} so the agent can read the flag and degrade gracefully.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoCompanies this ONE call returns, 1-100 (values outside are clamped), default 25. Pass the user's number when they named one.
offsetNoNumber of results to skip for pagination. Pass `limit`, 2*`limit`, ... to fetch subsequent pages. Re-run with the same filters to get a stable order. Each page is billed like a fresh pull, so page only when the user asked for more.
agent_idNoOptional — a specific agent to save the companies into. Omit it to use the running agent, which is the usual case.
industryNoLinkedIn-style industry names the company must match (e.g. ["Retail", "Higher Education"]). Values are validated against TheirStack's canonical catalog (431 industries) — wrong variants like "Architecture & Planning" raise ModelRetry with close-match suggestions.
list_nameNoShort kebab slug naming the Output-tab list bucket (e.g. 'shopify-brands'). Absent, companies land in the 'default' list.
confidenceNoTheirStack tech-detection confidence band. Pass ["high", "medium"] to drop one-off / stale mentions. Defaults to None (all confidence levels). Valid values: "high", "medium", "low". If a confidence-filtered search returns zero matches for a technology that plausibly has users, retry without `confidence` and judge per-company strength from `technologies_found[].confidence` instead — TheirStack's confidence aggregates are intermittently incomplete for some technologies.
company_cityNoCity/state substrings the company HQ must match (e.g. ["Atlanta", "Chicago", "Washington"]). Case-insensitive substring match, OR-combined across the list. Do NOT include the `(?i)` flag — TheirStack rejects it on this field. Pair with `country_codes` to keep matches scoped.
technologiesYesHuman product names — e.g. ["Shopify", "Klaviyo"]. Use canonical product names; names with no catalog match raise ModelRetry, and ambiguous names resolve to the most popular match. AND semantics: the company must use ALL supplied technologies. Max 10 per call.
country_codesNoISO alpha-2 HQ country filter. Pass ["US"] to scope to US companies — usually the right default.
min_revenue_usdNoMinimum company annual revenue in USD (e.g. 10_000_000 for $10M+).
industry_excludesNoIndustry names to exclude. Same canonical-name validation as `industry`.
max_employee_countNoMaximum company headcount. Defaults to None; consider passing e.g. 5000 if "uses Shopify" alone returns 10K+ matches dominated by enterprise outliers.
min_employee_countNoMinimum company headcount.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / agent_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Optional — a specific agent to save the companies into.\nOmit it to use the running agent, which is the usual case."
      +}
    • addedInput schema / properties / list_name
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Short kebab slug naming the Output-tab list bucket (e.g.\n'shopify-brands'). Absent, companies land in the 'default' list."
      +}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only mark it non-read-only and non-destructive; the description adds critical context: detection is from job-posting text (with absence != not using), service providers may be included, recruiting agencies are excluded, results are saved to the Output tab deduped by domain, failures degrade via `theirstack_available`, and it costs 1.5 credits per company (failed searches free). This is unusually rich behavioral disclosure beyond 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.

Conciseness4/5

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

Front-loaded with a summary and the usage condition, then organized paragraphs, all of which largely earn their place. It is somewhat verbose, especially the chat cost-reporting and Output-tab workflow instructions, but the structure keeps it navigable.

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?

Given 13 parameters, no formal output schema, and a mutation-plus-billing side effect, the description covers return shape, page/count semantics, failure degradation, cost model, and the downstream filtering workflow with `record_search_results`. Nothing essential to correct invocation 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?

Schema coverage is 100% so the baseline is 3, but the description adds genuine value the schema does not: it explains the technology-name resolution process (catalog lookup, popularity tiebreak, exact match wins) and reinforces AND semantics for `technologies`. It does not, however, expand on most other parameters (filters, pagination economics) beyond what the schema documents.

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?

States a specific verb and resource ('find companies whose technographic profile matches a target tech stack'), and explicitly differentiates from the sibling `theirstack_search` by contrasting installed-base discovery vs hiring-signal discovery. An agent can identify the right tool without opening the schema.

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?

Gives an explicit 'Use ONLY when...' condition with concrete user-utterance examples, and names the alternative (`theirstack_search`) with the criterion that selects it. It also prescribes the chat cost/count reporting behavior, leaving little to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources