Skip to main content
Glama
Sign In
iranketab-mcp

iranketab-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Browse a category

ik_browse
Read-onlyIdempotent

Browse books by category, bestseller, award, or curated list with sorting, in-list search, and sub-category filters to find Persian editions and prices.

Instructions

List books of a category, bestseller list or award list, with sort, in-list search and sub-category filters.

Ids: 209 bestsellers, 207 newest, 1 staff picks, 325 weekly 30% discounts, 1293 signed copies. Prizes and series are categories too (ik_lists). Prices in Toman. term can be slow on huge lists such as 103.

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": {
      "category": "<category>"
    },
    "name": "ik_browse"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNo24 books per page (18 for publishers).
sortNonewest = site order.newest
termNoSearch inside the list.
filtersNo'group=tag' strings from ik_categories(category), e.g. ['17=152']; groups combine with AND.
categoryYesCategory id: 209 bestsellers, 207 newest, 1 staff picks, 103 fiction, 152 Russian literature; more via ik_categories.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds genuinely new behavior: prices are in Toman and term-search degrades on very large lists. It says nothing about result size limits beyond pagination, rate limiting, or what a returned record looks like.

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 short blocks, front-loaded with the core action, then the id cheat-sheet and caveats. No filler sentences. The id list is dense but earns its place by enabling a call without a prior lookup.

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 read-only browse tool with a fully described schema and no output schema, the definition covers action, ids, controls, and a performance caveat. It still leaves the agent guessing at the returned book shape and total-count/pagination semantics, which are the main gaps.

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%, so category, sort, term, filters, and page are already documented, giving a baseline of 3. The description adds only marginal value: extra category ids (325, 1293) not in the schema and the slowness note for term; it does not explain how sort interacts with filters or what the filters syntax yields.

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 ("List books of a category, bestseller list or award list") plus the available controls (sort, in-list search, sub-category filters), and names the concrete category ids so an agent can map intent to a call. It differentiates against ik_lists and ik_categories but never mentions ik_search, which is the closest competing sibling for book lookup.

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?

Clear usage context: browse a list/pseudo-list, get more categories from ik_categories, and note that prizes and series are categories reachable via ik_lists. It also flags a performance condition ("term can be slow on huge lists such as 103"). Missing an explicit statement of when to prefer ik_search instead of browsing.

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