A
licenseNot graded
qualityC
maintenanceExposes Amazon Selling Partner API tools for sellers to manage orders, inventory, listings, pricing, analytics, and reports via natural language.
14 npm
1
AGPL 3.0
SellerSprite MCP
by JieXi-11
This server lets AI assistants query SellerSprite product, keyword, traffic, market, and review data through a local MCP using your logged-in browser session.
Check whether SellerSprite web and extension login credentials are available.
Open a dedicated Chromium browser login window and optionally wait for you to sign in.
Discover and filter available SellerSprite operations by name, purpose, endpoint, status, or authentication type.
Inspect an operation’s parameters, defaults, prerequisites, authentication requirements, request details, and verification status.
Execute operations for product research, competitor lookup, ASIN details and trends, keyword reverse lookup and mining, traffic sources, ABA, market concentration/distribution, and review filtering.
Return structured data from logged-in SellerSprite web or extension endpoints.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@SellerSprite MCPfind top keywords for yoga mats"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
SellerSprite MCP
让 AI 助手通过 MCP 查询卖家精灵的产品、关键词、流量、市场和评论数据，返回结构化结果。
第一次使用，只需完成：安装 → 添加 MCP → 登录 → 查询。 MCP 在你的电脑上运行，使用专用浏览器里的卖家精灵登录态；不需要部署服务器，也不需要填写卖家精灵 API Key。可查询的数据仍取决于账号权限、数据是否已采集及上游接口状态。
文档导航
你要做什么 | 从这里开始 |
第一次安装并使用 | 下方「快速开始」 |
不知道怎么向 AI 提问 | |
找不到命令、登录失败、切换端口或浏览器 | |
从源码运行、测试或维护项目 | |
查某个操作的完整参数 | 让 AI 调用 |
Related MCP server: Amazon Ads API MCP SDK
快速开始
1. 安装到本机
先准备：
Node.js 22 或更新版本（包含 npm）。
Git，供 npm 从 GitHub 安装。
Chrome、Edge、Brave 或 Chromium 浏览器。
卖家精灵账号，以及支持本地 STDIO MCP 的 AI 客户端。
在 Windows PowerShell 或 macOS / Linux 终端执行：
node --version
npm --version
git --version
npm install -g git+https://github.com/JieXi-11/SellerSprite.git
npm list -g sellersprite-mcp --depth=0检查结果： Node 版本至少为 v22，最后一条命令列出 sellersprite-mcp。安装完成后重启 AI 客户端，让它读取更新后的命令路径。
这条安装路线不需要克隆仓库，也不需要执行 npm start。安装失败或客户端找不到命令时，见启动问题。
2. 在 AI 客户端添加 MCP
下面三种方式任选一种，不要重复添加同名服务。
方式 A：客户端有 MCP 配置表单
字段 | 填写内容 |
名称 |
|
类型 / 传输方式 |
|
启动命令 |
|
参数 | 留空 |
环境变量 | 键： |
9222 是本机浏览器调试端口，不是远程 MCP 服务地址。不要将它填入 HTTP / SSE 服务地址栏。
方式 B：客户端接受 MCP JSON 配置
把下面配置合并到客户端的 MCP 配置中，保留已经配置的其他服务。配置文件位置由客户端决定。
{
"mcpServers": {
"sellersprite": {
"command": "sellersprite-mcp",
"args": [],
"env": {
"SELLERSPRITE_CDP_URL": "http://127.0.0.1:9222"
}
}
}
}也可复制 mcp.example.json。JSON 是客户端配置，不能直接粘贴到 PowerShell 中执行。
方式 C：使用已安装的 Codex CLI
codex mcp add sellersprite --env SELLERSPRITE_CDP_URL=http://127.0.0.1:9222 -- sellersprite-mcp
codex mcp get sellersprite没有 codex 命令时，使用方式 A 或 B。客户端配置能力以其版本为准，参见 Codex MCP 文档。
检查结果： 保存并重新加载 MCP 后，AI 应能调用 sellersprite_session_status 和 sellersprite_login 等工具。若没有工具，先解决启动问题，不要反复登录网页。
3. 在 MCP 专用浏览器中登录
把下面这句话发给 AI：
使用 SellerSprite MCP 检查登录状态。若尚未就绪，调用
sellersprite_login，waitSeconds 设为 0，打开登录窗口让我登录。在弹出的浏览器里登录卖家精灵，然后对 AI 说：
我已登录，请重新调用 sellersprite_session_status 检查状态。注意这三个区别：
专用浏览器与日常浏览器的登录态不共享。 在原来的浏览器中已登录，不代表 MCP 也已登录。
网页与扩展是两套登录态。 需要关键词反查、销量趋势等扩展功能时，还要在同一个专用浏览器内安装并登录卖家精灵扩展；只用网页功能不必先安装扩展。
使用时保持专用浏览器运行。 登录信息会保存在专用目录，下次可复用；关闭后可让 AI 再次调用登录工具打开。
检查结果： ready: true 表示已读到网页 Cookie；需要扩展的操作还应检查 extension.valid: true。这些是本地凭据检查，不保证账号有权限或上游接口一定成功，见状态字段说明。
Windows 自动启动使用系统默认的 HTTPS 浏览器；如果默认是 Firefox 等不支持的浏览器，请指定浏览器路径。
4. 发起第一次查询
先用不需要请求卖家精灵数据的功能目录检查工具连接：
调用 sellersprite_list_operations，查找“关键词”相关功能。再发起一个实际查询：
使用 SellerSprite MCP 查询美国站 ASIN B09BF6XJY1 的详情。
先检查登录状态，再查找并阅读 ASIN 详情操作的参数说明，然后查询。
如果返回登录、权限或数据错误，请如实说明，不要编造数据。将示例 ASIN 替换为你的目标商品。返回实际商品数据才说明这次查询成功；返回空结果时先核对站点、ASIN 和账号权限。
查询示例
复制后替换站点、ASIN、类目和日期条件；由 AI 先读取操作说明，确认接口支持哪些筛选。
选品：
使用 SellerSprite MCP 分析美国站最近可用周期内增长较快的新品。
优先考虑上架三个月内、非季节性产品，排除个护、医疗和小家电。
先检查操作支持的筛选项；返回 ASIN、上架时间、增长指标、统计周期和数据来源。
如果缺少历史对比数据，不要仅凭当前销量判断“快速增长”。竞品与关键词：
分析美国站 ASIN B09BF6XJY1 的关键词和流量来源。
先读取关键词反查、流量来源相关操作的说明，检查扩展登录状态。
区分自然流量和广告相关数据，标注数据周期，并提出需要验证的优化方向。评论痛点：
读取美国站 ASIN B09BF6XJY1 的低星评论，归纳产品缺陷、使用困难和改进方向。
先读取 review 操作说明。如果账号内没有该 ASIN 的评论分析语料，请告知我先采集。
说明实际读取的页数和评论数量，不要把少量样本当成全部评论。工具与功能
服务提供 5 个 MCP 工具，通过操作目录调用 40 项已映射功能。目录中的验证记录反映历史验证结果，不代表本次安装已完成全部在线验证。
工具 | 用途 |
| 检查网页 Cookie 和扩展凭据是否可读取 |
| 打开专用浏览器登录页，可等待用户登录 |
| 按名称、用途等查找操作 |
| 查看参数、默认值、认证要求和前置条件 |
| 执行操作，返回结构化数据 |
推荐顺序：session_status → 按需 login → list_operations → describe_operation → call。
主要功能包括产品研究、竞品查询、ASIN 详情与趋势、关键词反查与挖掘、关联流量、ABA、市场集中度与分布、评论筛选。完整参数以 data/operations.json 和工具返回的 tool_input 为准。
更新与日常使用
日常使用直接打开 AI 客户端，检查登录状态后查询，无需重复安装。更新时执行：
npm install -g git+https://github.com/JieXi-11/SellerSprite.git然后重启 MCP 服务或 AI 客户端。正常更新不会删除专用浏览器目录中的登录信息。
账号密码只在卖家精灵网页或扩展中输入，不要发送给 AI。默认模式不把 Cookie、扩展 Token 写入项目文件，但登录信息会保存在专用浏览器目录中；请勿分享该目录，也不要将浏览器调试端口开放到公网。
Available Tools
5 toolssellersprite_callB
Execute a SellerSprite logged-in web or extension operation using the documented MCP tool input.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Parameters from the operation tool_input returned by sellersprite_describe_operation. | |
| operation | Yes | Operation name returned by sellersprite_list_operations. |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only mentions 'logged-in' which hints at authentication requirements, but fails to disclose side effects, rate limits, destructive behavior, or response format. For a generic execution tool, this is insufficient.
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 a single sentence with no wasted words, but it is so concise that it sacrifices important context. It could be expanded without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that it is a generic execution tool relying on external operation definitions (from sellersprite_list_operations and sellersprite_describe_operation), the description fails to mention these dependencies or how to obtain the required parameters. No output schema is provided, leaving return values ambiguous.
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% for both parameters, so the description adds no extra meaning beyond what the schema already provides (operation name and params from sibling tools). The phrase 'using the documented MCP tool input' is vague.
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 clearly states the tool executes a SellerSprite operation, specifying the verb 'execute' and the resource 'SellerSprite operation'. It also notes the requirement of being logged in, but does not differentiate from sibling tools like sellersprite_list_operations or sellersprite_describe_operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool should be used when executing an operation after obtaining it from sellersprite_list_operations, but it lacks explicit guidance on when to use it versus alternatives, no exclusions, and no mention of prerequisites like logging in first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sellersprite_describe_operationB
Explain one operation: purpose, Agent input, actual logged-in web request, defaults, response, prerequisites, and verification.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes |
TDQS
B3.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals that the tool returns detailed breakdown (purpose, request, response, etc.), indicating read-only behavior. It does not explicitly state idempotency but the listed output components imply no side effects.
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?
Single sentence that begins with the core purpose, listing key components efficiently. Could be slightly more structured but is clear and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and no output schema, the description adequately outlines what is returned. However, it omits that the operation should come from list_operations, which would help agent ensure validity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'operation' lacks schema description, and the tool description merely says 'one operation' without specifying format or source (e.g., from list_operations). The description adds minimal meaning beyond the schema field name.
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 clearly states it explains one operation, listing components like purpose and request. It is reasonably distinct from sibling tools which list, call, or check session status, though explicit differentiation is missing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use before calling an operation, but provides no explicit guidance on when to use vs alternatives or when not to use it. Missing context about prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sellersprite_list_operationsB
List available SellerSprite logged-in web and extension operations with their purpose and endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional case-insensitive operation-name, title, description, or endpoint filter. | |
| status | No | Optional exact mapping-status filter. | |
| authentication | No | Optional authentication filter. |
TDQS
B3.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like auth requirements or data safety. It only states the operation, lacking any behavioral details beyond listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence that efficiently communicates the tool's purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema, the description mentions the output includes purpose and endpoint. Could be more complete by hinting at result format or pagination, but adequate.
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 coverage is 100% with parameter descriptions. The tool description adds no extra parameter meaning, meeting the baseline for high coverage.
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 clearly states the tool lists available operations with their purpose and endpoint. It distinguishes from siblings like sellersprite_describe_operation (single operation) and sellersprite_call (executes operations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs siblings like describe_operation or call. Usage context is purely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sellersprite_loginB
Open SellerSprite in the local default Chromium browser and wait for the user to complete sign-in. Credentials stay in the browser.
| Name | Required | Description | Default |
|---|---|---|---|
| waitSeconds | No | Seconds to wait for sign-in. Use 0 to only open the login window. |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions that credentials stay in the browser, indicating session persistence. However, with no annotations, it should disclose more about default behavior (e.g., what happens on timeout, whether it returns a status, or if it can be called multiple times).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no extraneous information. It front-loads the core action and efficiently includes a key behavioral note about credential persistence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a login tool with one optional parameter and no output schema, the description covers the essential flow: opening browser, waiting, and credential persistence. It could be slightly more explicit about post-sign-in behavior (e.g., does it return immediately or close the browser?), but it is largely sufficient.
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?
The schema has 100% description coverage for the single parameter waitSeconds, so the baseline is 3. The tool description does not add additional meaning beyond the schema's own parameter description.
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 clearly states the tool opens SellerSprite in the local default browser and waits for user sign-in. It distinguishes itself from sibling tools by being the only login-related tool, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or prerequisites. It is implied that login is needed before using other SellerSprite tools, but explicit direction is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sellersprite_session_statusA
Check the attached Chrome SellerSprite web and extension login state without exposing credentials.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It transparently states the tool is a read-only check that does not expose credentials. However, it doesn't mention if any state changes occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single clear sentence with no wasted words. Front-loaded with action and scope.
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?
For a simple status check tool with no parameters and no output schema, the description is complete. It covers purpose and a key behavioral trait (no credential exposure).
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?
No parameters in input schema, and schema coverage is 100% trivially. Description adds no parameter info but is unnecessary. Baseline score of 4 is appropriate.
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 clearly states the tool checks login state of SellerSprite web and extension without exposing credentials. It uses a specific verb-resource pair and distinguishes from siblings like sellersprite_login.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (before other operations), but lacks explicit when-not-to-use or alternative tools. Sibling tools exist but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
5 tool updates
v0.1.0- First observed
sellersprite_call - First observed
sellersprite_describe_operation - First observed
sellersprite_list_operations - First observed
sellersprite_login - First observed
sellersprite_session_status
TDQS
A3.7/5.0
Scored across 5 tools
Disambiguation5/5
Each tool serves a distinct purpose: listing operations, describing one, executing one, checking session, and logging in. There is no overlap or ambiguity.
Naming Consistency4/5
All tools use the 'sellersprite_' prefix, but the verb-noun pattern is not perfectly consistent: 'sellersprite_call' and 'sellersprite_login' lack a noun component, while others include one. Still, the naming is predictable and readable.
Tool Count5/5
With 5 tools, the server is well-scoped for its purpose of managing SellerSprite operations. Each tool is necessary and none are redundant.
Completeness5/5
The tool set covers the full lifecycle of interacting with SellerSprite operations: login, list operations, describe an operation, execute it, and check session status. No obvious gaps for the intended domain.
Maintenance
ActivityMaintained
ResponsivenessUnresponsive
Related MCP Connectors
AMZScout Skill + MCP gives AI agents live access to real Amazon marketplace data across 14 Amazon marketplaces. Analyze any ASIN, validate product ideas, research niches, compare competitors, discover profitable keywords, and build data-driven PPC strategies using trusted Amazon insights instead of AI assumptions. Works with Claude, ChatGPT, Cursor, and any other MCP-compatible AI client. To connect, you'll need an AMZScout API plan and authorize your account. Get access and view pricing here: https://learn.amzscout.net/amazon-product-api-for-ai-agents
Real-time Amazon product, seller, and search data for AI agents across 21 marketplaces.
- WisePPCOAuthcom.wiseppc
Amazon Ads and Seller Central data for your AI agent: ads, search terms, profit and listings.
Amazon Seller Central, Ads and Vendor Central in ChatGPT & Claude. 106 tools; writes need approval.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables AI-powered advertising applications by providing MCP-compliant tools to interact with Amazon Ads API for campaign management, reporting, and optimization.3MIT
- AlicenseNot gradedqualityBmaintenanceAMZScout Skill + MCP gives AI agents live access to real Amazon marketplace data across 14 Amazon marketplaces. Analyze any ASIN, validate product ideas, research niches, compare competitors, discover profitable keywords, and build data-driven PPC strategies using trusted Amazon insights instead of AI assumptions. Works with Claude, ChatGPT, Cursor, and any other MCP-compatible AI client.1MIT
- AlicenseAqualityBmaintenanceEnables AI agents to access Amazon commerce intelligence, WIPO design-patent data, Google Trends, and local market data through 19 business data tools via a stdio bridge to a hosted MCP server.2113 npm1MIT