This server demonstrates severe deficiencies across all definition quality dimensions. Tool names lack action verbs and are ambiguous; descriptions are either missing or trivial; input schemas are either absent or incomplete; and parameter descriptions lack essential constraint information. The server reads as a collection of proof-of-concept scripts rather than production-grade MCP tool definitions. Additionally, the tools expose significant security vulnerabilities (hardcoded credentials, session tokens as parameters, unvalidated user input) that violate fundamental agent tooling principles.
Polls recent orders from Temu API to detect drops in price, submitting a Price Adjustment request to claim the difference.
knapsack_cart_fillerwritesource verified45/100
Uses the Knapsack algorithm approach to find the exact or closest combination of super-cheap items to reach the target amount (e.g., $2.00 to hit free shipping).
search_temuread onlysource verified47/100
Simulates searching Temu bypassing WAF using Playwright with stealth. (Note: Hardcoded selectors and behavior need to be adapted dynamically)
check_price_adjustments exposes session_cookie as a tool parameter. This violates pattern:secret-injection, credentials must NEVER appear in tool parameters. Agent traces log all parameters; session tokens in logs are a data breach. Session cookies must be injected server-side via environment or vault.
knapsack_cart_filler, snipe_lightning_deals, and check_price_adjustments are all WRITE operations (they modify cart state, trigger purchases, submit refunds) but descriptions do not explicitly state this. Per pattern:command-tool, destructive tools must declare their side effects so agents know which calls are retryable. Additionally, no tool includes destructiveHint/idempotentHint annotations per current MCP spec.
CRITICAL: Remove session_cookie from check_price_adjustments parameters. Inject authentication server-side via environment variables or a secure vault. Document that the tool uses server-configured Temu credentials and does not require user input for auth.
CRITICAL: Add a complete input schema to snipe_lightning_deals. Minimally, add parameters for discount_threshold (float, 0-1.0), max_price (float), and item_category (optional string). Each parameter must have a description and type.
CRITICAL: Document output schemas for all four tools. Specify the exact structure, field types, and whether results are paginated. E.g., knapsack_cart_filler returns {selected_items: [{id, name, price, quantity}], total_cost: float}, and search_temu returns {status: string, items: [{title, price, rating, reviews, product_id}], total_count: int}.
CRITICAL: Add destructiveHint: true to knapsack_cart_filler, snipe_lightning_deals, and check_price_adjustments in their tool definitions. Update descriptions to explicitly state that these operations modify cart state or submit financial requests, making clear their irreversibility.
HIGH: Rename snipe_lightning_deals to add_lightning_deal_to_cart (verb_noun pattern) or better yet, split into two tools: find_lightning_deals (discovery) and add_to_cart (action). This clarifies intent and lets agents compose them independently.
HIGH: Rename knapsack_cart_filler to fill_cart_to_threshold or add_items_to_cart (clearer action verbs). 'Knapsack' is algorithm jargon; LLMs and end users do not think in terms of knapsack problems.
All four tools lack documented output/return schemas. LLMs cannot plan downstream calls or extract required fields if they do not know what the tool returns. Per pattern:tool, all tools must document their response structure, types, and fields.
Tool names lack standard action verbs or are ambiguous. 'knapsack_cart_filler' uses a noun-noun pattern; 'snipe_lightning_deals' uses informal jargon; 'check_price_adjustments' conflates checking and submitting (two separate actions). Per pattern:tool-naming, names must start with a clear verb (get, create, update, delete, search, list, send) so LLMs can infer intent from the name alone.
Parameter descriptions lack constraint information (min/max values, format rules, allowed enums, dependencies). E.g., available_items accepts a 'list' type but does not specify minimum items, required fields (id, name, price all mandatory?), or valid price range. Per review:param-validation-rules, all constraints must be documented in descriptions so LLMs can self-validate before calling.
No error handling guidance. If a tool fails (e.g., Temu API unreachable, invalid session, out-of-stock items), the tool returns a generic error string. Per pattern:recovery-guide, errors must tell the LLM what to do next: can I retry? Should I ask the user? Or is this unrecoverable?
Tools accept zero or minimal user-friendly parameters. 'snipe_lightning_deals' takes no parameters at all, how does an LLM control what deals to snipe? Per mxe:chat-data-model, tool interfaces must match what users say in chat and provide human-friendly identifiers (names, keywords) not just opaque IDs.
Tools are not idempotent. Calling snipe_lightning_deals twice will add the same item to cart twice; calling check_price_adjustments twice will submit duplicate refund requests. Per pattern:idempotent-operation, agents retry on ambiguous failures, non-idempotent tools risk duplicate side effects (double charges, duplicate records). Each tool must return an idempotency key or include deduplication logic.
No permission gates or scope declarations. These tools trigger financial transactions (add to cart, claim refunds) without checking if the agent has authorization. Per pattern:permission-gate and pattern:scope-declaration, destructive/privileged tools must verify caller authority and declare what permissions they require.
HIGH: Add parameter constraints to all tools. E.g., knapsack_cart_filler.target_amount: 'A float >= 0.01 and <= 9999.99 (e.g., 2.00 for free shipping). Precision: two decimal places.' available_items: 'An array of 1-1000 item objects, each with required fields id (string), name (string), price (float >= 0.01).'
HIGH: Add error recovery guidance to all tool descriptions. E.g., 'If Temu API is unavailable, the tool will return an error with retry guidance. If authentication fails, re-check your session credentials. If items are out of stock, the tool will skip them and continue with available items.'
HIGH: Add idempotency keys or deduplication logic. snipe_lightning_deals should return a unique deal_id or session_id so agents can retry safely without double-adding. check_price_adjustments should track previously claimed adjustments to avoid duplicate refund submissions.
HIGH: Add permission gates. Before executing a WRITE operation (add to cart, submit refund), verify the agent/user has cart_write or financial_write scope. Return a clear error: 'Permission denied: user does not have cart_write scope. Contact your administrator.' This prevents accidental authorization escalation.
MEDIUM: Expand snipe_lightning_deals parameters to accept discount_threshold, max_price, and category filters. Currently it accepts zero parameters, LLMs cannot control its behavior. Accept user-friendly inputs: discount_threshold (0-100 percent), category (optional), max_price (float).
MEDIUM: Add pagination support to search_temu. Add optional parameters: page (int, default 1), limit (int, 1-100, default 20). Ensure the response includes total_count and a next_page indicator. Currently it returns mock data; clarify whether real results are available and how many items are returned per call.
MEDIUM: Include chaining IDs in responses. If search_temu returns products, each should include a product_id that add_to_cart (if implemented) accepts. If knapsack_cart_filler returns selected items, include their item_ids so agents can reference them in follow-up calls.
MEDIUM: Replace 'Simulates' language in descriptions with factual claims. E.g., search_temu description says 'Simulates searching Temu', clarify: does it actually search Temu (with real results), or is it a mock? If mock, document that explicitly. LLMs interpret 'simulates' as unreliable.
LOW: Remove developer-facing notes ('Hardcoded selectors need dynamic adaptation') from tool descriptions. These belong in implementation comments, not user-facing docs. Descriptions must present the tool as stable and ready to use.
LOW: Add examples of expected parameter values in parameter descriptions (but NOT in tool descriptions). E.g., keyword param: 'Search term (e.g., wireless earbuds, phone case). Any string; special characters allowed.' This guides LLMs without baking in literal example values.
LOW: Document rate limits and retry behavior. E.g., 'check_price_adjustments may be rate-limited to 1 call per 60 seconds per account. If you receive a 429 error, wait and retry.' This prevents agents from exhausting API quotas.