Multi-platform e-commerce seller analysis server for Amazon, TikTok, Shopee, TEMU, and Walmart. Provides product research, competitor analysis, keyword research, category analysis, and profit calculation tools.
This server has significant structural gaps. While all 31 tools have names, descriptions, and input schemas visible, the quality is uneven. Most tool descriptions are under 100 characters (well below the 194-char production baseline) and lack strategic context (WHEN to use, prerequisites, state mutations). Parameter descriptions are minimal, many exist but are perfunctory (e.g., 'Amazon site', 'Amazon ASIN identifier'). No output schemas are documented anywhere in the provided source. Error handling is absent from the visible tool definitions. The server exhibits a 'wrapper pattern' where tools are thin passes to backend APIs, which means tool design decisions (pagination, result limiting, response shaping) are likely delegated and not surfaced. Naming is generally clear and action-oriented (product_detail, product_reviews, product_search) but lacks specificity for disambiguation (tools like 'keyword_detail' vs 'keyword_extends' are under-differentiated). The 'sorftime_raw_call' tool is a red flag, a generic pass-through handler suggests incomplete tool registration and prevents LLMs from understanding actual capabilities.
No output schemas documented for any tool. LLMs cannot anticipate response fields, plan chaining, or extract relevant data without knowing what fields are returned. This blocks composition and multi-step reasoning.
Add comprehensive output schemas for all 31 tools. Document every field the API returns that the LLM might need (product name, price, rating, category, ASIN, etc.) and mark fields relevant for downstream tool chaining (e.g., category_id, product_id for follow-up searches). Use JSON Schema with type and description for each field.
Rewrite all tool descriptions to 100-200 characters (production baseline ~194). Include: (1) WHAT the tool retrieves/does, (2) WHEN to use it (e.g., 'to discover similar products', 'to analyze keyword competition'), (3) any prerequisites (e.g., 'requires a valid ASIN'). Example: 'Fetch detailed keyword metrics including search volume, trend, and competition level. Use this to evaluate market demand before choosing a keyword for your listing.'
Convert bare parameter descriptions into formal constraints. For 'amz_site', replace 'Amazon site' with 'Amazon site code: one of US, UK, DE, JP, CA, FR, IT, ES, AU, IN, MX, BR'. Declare enums in schema for all constrained parameters.
Remove 'sorftime_raw_call' or explicitly register all backend tools it wraps. If it must remain, document which tools it supports and require explicit tool_name matching (no fuzzy lookups).
Add a 'When to use instead of similar tools' section in descriptions where disambiguation is needed. E.g., 'Use product_traffic_terms to find organic keywords driving traffic to a specific product. Use competitor_product_keywords to rank competitor products by keyword. Use keyword_extends to expand a keyword into long-tail variants without a product context.'
Tool descriptions are too brief (avg ~30 chars, far below 194-char production baseline). They state WHAT narrowly but omit WHEN to use, prerequisites, and whether the tool mutates state. Descriptions like 'Fetch Amazon product detail page information by ASIN' lack strategic context for LLM selection.
'sorftime_raw_call' is a pass-through handler for unregistered tools, indicating incomplete tool registration. This is an anti-pattern: it hides actual capabilities from the LLM, prevents proper validation, and encourages the LLM to guess at tool names and arguments.
Parameter descriptions are minimal and formulaic (e.g., 'Amazon site', 'Amazon ASIN identifier'). They do not explain valid ranges, constraints, dependencies, or edge cases. No parameter is described with format guidance (e.g., 'ISO 8601 date', 'UUID v4', 'ASIN: 10 alphanumeric characters'). No enums are declared for constrained parameters like 'amz_site' (which accepts US, UK, DE, JP, CA, FR, IT, ES, AU, IN, MX, BR).
No error handling guidance. Tools have no documented recovery paths, retryable classifications, or actionable error messages. LLMs will not know whether to retry, lookup alternatives, or escalate.
Naming ambiguities in similar tool pairs reduce distinctiveness. E.g., 'product_traffic_terms' vs 'competitor_product_keywords' both relate to keyword data but names do not make the semantic difference clear. 'keyword_detail' vs 'keyword_extends' sound overlapping.
Multi-platform parameter handling (amz_site, site, product_id vs asin) is inconsistent across tools. Some tools use 'amz_site', others 'site'; some use 'asin', others 'product_id'. This inconsistency forces the LLM to reason about field mappings for every cross-platform call.
No pagination, result limiting, or context-awareness guidance in any tool. Tools returning lists (product_search, keyword_search_results, etc.) do not declare page, offset, limit, or total_count parameters/fields. Large unfiltered result sets can exhaust LLM context.
Standardize parameter names across platforms. Use consistent naming: all marketplace identifiers should be 'marketplace_site' or 'platform'; all product IDs should be 'product_id' or 'asin' (not mixed). Alternatively, provide adapter parameters in the LLM prompt that map natural names (e.g., 'Amazon site') to actual parameter names.
Add pagination support: page_number/page_size parameters and page_total/next_cursor in responses for any tool returning lists. Cap default limit at 20 - 50 items and document in the description. E.g., 'Returns up to 50 results per page. Use page_number to retrieve additional pages.'
Add error handling guidance. Each tool description should note: 'On error, the LLM should [retry with modified input | call search_* to find the correct ID | escalate to the user]. Common errors: Invalid ASIN (format: 10 alphanumeric chars), Site code mismatch, Rate limit (retry after 60s).'
Add state mutation clarity. Explicitly state in descriptions which tools are READ-ONLY (all 31 are marked READ-ONLY already, which is good) so agents know they can retry freely without side effects.
Document dependency hints: e.g., 'If you only have a product name, call product_search() first to find the ASIN. Then call product_detail(asin=...) for detailed metrics.'
Audit and expand result field coverage: ensure tools return IDs needed for follow-up calls. E.g., if product_search returns a product, include asin, category_id, and marketplace_site so the agent can immediately call product_detail or category_report without extra lookups.