DataDive vs TrustRails MCP Server
A side-by-side look at the DataDive and TrustRails MCP Server MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose DataDive for e-commerce work as a local process; choose TrustRails MCP Server for e-commerce as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose DataDive when
- You need dedicated capabilities in the E-Commerce domain.
- You prefer a local stdio subprocess transport.
- You have the keys it needs:
DATADIVE_API_KEY. - You want tools like
list_niches, get_niche_keywords, list_keyword_exclusions.
Choose TrustRails MCP Server when
- You need dedicated capabilities in the E-Commerce domain.
- You prefer a local stdio subprocess transport.
- You have the keys it needs:
TRUSTRAILS_API_KEY. - You want tools like
search_products, get_product.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | E-Commerce | E-Commerce |
| Quality signal | 63/100 · Good | 55/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | Not declared |
| Pricing | Not declared | Not declared |
| Required env vars | DATADIVE_API_KEY | TRUSTRAILS_API_KEY |
| Verified owner | Community listing | Community listing |
| GitHub stars | 1 | 0 |
| Directory activity | 1 views 0 installs 0 upvotes | 2 views 0 installs 0 upvotes |
| Tools | 43 | 2 |
| Full listing | View DataDive | View TrustRails MCP Server |
Tools & capabilities
DataDive tools 43
list_nichesUse this first when the user asks about their niches, or to find a `nicheId` for use with `get_niche_keywords`, `get_niche_competitors`, or `get_ranking_juice`. Retrieves a paginated list of Niches, newest dive first. Each Niche represents a market segment or product category being tracked. Returns nicheId, heroKeyword, nicheLabel, marketplace (com/uk/de/...), and latestResearchDate per niche, plus pagination metadata (currentPage, pageSize, total, lastPage, hasNext, hasPrev). Narrow with `searchText` (label/keyword) or `searchAsin` (a competitor ASIN) instead of scanning pages; a page holds at most 50 niches, so the full list of a large account needs several calls.get_niche_keywordsUse this when the user asks about keywords, search terms, or search volume for a niche. Retrieves the master keyword list for the specified Niche — the relevant search terms monitored for ranking and performance metrics. For each keyword, returns search volume, relevancy (numeric score or "Outlier"), and competitor ASIN organic ranks (asinRanks: { ASIN -> rank | null }), plus `origin`: `mkl` (found by the dive), `manual` (added by hand with `add_niche_keywords`), `outlier` / `residue` (moved in from those lists). Only `manual`, `outlier` and `residue` keywords can be taken out with `remove_niche_keywords`. Keywords hidden by the niche's keyword exclusions are not listed; see `list_keyword_exclusions`. Also returns the latestResearchDate.list_keyword_exclusionsUse this to see which keywords are hidden from a niche's Master Keyword List, e.g. when a keyword the user expects is missing from `get_niche_keywords`. Returns the same lists the DataDive web app shows, oldest first: `exact` — each entry hides the one keyword that matches it exactly, with that keyword's `searchVolume` (0 when the niche has no such keyword); `phrase` — each entry hides every keyword that contains the phrase, with `excludedKeywordsCount` and the total `searchVolume` of the keywords it hides (not counting ones already excluded exactly). Exclusions hide keywords wherever they come from: the dive, the Outliers and Residue lists, and hand-added ones. Change them with `add_keyword_exclusions` and `remove_keyword_exclusions`.get_niche_rootsUse this when the user wants to find the highest-impact words across a niche's keywords, asks about 'keyword roots', or wants to prioritize terms for a listing. Retrieves the keyword lexical roots for the Niche — individual words or word-combinations extracted from the Master Keyword List (e.g. 'bluetooth headphones' yields roots 'bluetooth', 'headphones', 'bluetooth headphones'). Returns `roots` and `normalizedRoots` tables, each item with root, frequency (how many keywords contain it), broadSearchVolume (summed search volume of those keywords), and broadSearchVolumeRatio (0-1, relative to the top root), plus the per-keyword breakdowns and latestResearchDate.get_niche_competitorsUse this for competitor ASINs, product titles, BSR, sales/revenue benchmarks, or niche opportunity scoring. Retrieves the list of Competitors within the specified Niche along with Niche statistics. For the Niche: keyword statistics, opportunity evaluation, benchmark median values, and overall competitor strength assessment. For each Competitor: ASIN, product title, BSR, category and full category tree, sales, revenue, ratings, reviews, price, number of variations, image URL, total Ranking Juice, and ranking data. BSR supports ranking Competitors by sales position within mentioned category. For the Ranking Juice breakdown by title, bullets and description, use `get_ranking_juice`.get_ranking_juiceUse this when the user asks 'how do I rank higher', 'what's my ranking juice', or wants listing-optimization guidance. Retrieves the Ranking Juices for each Competitor within the specified Niche. Ranking Juice is DataDive's proprietary metric identifying the key factors driving search-ranking success for each Competitor's listing. Returns currentListing and optimizedListing breakdowns (rankingJuice + per-property contributions: title, bullets, description) plus per-competitor listing scores and the latestResearchDate.list_rank_radarsUse this to find a `rankRadarId` before calling `get_rank_radar_data`. Filter by `nicheId` if the user has already identified a niche. Retrieves a paginated list of Rank Radars — keyword-rank trackers monitoring organic and sponsored positions for specific ASINs over time. Each item includes id, status (ACTIVE, PAUSED or ARCHIVED), asin, marketplace, keywordCount, title, imageUrl, and summary metrics: top10KW, top10SV, top50KW, top50SV. Supports pagination metadata (currentPage, pageSize, total, lastPage, hasNext, hasPrev); a page holds at most 50 Rank Radars, so a large account needs several calls.get_rank_radar_dataUse this to analyze keyword ranking trends over time. Requires startDate and endDate (yyyy-mm-dd), at most 90 days apart. Retrieves historical keyword ranking data for the specified Rank Radar within the date range. Without `currentPage` and `pageSize` it returns every active keyword in one result. To read one page instead — faster for large Rank Radars — pass `currentPage` and/or `pageSize` (max 100) and continue with `currentPage` + 1 while `hasNext` is true. The response carries currentPage, pageSize, total, lastPage, hasNext and hasPrev; `total` is the Rank Radar's active keyword count. Paused keywords are not included. Each keyword has id, keyword, searchVolume, relevancy, ranks (per-day { date, organicRank, sponsoredRank, impressionRank }), and `highlights` — the user tags on this keyword. Each `highlights` entry is the same object `list_rank_radar_tags` returns (id, title, color, description, startAt, endAt, type, krtId, krtKeywordId); its `id` is the `tagId` the tag-management tools take. A rank of 101 means the product was not in the top 100 results that day. For PPC metrics use `get_rank_radar_ppc_data`; for Search Query Performance use `get_rank_radar_sqp_data`. Use after `list_rank_radars` to discover a `rankRadarId`.get_rank_radar_sqp_dataUse this when the user asks how shoppers search, click, add to cart and buy for the keywords of a Rank Radar — Amazon's Search Query Performance (SQP) data, from Brand Analytics. Requires startDate and endDate (yyyy-mm-dd), at most 90 days apart; 30 days or less keeps it fast. Each keyword's metrics are aggregated over the range: searchQueryVolume and searchQueryScore; impressions, clicks, cart adds and purchases, each as the total across all sellers (`*TotalCount`), this ASIN family's count (`*AsinCount`) and its share (`*AsinShare`); click, cart-add and purchase rates; and ctr/cvr for the market (`*Total`) and for this ASIN family (`*Asin`). `numberOfDaysWithData` says how many days of the range had SQP data; metrics are null when there is none, which is normal for low-volume keywords, recent dates (Amazon publishes SQP with a delay) and sellers without Brand Analytics. Results are paged by keyword: `data` holds one page, and the response carries currentPage, pageSize, total, lastPage, hasNext and hasPrev. `total` is the Rank Radar's active keyword count; to read every keyword, call again with `currentPage` + 1 while `hasNext` is true, using `pageSize` 100 for large Rank Radars. Paused keywords are not included. Each call counts toward API usage and is rate limited (about 60 requests/minute). Use after `list_rank_radars` to discover a `rankRadarId`.get_rank_radar_ppc_dataUse this when the user asks about advertising (Sponsored Products) performance for the keywords of a Rank Radar. Requires startDate and endDate (yyyy-mm-dd), at most 90 days apart; 30 days or less keeps it fast. Each keyword's metrics are aggregated over the range: sponsoredRank (median; 101 means not in the top 100 sponsored results), impressionRank and impressionRankShare; how many exact, phrase, broad and auto campaigns target it; organicSales, ppcSales, ppcSpend, costPerClicks, clickThroughRate, conversionRate, totalClicks, totalImpressions, totalOrders and acos. Metrics are null or 0 when the seller runs no ads on a keyword. Set `includeCampaigns` for the per-campaign breakdown. Results are paged by keyword: `data` holds one page, and the response carries currentPage, pageSize, total, lastPage, hasNext and hasPrev. `total` is the Rank Radar's active keyword count; to read every keyword, call again with `currentPage` + 1 while `hasNext` is true, using `pageSize` 100 for large Rank Radars. Paused keywords are not included. Each call counts toward API usage and is rate limited (about 60 requests/minute). For the seller's campaigns as a whole, use `list_ppc_campaigns`. Use after `list_rank_radars` to discover a `rankRadarId`.list_rank_radar_tagsUse this to find a `tagId` before calling `update_rank_radar_tag`, `delete_rank_radar_tag`, `add_rank_radar_tag_search_terms` or `remove_rank_radar_tag_search_terms`. Returns the user tags ("highlights") on the specified Rank Radar, ordered by title (case-insensitive, ascending). Each row carries `id`, `title`, `color`, `description`, `startAt`, `endAt`, `createdAt`, and `keywordCount` — the number of Rank Radar keywords this tag is applied to. The system "paused" tag (the one the quota pauser writes with a reserved colour) is not listed and cannot be addressed from these tools. Supports pagination metadata (currentPage, pageSize, total, lastPage, hasNext, hasPrev); a page holds at most 50 tags.create_rank_radarUse this to start tracking organic and sponsored keyword rankings for an ASIN within a niche. ⚠️ Spends Search Term tokens (cost scales with `numberOfKeywords`) and cannot be undone — set `confirm: true` only after the user approves the cost. Not safe to retry: each call spends tokens again and creates a separate Rank Radar — if a call errors or times out, check `list_rank_radars` instead of re-calling. The first call previews the creation and may return `warnings` alongside the cost note — for example that this product family is already tracked by another Rank Radar. Show every warning `message` to the user verbatim, before asking them to confirm; do not summarise it or decide on their behalf. A warning never blocks creation. Returns the new `rankRadarId`; read its data later with `get_rank_radar_data`. Requires `asin`, `numberOfKeywords` (min 1), and a `nicheId` from `list_niches`.- +31 more on the listing page
TrustRails MCP Server tools 2
search_productsHOW TO CALL THIS TOOL — read before every call: Decompose the user's request into filters first. Only what's left over goes in query. STEP 1: brand name → brand filter. STEP 2: product category → category filter. STEP 3: price → min_price/max_price. STEP 4: RAM, storage, screen size, resolution, refresh rate, wattage, Wi-Fi generation → constraints. STEP 5: what remains → query. BAD: query='Sony headphones under £200' | GOOD: brand='Sony', category='Headphones', max_price=200, no query. BAD: query='tablet' | GOOD: category='Tablets', no query. BAD: query='macbook neo' | GOOD: brand='Apple', category='Laptops', query='neo'. BAD: query='Samsung QLED TV' | GOOD: brand='Samsung', category='TVs', query='qled'. If brand+category alone cover what the user wants, omit query entirely. Only put differentiating terms in query: model lines (neo, ultra, oled), variants, model numbers (WH-1000XM5, s25 ultra). Query words must appear in the title, except words naming the category ('router' in Networking) and bare numbers or specs ('4070', '16GB'), which are ignored when finding products and only rank them. Put a model number with its prefix ('RTX 4070', not '4070') and check each title for it. Leave out use-case words like gaming, cheap or best. CROSS-CATEGORY NOTE: Gaming headsets → category='Headphones', query='gaming headset'. The Gaming category is consoles/controllers/accessories only. Always set lite=true (it still carries `attributes`). If 0 results, broaden the query or drop filters (but never present a near miss as meeting a requirement). Searches 26,000+ UK electronics products across 7 retailers with price comparison. Prices are in GBP. Every listing is new (refurbished and used are excluded). PRICE COMPARISON: for a final pick with offer_count > 1, get_product returns offers[] (sorted in-stock first, then cheapest): show the cheapest in-stock retailer, the other prices with the difference and the exact saving among in-stock offers. Before claiming a saving, read offers[].title (from get_product): they must name the same model; if they differ, don't claim one. Before recommending any pick, check its title is the product type asked for (not a cable, accessory or adapter). COMPARING SPECS: compare products from the `attributes` in the search results, not by calling get_product on each. Every spec known for a product is there as {status, value}, or {status, values} when conflicting, without sources; names and units are as in `constraints`. 'confirmed' (two or more retailers state the same value) and 'inferred' (one retailer's title states it) are both the product's spec: state the value. Only `conflicting` (retailers disagree: say so, don't pick one) or a missing name (unknown) needs a caveat. A product with no `attributes` has none of these seven specs known: say so only if the user asked about one. Call get_product only for your final 1-3 picks, and only when you need what search lacks: what only the retailer's description has (processor, GPU, ports, weight, battery), or every retailer's offer and buy link (search results carry only the best offer's purchase_url (cheapest in stock)). A pick with offer_count 1 needs no call unless the user asked for a description-only detail. Don't guess those details from titles. SPEC REQUIREMENTS: put exact requirements in `constraints`, not in query, and always set `category` (and brand if known) with `constraints`: a search of only specs is rejected. If a requirement is ambiguous (e.g. '16GB' could be RAM or storage), ask the user or search without that constraint. With constraints, every product has `constraint_status` per name: 'matched' = a retailer's title states a value that meets it. 'unverified' = not known to meet it: check `attributes[name]`, where `conflicting` means retailers disagree and missing means unknown. Never treat 'unverified' as a match or say a product meets a requirement because it was returned: tell the user it is unconfirmed. Products whose stated value fails are left out (`excluded_by_constraints`). Matched results come first, also with sort='price_asc'. With constraints, `total` counts the products that match every constraint and `unverified_total` the unverified products that passed the other filters (only some may be in `products`). If `total` is 0, say no product is known to meet every requirement and offer the unverified ones only as unconfirmed. If `candidates_truncated` is true, the first 2,000 candidates in the chosen sort order were checked and more exist: add a brand or category, or a narrower query, and search again before saying nothing matches. If the search was already narrowed, tell the user the results may be incomplete. STOCK: availability is in_stock, low_stock, out_of_stock or unknown (the retailer gave no stock signal: say so, don't assume). When availability is out_of_stock, mention it as an alternative and suggest checking back — do not silently omit it. purchase_url is a trustrails.app/go/ redirect through an affiliate link; TrustRails may earn a commission, and the price is the same. Colour variants have separate barcodes and are separate products: when price matters, search again without the colour or check other colours of the same model.get_productGet full details for a single product by ID. Returns `attributes`: structured specs read from retailer titles, each name mapping to {status, value, sources}; a conflicting one has values: [{value, sources}] instead of value and sources. Names and units as in the search constraints argument. status: 'confirmed' = two or more retailers state the same value; 'inferred' = one retailer's title states it; 'conflicting' = retailers state different values (none is picked, tell the user they disagree; a retailer can appear under two values, so read offers[].title to see which listing states which); a missing name = unknown. Also returns specs.description, the retailer's own prose: use it only for details attributes do not cover (processor, GPU, ports, weight, battery, features); if it doesn't give a detail, tell the user it isn't listed. It can describe another configuration or a maximum ('up to 32GB'), so it never overrides or fills in an attribute: if an attribute is missing or conflicting, that spec is unknown or unconfirmed, and you may mention what the description says only as 'the retailer's description mentions X, unconfirmed'. It also returns pricing, availability, delivery time, and all retailer offers with per-retailer pricing (offers[].stock is a unit count only when the retailer supplies one, otherwise null). Accepts both canonical product IDs and original retailer offer IDs. Use this after search_products only for your final 1-3 picks, and only when you need what search lacks: details only the description has, or every retailer's offer and buy link. Search results already carry `attributes` to compare specs.
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
DataDive
{
"mcpServers": {
"datadive": {
"command": "npx",
"args": [
"-y",
"@datadive-tools/mcp"
],
"env": {
"DATADIVE_API_KEY": "YOUR_DATADIVE_API_KEY_HERE"
}
}
}
}
TrustRails MCP Server
{
"mcpServers": {
"server-3": {
"command": "npx",
"args": [
"-y",
"@trustrails/mcp-server"
],
"env": {
"TRUSTRAILS_API_KEY": "YOUR_TRUSTRAILS_API_KEY_HERE"
}
}
}
}
Frequently asked questions
DataDive is categorized under E-Commerce and uses a local stdio subprocess. TrustRails MCP Server belongs to E-Commerce and uses a local stdio subprocess. Pick DataDive for e-commerce work and TrustRails MCP Server for e-commerce.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
DataDive has no declared pricing — check the project's own site. TrustRails MCP Server has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add datadive and server-3 as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, DataDive has a quality signal of 63/100 (Good) with 1 views, 0 installs and 1 GitHub stars. TrustRails MCP Server has 55/100 (Good) with 2 views, 0 installs and 0 GitHub stars.
