This server turns your Sell The Trend account into an AI-drivable product research engine by controlling a real browser, enabling comprehensive dropshipping niche research and automated PDF report generation.
Session Management
Check login/authentication status (stt_status)
Log in with human-in-the-loop Cloudflare verification (stt_login)
Persist browser sessions for future runs (stt_save_session)
Product Research
Search NEXUS by keyword/niche for structured product data — name, sell price, orders, and sales (stt_research)
Search for products by keyword and return raw product cards (stt_search_products)
Browse handpicked/winning products (stt_winning_products)
PDF Report Generation
Generate a detailed PDF dossier for any niche/keyword (stt_research_report), including:
Full product list with economics (cost, profit, saturation %)
Deep dives into top products with AI insights
Competitor stores with URLs and revenue
AliExpress supplier links
Facebook Ad Library links and targeting suggestions
Product images embedded in the report
Browser Automation Primitives
Navigate to any Sell The Trend page or URL (stt_navigate)
Take a text snapshot of the current page (stt_snapshot)
Extract data via CSS selectors (stt_extract)
Click elements by selector or visible text (stt_click)
Fill input fields and optionally submit forms (stt_fill)
Execute arbitrary JavaScript in the page context (stt_evaluate)
Capture PNG screenshots of the current page (stt_screenshot)
These low-level browser tools also give access to any dashboard area, including ad finders, spy tools, and store intelligence features.
Retrieves AliExpress supplier information for products discovered during Sell The Trend research.
Generates links to Facebook Ad Library and provides targeting data for products researched through Sell The Trend.
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., "@Sell The Trend MCP Research the catnip niche and give me a detailed PDF report."
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.
An MCP (Model Context Protocol) server that turns your Sell The Trend account into an AI-drivable product-research engine, and generates detailed, decision-ready PDF dossiers for any niche.
Sell The Trend has no public API, so this server drives your own logged-in account through a real browser (Playwright). It gives an AI assistant (Claude Code, etc.) generic browser primitives plus purpose-built research + reporting tools.
⚠️ Personal-use tool, your own paid account, your own data. Automating a SaaS dashboard can be against its Terms of Service. Use responsibly and at your own risk. Not affiliated with, or endorsed by, Sell The Trend.
🔎 stt_research: search NEXUS for a niche/keyword → structured product data (name, sell price, orders, sales).
📄 stt_research_report: research a keyword and generate a detailed PDF dossier: full product list + deep dossiers for the top products (cost, profit, saturation %, AI insights, competitor stores + revenue + URLs, AliExpress suppliers, Facebook Ad Library link, FB targeting, product image).
🧭 Browser primitives (stt_navigate, stt_snapshot, stt_extract, stt_click, stt_fill, stt_evaluate, stt_screenshot): reach anything in your dashboard (ad finders, spy tools, store intel…).
🔐 stt_login / stt_status: one-click human login (handles the "verify you are human" check) + session status.
Related MCP server: merch-connector
Node.js 18+
A Sell The Trend account (free trial works)
Claude Code (or any MCP client)
git clone https://github.com/mfahadiqbalofcl/sellthetrend-mcp.git
cd sellthetrend-mcp
npm install
npx playwright install chromium # one-time browser download
cp .env.example .env # then add YOUR Sell The Trend login (never commit it)Open .env and set:
STT_EMAIL=you@example.com
STT_PASSWORD=your-password
STT_HEADLESS=false # keep false, STT blocks headless loginsclaude mcp add sellthetrend -s user -- node /ABSOLUTE/PATH/TO/sellthetrend-mcp/server.mjsThen restart Claude Code so the tools load. Verify: claude mcp list → sellthetrend ✔ Connected.
STT guards login with a Cloudflare "verify you are human" check that only a human can pass. So:
In Claude, call stt_login (or just ask: "log into Sell The Trend").
A browser window opens (email + password pre-filled). Tick "verify you are human" → Sign in.
The session is held by the running server and reused for every tool call.
(Standalone alternative when the server isn't running: node login.mjs.)
"Research the catnip niche on Sell The Trend and give me a detailed PDF report." → drops a dossier in ./reports/.
"Find winning cat dental products with their cost, profit and saturation."
"Open the Facebook Ad finder and show me the top pet ads."
"Screenshot my NEXUS page."
Reports are saved to ./reports/winning-product-report-<keyword>-<timestamp>.pdf. Each has a summary table + per-product dossiers with embedded image, economics, AI insights, competitor stores (URLs + revenue), AliExpress suppliers, FB Ad Library link, and targeting.
.env)Var | Purpose |
| your login (pre-fills the form) |
|
|
| optional residential proxy to avoid IP rate-limits |
| optional overrides if STT changes its UI |
"verify you are human" loops / logged out → call stt_login again (session expired). Never kill -9 the browser. That discards the session.
Empty results → STT changed selectors; use stt_navigate + stt_snapshot to find the new path and set overrides in .env.
IP blocked → add a residential proxy via STT_PROXY_*.
server.mjs # the MCP server (14 tools)
report.mjs # parser + detailed PDF report engine
login.mjs # standalone one-time manual login
make_report.mjs # generate a report from sample data
smoke.mjs # lists the tools (sanity check)
reports/ # generated PDFs (gitignored)For personal research on your own account. Respect Sell The Trend's Terms of Service and robots policies. The author/operator is responsible for how it's used. MIT-licensed code; the data belongs to Sell The Trend and its sources.
Click an element by CSS selector or visible text.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| selector | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the burden. It does not disclose behavioral traits such as whether it waits for the element, what happens if the element is not found, or if it scrolls into view. For a DOM interaction tool, these are critical missing details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that front-loads the core information. Every word is necessary and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is insufficient for complete understanding. Important context like behavior on missing elements, multiple matches, and interaction with dynamic pages is omitted. A richer description is needed for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It connects 'selector' to CSS selector and 'text' to visible text, which is basic but helpful. However, it doesn't specify that only one should be provided, the format of the selector, or any precedence between the two.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Click'), the resource ('element'), and the two identification methods (CSS selector or visible text). It differentiates from sibling tools like 'stt_fill' and 'stt_navigate', which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no mention of prerequisites, when not to use it, or comparison to sibling tools. The description simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run JavaScript in the page and return the JSON-serializable result. The escape hatch for anything the other tools don't cover.
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | JS expression evaluated in page context, e.g. "document.querySelectorAll('.product-card').length" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states that JavaScript is run and a JSON result is returned, but does not disclose potential side effects, security implications, or limitations such as script errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and every word is necessary. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the lack of output schema, the description covers the basics but could be more complete by mentioning error handling or safety considerations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a description for the script parameter. The tool description adds context by stating the result is JSON-serializable and that this is an escape hatch, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs JavaScript and returns a JSON-serializable result, and explicitly calls it the 'escape hatch for anything the other tools don't cover,' distinguishing it from sibling tools that perform specific actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use (as an escape hatch when other tools are insufficient) but does not provide explicit when-not-to-use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract data from the current page via a CSS selector. Returns innerText (or a given attribute) of each match.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| selector | Yes | ||
| attribute | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns innerText or an attribute per match, and implies it operates on the current page. However, it does not mention side effects, authentication needs, rate limits, or behavior when no matches are found. With no annotations, this is a moderate disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the core functionality efficiently. However, it lacks a brief breakdown of parameters or usage hints, which would improve structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description leaves out important details like what happens with multiple matches, the default limit, and any prerequisites. It is incomplete for a tool with three parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'selector' implicitly and 'attribute' explicitly (via 'or a given attribute'), but completely omits the 'limit' parameter. With 0% schema description coverage, the description fails to fully compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts data from the current page using a CSS selector and returns innerText or a specified attribute. This is a specific verb+resource pair that distinguishes it from siblings like stt_click or stt_navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as stt_evaluate or stt_snapshot. There are no exclusions, prerequisites, or context for optimal use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill an input by CSS selector; optionally submit with Enter.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | ||
| submit | No | ||
| selector | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions the core action and optional submit but does not disclose error handling, whether existing text is cleared, or other 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action and optional behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple fill action with 3 parameters, but lacks details on error conditions, preconditions, or return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description adds minimal meaning beyond parameter names: 'selector' implies CSS selector, 'submit' implies Enter key. 'value' is not elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fills an input by CSS selector and optionally submits with Enter. It distinguishes from siblings like stt_click (clicking) and stt_extract (extracting).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open Sell The Trend login in THIS server's browser window and wait (up to 5 min) for you to solve the human-check + sign in. Run once per server start if stt_status shows loggedIn:false. (Server must be headful: STT_HEADLESS=false.)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description carries full burden. It discloses that it opens a browser, waits up to 5 minutes for human check, and requires a headful server. Does not describe error handling or timeout behavior beyond the 5 min wait, but is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no extraneous information. Every word is necessary and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description covers essential behavioral and prerequisite information. Could benefit from more detail on error cases, but is adequate for a login tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4 applies. The description adds no parameter information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool opens the Sell The Trend login page in the server's browser and waits for human interaction. Specifies condition to run (loggedIn:false) and distinguishes from sibling tools that perform other actions like clicking, navigating, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to use (if stt_status shows loggedIn:false) and prerequisite (headful mode). Does not explicitly state when not to use or mention alternatives, but the context is sufficient for an agent to understand its role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Sell The Trend NEXUS for a niche/keyword and return STRUCTURED product data (name, sell price, orders, sales). The reliable way to pull winning-product data.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only states return structure but does not disclose behavioral traits like read-only nature, authentication needs, rate limits, or whether it modifies data. This is insufficient for a tool that may have 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, no filler, and front-loads the action and result. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the core functionality and return structure adequately. It could mention the scope (e.g., Shopify product data) but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the only parameter (keyword). The description adds that the keyword is a 'niche/keyword', which is minimal but clarifies the input role. It does not specify format, allowed values, or constraints beyond the required flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: search a specific resource (Sell The Trend NEXUS) for a niche/keyword and return structured product data. It distinguishes from siblings like stt_search_products by emphasizing 'winning-product data' and structured output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for pulling winning-product data, but does not explicitly state when not to use it or compare to alternatives like stt_winning_products or stt_search_products. The guidance is clear but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Research a niche/keyword on NEXUS and generate a DETAILED PDF dossier under ./reports/: full product list + deep dossiers (cost, profit, saturation, stores+URLs, suppliers, Facebook ad library, targeting, image) for the top products. Use this by default whenever researching a product.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | ||
| deepCount | No | how many top products to deep-dive (default 3) | |
| recommendation | No | optional HTML recommendation paragraph to embed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the output is a PDF dossier under ./reports/ with specific content (product list, dossiers). Missing details on side effects, authentication, filesystem behavior, or error handling. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose and output. No wasted words. The usage recommendation is included concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and three parameters, the description covers the main output structure but omits details on parameter behavior, return value, and error conditions. It is adequate for a straightforward research tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 67% description coverage. The tool description adds context for 'keyword' and 'deepCount' (deep dossiers) but does not mention the 'recommendation' parameter. It adds some meaning but does not fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: research a niche/keyword and generate a detailed PDF dossier. It distinguishes from sibling tools by saying 'Use this by default whenever researching a product,' implying it is the comprehensive research tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit when-to-use guideline: 'Use this by default whenever researching a product.' However, it does not mention when not to use it or provide specific alternatives, but the context of sibling tools makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persist the current browser session after a manual login so future runs stay logged in.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral transparency. It only states that the session is persisted, without disclosing what exactly is saved, whether it overwrites previous sessions, or any potential side effects. This lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every word contributes to understanding the tool's function and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and is relatively simple, the description covers the core idea. However, it could be improved by explicitly stating that it must be called after a successful manual login and mentioning the expected state (e.g., cookies persisted). It is minimally adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so per the baseline rule, a score of 4 is appropriate. The description adds meaning by explaining the purpose and usage context, which the empty schema does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'persist' and the resource 'current browser session', and explains the purpose ('so future runs stay logged in'). It distinguishes from the sibling tool stt_login by specifying it is for use after a manual login, making the purpose highly specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating 'after a manual login', indicating when to use this tool. However, it does not explicitly list alternatives or when not to use it, though the context is sufficient given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a PNG screenshot of the current page so you can see the dashboard.
| Name | Required | Description | Default |
|---|---|---|---|
| fullPage | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose output format (e.g., returns image data or URL) and behavioral traits like full-page support. It only states 'PNG screenshot', leaving critical behavioral details unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but omits essential details, making it insufficiently structured for effective agent guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description still lacks information about what the tool returns and how the fullPage parameter affects behavior, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0% and the description does not mention the 'fullPage' parameter, failing to add any meaning beyond the raw schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool takes a PNG screenshot of the current page, but it over-specifies by mentioning 'dashboard' and does not differentiate from sibling tool stt_snapshot, leaving ambiguity about their differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like stt_snapshot, nor are there any exclusions or usage contexts mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Sell The Trend product research for a niche/keyword and return found product cards. Best-effort — if cards are empty, use stt_navigate + stt_snapshot to find the real path/selector and set STT_SEARCH_PATH / STT_CARD_SELECTOR in .env.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions a best-effort nature and fallback, but does not cover other traits like authentication, side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no wasted words, and front-loads the purpose. Every sentence is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is incomplete. It does not explain the return format, error handling, or prerequisites like login, leaving significant gaps for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and one required parameter, the description adds that 'query' is a niche/keyword, providing basic meaning. However, it does not specify format or constraints, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for a niche/keyword and returns product cards. However, it does not explicitly distinguish from sibling tools like stt_research or stt_winning_products, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides fallback guidance if cards are empty, implying when to use other tools. But it lacks explicit when-to-use alternatives or exclusions, so guidance is moderate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a text snapshot of the CURRENT page (title, url, visible text, links, buttons).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavior. It indicates a read-only operation returning text content, but it does not disclose potential limitations (e.g., text truncation, handling of dynamic content) or whether it modifies state. The description is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose. It includes key details without excess. Minor improvement: could use bullet points for clarity, but it's already concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description should ideally specify the output format structure. It lists what is included but not how it is formatted (e.g., plain text, JSON). This gap leaves some ambiguity about the tool's exact output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100%. Per guidelines, 0 parameters yields a baseline of 4. The description does not add parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a text snapshot of the current page, listing specific elements (title, url, visible text, links, buttons). It distinguishes from siblings like stt_screenshot (image) and stt_extract (specific data extraction).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for obtaining a broad textual overview, but it does not explicitly state when to use it versus alternatives like stt_extract or stt_evaluate. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report Sell The Trend session/auth status and whether you're logged in.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description clearly indicates it's a read-only status report without side effects. Simple and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no unnecessary words. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a tool with no parameters and no output schema. Sufficient for the agent to understand what it does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% trivially. Baseline 4 applies per rubric for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses verb 'Report' and specifies resource 'Sell The Trend session/auth status and whether you're logged in.' It clearly distinguishes from sibling tools like stt_login and stt_save_session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context for checking login status, but no explicit when-not-to-use or alternatives are provided, though siblings imply different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open Sell The Trend winning/handpicked products and return a snapshot. Tune STT_WINNING_PATH in .env if the default isn't right.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits such as read-only vs. mutating, prerequisites (e.g., need login), side effects, or what 'open' entails (e.g., navigates to a page?). It only says 'return a snapshot', which is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first states the purpose, the second provides a configuration tip. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description adequately states the goal but lacks detail on what the snapshot contains (e.g., list of product IDs, full details, etc.). It also does not address potential prerequisites or error conditions. Competent but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline is 4 per instructions. The description adds context about an environment variable (STT_WINNING_PATH) that configures behavior, which is a meaningful addition beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens and returns a snapshot of winning/handpicked products from Sell The Trend. It distinguishes from siblings like stt_search_products by implying this is a curated set, not a search. However, it could be more precise about whether 'winning' and 'handpicked' are the same or different.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. alternatives (e.g., stt_search_products, stt_snapshot). The only hint is a configuration note about .env, which does not help with tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0stt_clickstt_evaluatestt_extractstt_fillstt_loginstt_navigatestt_researchstt_research_reportstt_save_sessionstt_screenshotstt_search_productsstt_snapshotstt_statusstt_winning_productsScored across 14 tools
Tools have mostly distinct purposes, but stt_research, stt_research_report, and stt_search_products overlap in searching products. Descriptions clarify differences (structured data vs. PDF vs. raw cards), so agents can differentiate.
All tools use the 'stt_' prefix with consistent verb_noun snake_case (e.g., stt_click, stt_extract, stt_research_report). No mixed conventions or ambiguous names.
14 tools is well-scoped for a platform automation server covering login, navigation, interaction, data extraction, research, and reporting. No excess or deficiency.
Covers major workflows: login, navigation, interaction, research, reporting. Minor gaps like logout or advanced filtering, but core user tasks are supported.
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Get recommended by Amazon's AI. Hosted MCP server for Amazon listing compliance & generation.
Remote MCP server for creating and selling digital products via MoneMee. It lets AI agents create, publish, and sell digital products such as e-books, AI prompt packs, software, courses without a human touching a dashboard. Docs: https://monemee.com/mcp Sign up on Monemee to get a token.
