Skip to main content
Glama
sepehr071

masterkala-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Delivery date and fee

mk_shipping
Read-only

Get the nearest delivery slot and shipping fee for one product, covering Tehran courier and post to other cities, so you can answer arrival time and cost.

Instructions

Get the nearest delivery slot and shipping fee for one product: Tehran courier and post to other cities.

Use for "when will it arrive / how much is shipping". Fees are Toman, 0 = free; free above free_shipping_from (null = never free). same_day_seconds_left > 0: can still arrive today in Tehran. Estimates use a default Tehran address.

Input Schema

NameRequiredDescriptionDefault
product_idYesMasterKala product id from mk_search / mk_browse, e.g. 24855.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.3.0
    • removedInput schema / properties / product_id / title
      Removed value: -"Product Id"
    • removedInput schema / title
      Removed value: -"mk_shippingArguments"
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "mk_shippingDictOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only supply readOnlyHint=true, but the description discloses real operational semantics: fees are Toman with 0 = free, the free_shipping_from threshold (null = never free), the same_day_seconds_left > 0 cutoff for same-day Tehran delivery, and that estimates assume a default Tehran address. These caveats materially affect how the agent should interpret and present results.

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?

Front-loaded with purpose, then usage trigger, then output semantics in compact form; every sentence carries information. The dense field-name shorthand (same_day_seconds_left, free_shipping_from) is slightly cryptic but defensible for an agent-facing spec.

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 and only one parameter, the description compensates well by explaining the return values' meaning and the Tehran-default assumption. It leaves the shape of the 'delivery slot' itself and behavior on an invalid product_id unaddressed, so not fully complete.

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 description coverage is 100% and the single parameter is documented ('MasterKala product id from mk_search / mk_browse, e.g. 24855'), so the schema does the heavy lifting. The description adds no syntax or format detail beyond it, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource: 'Get the nearest delivery slot and shipping fee for one product', with scope narrowed to Tehran courier vs. post elsewhere. No sibling tool covers shipping, so it is uniquely identifiable in the toolset.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Routes the agent by user intent: 'Use for "when will it arrive / how much is shipping"'. That is clear when-to-use guidance, though it names no alternatives or exclusions (none of the siblings overlap, so this is a minor gap).

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