Skip to main content
Glama

Spytrend

by com.spytrend
OverviewDiscussionsAdmin

Get shop by domain

get_shop
Read-only

Fetch one domain surface's full profile, with its embedded products paged by products_offset/products_limit (20 by default, at most 50). products_page reports embedded_total, has_more and next_offset; follow it to retrieve every embedded product without losing its fields. products_total counts the product pages of the whole catalog, not embedded_total; use search_products to browse the rest of the catalog. Primary visits is the monthly estimate for traffic_as_of; fetched_at is ingestion time. traffic_sources is typed, while a separate legacy snapshot is kept alongside, and its similarly named traffic fields are not interchangeable with primary visits. the estimate's page title is not a canonical company/brand name; a missing rank on a subdomain is not evidence that the parent domain has no rank. domain_created is the best available registrable-root registration date, not product launch; its per-row RDAP/WHOIS-vs-legacy-fallback provenance is not retained in ClickHouse. ads_monthly/ads_burn use first_parsed_date and mark the open month is_complete=false. fb_signal is correlation_only. The domain/subdomain may be a funnel, runtime, blog or redirect rather than a company/product; inspect registrable_domain and surface_type. Includes AI-ad-category breakdown, recent ads and products. Its active_ads/total_ads count the Meta ads of the WHOLE domain; the product / best-seller list carries no per-product ad counts — call search_products with domain= for per-product numbers. To save it use add_to_favorites (entity_type=shop, ids=[domain]). COUNTS: every count is ONE network over ONE window — never add counts together, never derive a new count, and never present a sum across networks or windows as the domain's total. active_ads / total_ads = Meta (Facebook/Instagram) ads of the whole domain: active now / all time. ads_last_month / ads_prev_month = Meta ads first seen in our data in the last / the previous complete calendar month. ads_active_7d / ads_active_14d / ads_active_28d = Meta ads that were active 7 / 14 / 28 days ago; launches_7d / launches_28d = Meta ad launches counted for the shop over the last 7 / 28 days. google_ads / google_ads_active = Google ads: all published / active now. tt_ads / tt_ads_30d = TikTok ads: all time / active in the last 30 days. The Google and TikTok fields are omitted when no ads of that network were found for the domain. ads_geo[] is per targeted country: ads = Meta ads targeting that country, share = that count over an internal row count of the domain (not total_ads); one ad targets several countries, so ads_geo rows overlap and shares do not add up to 1 — never divide ads by share, never add ads_geo rows, ads_monthly or ads_burn months into a total: the all-time Meta total is total_ads. To describe ads across networks, name each network with its own number and window. Product counts are different fields — product_count is the shop's catalog: the number of UNIQUE products, where several product pages (URLs/handles) of one product, such as a -1 copy or a funnel duplicate, count once (merged by brand and title); only when our product data is smaller than the site crawler's counter is product_count that crawler counter. products_unique = unique products in our data, products_total = product pages (URLs) of the shop in our data, duplicates of one product included, catalog_size_true = catalog size from the sitemap (0 = unknown): call product_count the catalog and quote any other field by its meaning; products is a SAMPLE of the catalog's pages (best-sellers first) — its length is not a product count. A number with no field here is not available: say it is not available instead of computing it. 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.

Input Schema

NameRequiredDescriptionDefault
domainYesthe shop domain to fetch (e.g. 'example.com'), as returned by search_shops
products_limitNonumber of embedded products per page (default 20, maximum 50); all other shop profile fields remain present on each page
products_offsetNozero-based offset into the embedded products list; use products_page.next_offset to retrieve the next page

Output Schema

NameRequiredDescriptionDefault
dataNo
errorNoPresent only when isError is true: machine-readable failure. The human explanation stays in content.
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.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / addon_hints
      Added value: +{
+  "description": "Add-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.",
+  "items": {
+    "properties": {
+      "available_data_types": {
+        "description": "kinds of data the module confirmedly has for the object",
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "info_url": {
+        "description": "the object (or its limited breakdown) inside the module on spytrend.com",
+        "type": "string"
+      },
+      "module": {
+        "description": "nutra | crypto | web2app | search_arb | startups",
+        "type": "string"
+      },
+      "object_id": {
+        "description": "the ad id, or the site domain for site rows",
+        "type": "string"
+      },
+      "preland_downloadable": {
+        "description": "Nutra / Crypto: the saved pre-lander can be downloaded in the module",
+        "type": "boolean"
+      },
+      "subscription_status": {
+        "description": "active | not_connected",
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}
  2. Changed2 schema fields changed
    • addedInput schema / properties / products_limit
      Added value: +{
+  "description": "number of embedded products per page (default 20, maximum 50); all other shop profile fields remain present on each page",
+  "type": "integer"
+}
    • addedInput schema / properties / products_offset
      Added value: +{
+  "description": "zero-based offset into the embedded products list; use products_page.next_offset to retrieve the next page",
+  "type": "integer"
+}
  3. Changed2 schema fields changed
    • addedOutput schema / properties / error
      Added value: +{
+  "description": "Present only when isError is true: machine-readable failure. The human explanation stays in content.",
+  "properties": {
+    "code": {
+      "description": "fine-grained, stable failure code (e.g. invalid_arguments, backend_busy)",
+      "type": "string"
+    },
+    "kind": {
+      "description": "failure class: invalid_argument, not_found, permission_denied, unauthenticated, quota_exceeded, rate_limited, temporarily_unavailable, unavailable_until_ready, unsupported, internal",
+      "type": "string"
+    },
+    "message": {
+      "description": "the same human text as content[0]",
+      "type": "string"
+    },
+    "outcome": {
+      "description": "activity-feed outcome class",
+      "type": "string"
+    },
+    "param": {
+      "description": "the request parameter the failure is about, when known",
+      "type": "string"
+    },
+    "retry_after_seconds": {
+      "description": "wait this long before retrying",
+      "type": "integer"
+    },
+    "retryable": {
+      "description": "true when repeating the SAME call can succeed (after retry_after_seconds when present)",
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}
    • addedOutput schema / properties / params
      Added value: +{
+  "description": "Request 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.",
+  "properties": {
+    "applied": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "ignored": {
+      "items": {
+        "properties": {
+          "param": {
+            "type": "string"
+          },
+          "reason": {
+            "type": "string"
+          },
+          "to": {
+            "description": "the parameter it was applied as, when renamed",
+            "type": "string"
+          },
+          "value": {
+            "description": "the value actually applied, when rewritten",
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "normalized": {
+      "items": {
+        "properties": {
+          "param": {
+            "type": "string"
+          },
+          "reason": {
+            "type": "string"
+          },
+          "to": {
+            "description": "the parameter it was applied as, when renamed",
+            "type": "string"
+          },
+          "value": {
+            "description": "the value actually applied, when rewritten",
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnly/openWorld annotations, the description discloses extensive behavior: paging via products_page, what embedded_total vs products_total mean, count non-additivity rules, provenance caveats for domain_created and traffic fields, sample-vs-catalog distinctions, and quota/pricing considerations. These are substantive operational details an agent would otherwise miss.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The definition is front-loaded with a clear purpose sentence and uses some headings for COUNTS, QUOTA, and PRICING, so it is not unstructured. However, it is extremely long and dense, with many run-on caveats and repeated non-additivity warnings that could be tightened or moved into field documentation.

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, the presence of an output schema, and rich annotations, the description is more than complete. It covers purpose, paging, field semantics, count pitfalls, provenance limits, alternatives, quota, and pricing so an agent has enough context to call it correctly.

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 description coverage is 100%, so the baseline is 3, but the description adds useful paging semantics beyond the schema: products are paged by products_offset/products_limit, products_page exposes next_offset, and all other profile fields remain present on each page. It does not add much about the domain parameter beyond what the schema already says.

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 first sentence states a specific verb and resource: 'Fetch one domain surface's full profile' with embedded products. It scopes the tool to a single domain surface and later distinguishes it from catalog-wide browsing via search_products.

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 routes agents to alternatives: use search_products to browse the rest of the catalog, call search_products with domain=<domain> for per-product ad numbers, and use add_to_favorites to save the shop. It also gives a prerequisite workflow for estimate_cost and accept_pricing_terms before calling.

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

All Spytrend toolsInspect
Try in Browser
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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources