Spytrend

Search nutra & crypto affiliate offers

search_affiliate_offers

Read-only

PAID ADD-ONS «Nutra» and «Crypto», sold separately (MCP comes with the annual plan of each vertical). Find Meta ads whose landing pages are nutra or crypto affiliate offers, filtered by vertical (lp_category), niche (lp_subcategory), offer (lp_product), text (q) and Facebook launch date (date_from/date_to). PAGING: one call returns at most 50 rows; when has_more=true, repeat the call with the same filters and cursor=next_cursor to get the next page (new rows, never the same ones) — keep following next_cursor until has_more=false. total is the exact number of matching ads and is omitted when no exact count is available (absent total never means zero). Each row: ad_id, advertiser, landing_domain, vertical, niche, offer. Without the add-on the call is refused; a monthly «site» subscriber is told that MCP access is part of the annual plan. QUOTA: 1 MCP credit per delivered row; section rows have their own allowance — up to 500 rows per UTC day and 5 000 per UTC month per account, shared by every tool (search_ads, get_ad, get_media and the rest count the Nutra / Crypto / Web2App rows they return too), which MCP credit packs do not raise; market summaries (get_web2app_market) are outside it. 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

Name	Required	Description
`q`	No	free-text search in the ad
`limit`	No	rows per page, 1-50 (default 20); page further with cursor
`cursor`	No	next_cursor of the previous response with the same filters: returns the next page
`date_to`	No	Facebook launch date on/before, YYYY-MM-DD
`date_from`	No	Facebook launch date on/after, YYYY-MM-DD
`lp_product`	No	offer (product) name as shown by this tool (OR)
`lp_category`	No	vertical: nutra_affiliate or crypto_affiliate (OR); omitted = the verticals your annual plans open
`lp_subcategory`	No	niche as vertical/niche, e.g. nutra_affiliate/weight_loss (OR)

Output Schema

Name	Required	Description
`data`	No
`error`	No	Present only when isError is true: machine-readable failure. The human explanation stays in content.
`total`	No
`params`	No	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.
`has_more`	No
`addon_hints`	No	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.
`next_cursor`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 27, 2026

addedInput schema / properties / cursor

Added value: +{
+  "description": "next_cursor of the previous response with the same filters: returns the next page",
+  "type": "string"
+}

addedInput schema / properties / date_from

Added value: +{
+  "description": "Facebook launch date on/after, YYYY-MM-DD",
+  "type": "string"
+}

addedInput schema / properties / date_to

Added value: +{
+  "description": "Facebook launch date on/before, YYYY-MM-DD",
+  "type": "string"
+}

changedInput schema / properties / limit / description

Previous value: -"rows to return, 1-50 (default 20)"New value: +"rows per page, 1-50 (default 20); page further with cursor"

addedOutput schema / properties / next_cursor
```
Added value: +{
+  "type": "string"
+}
```

AddedOct 23, 2026

TDQS

A4.1/5.0

Behavior5/5

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

The description adds substantial behavior beyond the annotations: paid add-on requirements, refusal behavior, credit consumption per delivered row, daily/monthly row allowances, paging semantics, and what total/has_more mean. The readOnlyHint, openWorldHint, and destructiveHint annotations are not contradicted.

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 long but organized with explicit PAGING, QUOTA, and PRICING sections, and most details are relevant to correct invocation. The opening sentence prioritizes the paid add-on requirement before stating the core purpose, which slightly weakens front-loading.

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 paid add-on, quota limits, pricing consent, paging, and output schema, the description covers the full operational context an agent needs before calling. It also lists row fields despite having an output schema, leaving no significant practical gaps.

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%, so the schema already documents all eight parameters thoroughly. The description maps filters to lp_category, lp_subcategory, lp_product, q, and date fields and clarifies paging, but it largely duplicates what the schema provides rather than adding new parameter-level meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: find Meta ads whose landing pages are nutra or crypto affiliate offers. It also lists the filtering dimensions, which makes the tool's scope recognizable. It does not explicitly contrast itself with the general search_ads sibling, so it falls short of a 5.

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 clear prerequisites and usage context: the Nutra/Crypto add-on is required, calls are refused without it, consent via accept_pricing_terms is needed, and estimate_cost should be called first. It does not explicitly say when to use search_ads instead, but it does define the specialized context and refusal condition.

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

All Spytrend tools Inspect

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.