amazon-sorftime-research-MCP-skill: MCP-backed Amazon research skills for coding agents

The gap this fills: agent skills that call paid Amazon data APIs

Most Amazon seller research happens in a browser tab. You open a data service, export a CSV, paste it into a spreadsheet, and then redo the same sequence next week for a different ASIN. The repository liangdabiao/amazon-sorftime-research-MCP-skill packages that sequence as agent skills. Each skill is a named command such as /amazon-analyse or /category-select that a Claude Code or Codex agent can run, with the data coming from MCP servers rather than from copied text. The audience is narrow and specific: cross-border Amazon sellers and product researchers who already hold accounts with Sorftime, Sif, 西柚洞察 or 卖家精灵, and who work inside an agent that supports MCP. If you sell on Amazon but have none of those subscriptions, this repository gives you prompts with nothing behind them. The README's own framing is a toolset of nine skills, not an application.

Nine skills, four MCP backends, one shared output pattern

The skills divide by analysis object. Listing-level work goes through amazon-analyse, keyword work through keyword-research, review work through review-analysis, and category work through category-selection. Three further skills are bound to a single vendor's MCP: sif-amazon-research, xiyou-insight and sellersprite-amazon-research. The ninth, amazon-listing-builder, is different in kind. It does not analyse an existing market; it produces listing copy through an eight-step workflow that the README describes as analyse first, generate second, validate last, with the stated data-source priority of MCP over browser. The shared pattern is the deliverable set. The xiyou-insight skill writes to xiyou-insight-reports/{scenario}_{ASIN}_{site}_{date}/ containing report.md, data.json, dashboard.html and a raw/ folder of original MCP responses. The sellersprite skill writes market_report.md, market_report.html and research_data.json. Keyword-research adds CSV to the mix. This is the most concrete design decision in the repository: every run leaves an auditable directory, including the unprocessed API responses, so a later reviewer can check whether a conclusion came from the data or from the model.

How the MCP dependency actually shapes each workflow

The skill count is misleading if you read it as breadth. Behind the nine skills sit two MCP tool inventories of very different size. The 西柚 toolset is 17 APIs, split across ASIN basics (get_asin_info, get_asin_variations), keyword rank and traffic trends (get_asin_keyword_rank_hourly, get_asin_keyword_traffic_trends), traffic and order trends, and one advertising endpoint, get_asin_ad_change_trends. The 卖家精灵 toolset is 43 APIs and reaches further: product_research, keyword_miner, aba_research_trend, google_trend, market_price_distribution, competitor_lookup. The practical consequence is that the two skills are not interchangeable. If your question is what a competitor's ad spend looks like hour by hour, the 西柚 path has a dedicated tool. If your question is whether a keyword trend is rising on Google as well as Amazon, only the 卖家精灵 path has google_trend. The README does not document a fallback when an MCP call fails, and it does not describe caching between runs, so a repeated analysis re-queries the same endpoints.

Running a skill: commands and the one parameter that matters

Invocation is command-style inside the agent. The README gives these forms: /amazon-analyse {ASIN} {SITE}, /category-select "{品类}" {SITE}, /keyword-research {ASIN} {SITE}, /review-analysis {ASIN} {SITE}, and /product-research "{产品关键词}" {SITE}. The xiyou-insight skill instead takes a scenario flag plus named arguments, for example --scenario traffic_gap --own_asin --competitor_asins --site, or --scenario ad_monitoring --asin --site --keyword. The sellersprite skill exposes ten commands including /market-analysis, /listing-optimizer and /ad-optimizer. Two things stand out. First, SITE is a required positional argument in nearly every command, and the README never enumerates the accepted site codes, so you learn the valid values from the MCP service or by trial. Second, the data-source rule in amazon-listing-builder is explicit rather than advisory: core data must go through MCP, with the browser as a lower-priority fallback. That rule is worth respecting, because a browser-scraped number inside a generated listing cannot be traced the way a raw/ MCP response can.

Where the analysis is opinionated and where it is thin

Some of the scoring is specified. category-selection uses a five-dimension model covering market size, growth potential, competitive intensity, entry barriers and profit margin. review-analysis uses six pain-point dimensions and adds a numeric threshold: a second-hand or defective-item rate above 5% is flagged as dangerous, and service problems trigger an automatic warning. That 5% figure is the only quantitative threshold stated anywhere in the README, which makes it the one place you can check the tool's judgement against your own. Other parts are much less defined. The five-dimension model has no published weights, so the composite score is not reproducible from the documentation. The eight-dimension keyword classification (negation, brand, material, scenario, attribute, function, core, other) is a taxonomy, not a rule set; nothing states how a term that is both a material and a scenario word gets resolved. The 16 tactical selection strategies in the sellersprite skill read as hypotheses to test rather than as filters with cutoffs. Treat the reports as structured first drafts that a human still has to grade.

The limitation that decides adoption: no data without a subscription

Every skill in this repository is a consumer of an external MCP service. There is no bundled dataset, no scraping fallback documented in the README, and no offline mode. If your MCP credentials expire, a skill run does not degrade to partial output; it has nothing to analyse. The same applies to coverage: an ASIN or a site code that your plan does not include will simply return nothing, and the README does not describe how the skills report that case, so you may get a report file with empty sections rather than a clear error. There is a second constraint worth naming. The repository is Python, and the README describes product-research as deliberately lightweight scripts that only call APIs and render the dashboard, with the analysis itself done by the LLM. That is a reasonable split, but it means output quality tracks model quality and prompt quality, not script quality. Two runs of the same command on the same ASIN can differ. If you need a fixed, versioned methodology that produces identical numbers for an auditor, this is the wrong tool.

What you would use instead, and how the approach differs

The obvious alternative is the vendor dashboards themselves: log into 卖家精灵 or 西柚, run the market or keyword report, export it. The difference is not data quality, since both paths hit the same APIs. It is repeatability and traceability. A dashboard export gives you the vendor's chosen columns and no record of which calls produced them. This repository gives you a directory per run, a raw/ folder of MCP responses, and a Markdown report the agent wrote on top of them. The cost is that you own the orchestration: the agent, the MCP configuration, the credentials, and the reading of whatever the model concluded. The second alternative is writing your own MCP client against the same 17 or 43 endpoints. That buys you exact control over scoring weights and output schema, at the price of rebuilding the prompt scaffolding, the eight-step listing workflow and the three-format report rendering that this repository already ships.

Maintenance, licence and what the repository does not state

The repository's most recent push is dated 2026-07-08 and it is not archived, so it is active rather than abandoned. There are no retrieved releases, which means there is no tagged version to pin; you track the main branch or a commit hash of your own choosing. Maintenance cost here is mostly external. Each MCP service can change its endpoint list, and when it does, the skill that names that endpoint breaks, so the update burden sits with whoever watches those services, not with the Python. The licence is listed as unknown, and the README does not state one. That matters more than usual for this project because it is a prompt-and-script layer over commercial data services: without a licence you have no stated grant to redistribute the skill files, and the data those skills retrieve is governed by your separate agreement with each MCP provider. Confirm the licence with the maintainer and check each provider's terms before shipping these skills to a team. That is a factual gap in the repository, not a legal opinion.

Editorial conclusion

Adopt it if your team already pays for at least one of these MCP data services and you want repeatable, file-producing analysis runs inside Claude Code or Codex rather than manual dashboard clicking. Do not adopt it if you have no MCP subscription, because none of the nine skills generate data on their own. Before committing, verify three things: the licence file, which MCP servers the skill you need actually calls, and whether the Amazon site codes you sell in are covered by your plan.

Official sources

1. Issues
2. liangdabiao/amazon-sorftime-research-MCP-skill on GitHub
3. Project website
4. README