Skip to main content
Glama
Sign In
torob-mcp

torob-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Sellers

tb_sellers
Read-onlyIdempotent

Lists every shop offer for a product, cheapest first, with shop score, warranty, installment and delivery details so you can pick where to buy.

Instructions

Every online shop offer for a product, cheapest first, with trust, warranty, installment and delivery info.

Use to pick where to buy. score/votes: shop rating 0-5; unreliable: bait or stale price; buyer_notes: Torob's order-volume and complaint notes; updated: price age. stats cover usable offers only.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "product": "<product>"
    },
    "name": "tb_sellers"
  }
}

Input Schema

NameRequiredDescriptionDefault
cityNoCity id or name: only offers serving that city.
limitNo
outputNojson
productYesProduct id (UUID) or torob.com product URL.
min_scoreNoMinimum shop score.
warranty_onlyNoTorob warranty (گارانتی ترب) offers only.
installment_onlyNoInstallment (قسطی) shops only.
include_unreliableNoKeep offers flagged unreliable (bait or stale).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.2.0
    • changedInput schema / properties / city / description
      Previous value: -"City id or name (e.g. 'مشهد' or 468): only offers that deliver to / sit in that city."New value: +"City id or name: only offers serving that city."
    • changedInput schema / properties / include_unreliable / description
      Previous value: -"Keep offers Torob flags as unreliable (bait or stale prices). Hidden by default."New value: +"Keep offers flagged unreliable (bait or stale)."
    • changedInput schema / properties / installment_only / description
      Previous value: -"Only shops that sell it in installments (قسطی)."New value: +"Installment (قسطی) shops only."
    • removedInput schema / properties / limit / description
      Removed value: -"Rows to return (default 15, max 50)."
    • changedInput schema / properties / min_score / description
      Previous value: -"Only shops with at least this Torob score (0-5)."New value: +"Minimum shop score."
    • removedInput schema / properties / output / description
      Removed value: -"json (default) or csv text for export."
    • changedInput schema / properties / product / description
      Previous value: -"Product id (the UUID from search cards, e.g. '57ea65ae-0798-4cd0-96a7-38d8af180345'), a '/p/<id>/...' path or a full torob.com product URL."New value: +"Product id (UUID) or torob.com product URL."
    • changedInput schema / properties / warranty_only / description
      Previous value: -"Only offers with Torob's buyer-protection warranty (گارانتی ترب)."New value: +"Torob warranty (گارانتی ترب) offers only."
  2. First observedv0.1.1

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already carry the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower, and the description still adds real value by decoding the response semantics: score/votes scale, what 'unreliable' means (bait or stale price), what buyer_notes contains, and that stats cover usable offers only. It omits pagination/truncation behavior and the meaning of 'cheapest first' when unreliable offers are included.

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 purpose and sort order are front-loaded in the first sentence, followed by a compact field glossary that earns its place. The backticked field list is dense and reads like documentation shorthand, but no sentence is redundant.

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?

With no output schema, the description does the necessary work of explaining the returned offer fields, which is the main completeness risk here. Remaining gaps (limit/output defaults, behavior when filters exclude everything, relationship to the toolbar siblings) are minor for a read-only listing tool whose annotations already cover safety.

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 75%, so the schema already documents city, product, min_score, warranty_only, installment_only, and include_unreliable; limit and output carry no description in either place. The description adds indirect meaning by explaining the score scale and the unreliable flag that min_score and include_unreliable operate on, but it never addresses city scoping, the limit cap of 50, or the json/csv choice.

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 states a specific resource and scope: every online shop offer for a given product, ordered cheapest first, plus what each offer carries (trust, warranty, installment, delivery). It stops short of naming any sibling (tb_offers, tb_cheapest, tb_compare, tb_stores) by contrast, so an agent must infer the boundary itself.

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?

'Use to pick where to buy' implies the selection scenario but names no alternative and no when-not condition among the many overlapping siblings (tb_cheapest, tb_best_value, tb_compare, tb_offers). The routing decision is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools