Skip to main content
Glama
sepehr071

khanoumi-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Shipping, returns and store rules

kh_store_info
Read-onlyIdempotent

Retrieve Khanoumi order rules from its FAQ to check packaging costs, shipping fees and times, returns, payments, refunds, authenticity, and pink-box policies.

Instructions

Get Khanoumi's order rules from the official FAQ: packaging cost, shipping fees and times, returns, payment and refunds, authenticity guarantee, pink-box rules.

Use for "how much is shipping", "can I return it", and the true order cost (formula in the server instructions; the fees are in the delivery answers). With topic=all and no query, answers are cut to 300 characters (end with …); pick a topic or a query, or set full_text=true, for full text.

Input Schema

NameRequiredDescriptionDefault
queryNoOnly questions or answers containing this, e.g. 'هزینه ارسال'.
topicNoFAQ section: delivery (fees, times), returns, payment, guarantee (authenticity, expiry), ...; all = about 80 answers, clipped.delivery
full_textNoDo not clip answers when topic is all.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.2.0
    • addedInput schema / properties / full_text
      Added value: +{
+  "default": false,
+  "description": "Do not clip answers when topic is all.",
+  "type": "boolean"
+}
    • removedInput schema / properties / query / title
      Removed value: -"Query"
    • changedInput schema / properties / topic / description
      Previous value: -"FAQ section: delivery (fees, times), returns, payment, guarantee (authenticity, expiry), order, pink_box, tracking, order_edit, comments, gold, or all (about 80 answers, long: prefer a topic or a query)."New value: +"FAQ section: delivery (fees, times), returns, payment, guarantee (authenticity, expiry), ...; all = about 80 answers, clipped."
    • removedInput schema / properties / topic / title
      Removed value: -"Topic"
    • removedInput schema / title
      Removed value: -"kh_store_infoArguments"
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "kh_store_infoDictOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already establish a safe read-only, idempotent profile, and the description adds genuinely useful behavior the schema cannot express: answers are truncated to 300 characters (ending in …) when topic=all with no query, with the three ways to obtain full text. It does not describe answer structure or result count beyond the clipping rule, so it falls short of the richest disclosures.

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?

Two tight paragraphs, with the operational trap (300-character clipping) surfaced in the second sentence rather than buried. Some topic names are repeated verbatim from the enum (returns, payment, etc.), which is mild redundancy, but nothing is padded or off-topic.

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?

For a no-required-parameter FAQ reader with no output schema, the definition covers the resource, the trigger cases, the parameter interaction, and the truncation caveat, plus a pointer to the server instructions for the cost formula. The only real gap is a brief note on what an answer record contains, which is minor given the read-only scope.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics the schema does not: the topic=all corpus is ~80 answers and is clipped unless full_text=true, and the clip only applies in that combination. It also frames query as 'questions or answers containing this', clarifying match scope beyond the schema's maxLength note.

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?

States a specific verb and resource ('Get Khanoumi's order rules from the official FAQ') and enumerates the covered domains (packaging cost, shipping fees/times, returns, payment, refunds, authenticity, pink-box rules), which matches the topic enum closely. It is clear what is retrieved, but it never names or contrasts a sibling (e.g. kh_blog_search or kh_product), so an agent must infer the boundary from domain knowledge alone.

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?

Gives concrete trigger phrasings ('how much is shipping', 'can I return it'), points to the delivery answers as the source of the fee values needed for the order-cost formula, and explains how to avoid clipped results. There is no explicit when-not-to-use statement or named alternative tool, so the routing guidance is strong but not exhaustive.

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