Skip to main content
Glama

Find competitors of a site

find_competitors
Read-only

Find the competitors of an advertising site by its domain, across the whole base. competitors are the site's direct competitors, the main list of its competitors page: taken from a saved paid competitor analysis of the site when one exists, otherwise from candidate sites filtered by domain rules and checked one by one by an AI judge. Rows keep that order, strongest first; the row's score field is not a rating here. Each row also carries site_profile, the monthly visits estimate, active_ads (Meta ads active now), product_count, platform, top_country and domain_created. A subdomain is looked up by its registrable domain. competitors_total is the number of rows returned (at most limit). An EMPTY competitors list means the site is not covered yet; it is NOT evidence that the site has no competitors. similar (include_similar=true, the default) are look-alike sites by site profile: they resemble the site but were not checked as rivals, and may include clones, mirrors and other domains of the same brand; similar_total counts every site passing the similarity threshold, not only the returned rows. Use get_shop to open one domain in full and search_ads with landing_domain to list its ads. QUOTA: 1 MCP credit (one entity card). PRICING: on paid plans ×1 after 500 MCP credits/month; one-time consent via accept_pricing_terms; before calling, get the maximum debit from estimate_cost (free) and tell the user.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "domain": "<domain>"
    },
    "name": "find_competitors"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNorows per list (default 20, maximum 50); applies to competitors and to similar
domainYesthe site domain (e.g. 'example.com'), as returned by search_shops or get_shop
include_similarNoalso return look-alike sites by site profile in similar (default true); false = competitors only

Output Schema

NameRequiredDescriptionDefault
errorNoPresent only when isError is true: machine-readable failure. The human explanation stays in content.
domainNo
paramsNoRequest parameter echo: applied = parameters that shaped this result; normalized = parameters rewritten before applying (alias, type coercion, resolved id); ignored = parameters that were accepted but NOT applied, with the reason.
similarNo
addon_hintsNoAdd-on modules that have additional data for objects of this result (no prices, no paid values). subscription_status=active: the account has the module — use its normal path. Do not push a purchase the user did not ask about.
competitorsNo
similar_totalNo
competitors_totalNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover safety (readOnlyHint, destructiveHint false, openWorldHint true), but the description adds substantial behavioral context beyond those annotations: the provenance of competitor data (saved analysis versus AI-judged candidate sites), row ordering, the meaning of the score field, subdomain lookup behavior, and subtle semantics like similar_total counting all matches. It also discloses quota, pricing, consent requirements, and the need to call estimate_cost first.

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?

The description is front-loaded and every sentence carries useful information, but it is dense and somewhat run-on, packing provenance, field meanings, quota, and pricing into one paragraph. A more structured layout could improve readability without losing substance.

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 the tool's complexity and the presence of an output schema, the description is highly complete. It explains data provenance, return semantics (including edge cases like empty lists), and operational requirements (estimate_cost, consent), leaving no critical gaps for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the input schema has full description coverage, the tool description adds meaning beyond it: domain is looked up by its registrable domain for subdomains, limit applies to both competitors and similar lists, and include_similar=true returns look-alike sites by profile with a specific caveat. This enriches parameter understanding materially.

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 begins with a specific verb and resource: 'Find the competitors of an advertising site by its domain, across the whole base.' It clearly distinguishes 'competitors' from 'similar' look-alike sites and explains how competitors are sourced, which sets it apart from sibling tools like get_shop and search_ads.

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 explains when to use this tool versus alternatives: get_shop for opening a domain in full and search_ads with landing_domain for listing ads. It also clarifies empty-list semantics ('not covered yet; NOT evidence that the site has no competitors') and the default behavior for include_similar, leaving little ambiguity for an agent.

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.