Loading ToolBench
Unofficial MCP server for the Trendyol Marketplace seller API: products, orders, customer Q&A, stock/price updates, claims.
This server presents 6 well-named, read/write-separated tools with complete input schemas and solid descriptions. Naming is strong (verb_noun pattern: get_products, get_orders, answer_question, update_price_and_stock). Descriptions are thorough (150-300 chars each) and explain WHAT, WHEN, and side effects clearly. All parameters have type definitions and descriptions. Output schemas are documented in prose but not formalized as JSON Schema. Error handling is present (TrendyolError, TrendyolRateLimitError) with actionable messages. Security is well-designed: write tools gated behind TRENDYOL_ALLOW_WRITES=true environment variable, PII redaction in get_orders by default. Key gaps: (1) output schemas not formally defined in JSON Schema format, LLMs must infer field structures from prose; (2) no enum constraints on status/filter parameters despite documented finite sets; (3) parameter validation rules (min/max chars for answer_question) are documented in prose only, not in schema constraints; (4) no per-item success/failure for batch operation (update_price_and_stock). These are significant but addressable, the server demonstrates professional attention to usability and safety.
WRITE: publish an answer to a customer question on Trendyol. Refuses unless the environment variable TRENDYOL_ALLOW_WRITES=true is set. The answer is shown publicly to customers; Trendyol requires 10-2000 characters and questions can only be answered once. Args: question_id: The question id from get_customer_questions. text: The answer text (10-2000 characters).
List customer claims (refund/return requests) on the store (read-only). Args: status: Optional filter. Documented statuses: INITIATED, APPROVED, REJECTED, COMPLETED, CANCELLED, REQUESTED_FROM_CUSTOMER, WAITING_FOR_CUSTOMER_ACTION. start_date: 'YYYY-MM-DD' or epoch milliseconds. end_date: 'YYYY-MM-DD' (inclusive) or epoch milliseconds. page: Zero-based page number. size: Items per page.
List customer questions about the store's products (read-only). Args: status: One of WAITING_FOR_ANSWER, WAITING_FOR_APPROVE, ANSWERED, REPORTED, REJECTED. Default lists questions awaiting an answer. page: Zero-based page number. size: Items per page, max 50. Returns question id, text, status, creationDate, productName and webUrl, plus the existing answer text when one exists. Customer user names are not included.
List order packages (shipment packages) for the store (read-only). Args: status: Optional filter. Documented values: Created, Picking, Invoiced, Shipped, Cancelled, Delivered, UnDelivered, Returned, AtCollectionPoint, UnSupplied. start_date: 'YYYY-MM-DD' or epoch milliseconds. end_date: 'YYYY-MM-DD' (inclusive) or epoch milliseconds. page: Zero-based page number (API allows pages 0-49). size: Items per page, max 200. include_pii: Customer name and full shipping address are REDACTED by default; set True only when personal data is genuinely needed. Returns a paged summary: orderNumber, status, orderDate, totalPrice, order lines, and the customer's city only (unless include_pii=True).
Output schemas not formalized in JSON Schema, LLMs infer field structures from prose descriptions only, risking field-name mismatches and type confusion in downstream agent reasoning.
Enum parameters (status in get_orders, get_customer_questions, get_claims; approved in get_products) are documented in prose but not enforced as JSON Schema enums, inviting hallucinated invalid values from LLMs.
Numeric/string constraints (barcode format, price ranges, quantity min/max, answer text 10-2000 chars, max 1000 items in update_price_and_stock array) documented in prose but not enforced in schema minLength, maxLength, minimum, maximum, items. LLMs cannot read schema comments.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 72 | 2026-07-28+ | v2 |
List products in the seller's Trendyol store (read-only). Args: page: Zero-based page number. size: Items per page (the sibling V2 endpoint caps at 100; no explicit cap is documented for this V1 filter). approved: True for approved products only, False for unapproved only, omit for both. barcode: Filter by an exact product barcode. Returns a paged summary with barcode, title, quantity, salePrice, listPrice and approved per product.
WRITE: update prices and inventory levels for products on Trendyol. Refuses unless the environment variable TRENDYOL_ALLOW_WRITES=true is set. Up to 1000 items per request; each item must have a barcode and at least one of price or quantity. Args: updates: A list of dicts, each with: - barcode (str): the product barcode - salePrice (float, optional): the new sale price - listPrice (float, optional): the new list price - quantity (int, optional): the new stock quantity One item fails = the entire request fails (transactional). Prices affect product visibility (zero or negative = hidden); quantity changes are published immediately.
answer_question and update_price_and_stock have no documented output schema, what is returned on success? This breaks agent chaining and forces LLMs to guess what fields are available for downstream calls.
update_price_and_stock fails atomically (all 1000 items or none) with no per-item success/failure detail, on error, agent cannot determine which items succeeded and which failed, forcing full retry.
Date parameters in get_orders and get_claims accept both YYYY-MM-DD and epoch milliseconds but schema lacks pattern or format constraint; validation happens in code, not client-side, LLMs may pass malformed dates.