Skip to main content
Glama

Seller and their ads

dv_seller
Read-onlyIdempotent

Retrieve a seller's profile from an ad token: personal/business ad counts, business card details, and their other listings to assess seller activity and find more ads.

Instructions

The seller behind an ad: how many personal and business ads they have, the business card (name, brand_token) and their ads.

Use to judge a seller (one flat or fifty cars?) and to list their other ads. For a dealer's whole page call dv_dealer with the brand_token (dv_post does not give one). A personal seller has no business card (seller_kind); Divar no longer lists a personal seller's other ads, and a dealer's list is the first 11. No phone number or identity is exposed.

Input Schema

NameRequiredDescriptionDefault
limitNoMax of the seller's other ads to return.
tokenYesAd token: the last part of divar.ir/v/<slug>/<token> or `token` of a search result, e.g. 'gaRPIP2m'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds genuinely non-obvious behavior: personal sellers lack a business card/seller_kind, Divar no longer lists a personal seller's other ads, dealer lists are truncated at 11, and no phone/identity is exposed.

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-loads the return shape, then usage, then caveats in a compact two-block layout with no filler. Slightly dense parenthetical asides, but every sentence carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description enumerates the returned components (ad counts, business card name/brand_token, ads) and flags the edge cases (missing seller_kind, capped lists) that would otherwise surprise an agent. For a 2-param read tool this is complete.

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 baseline is 3; the description goes beyond it by implying the effective ceiling on the ads list (dealer lists are 'the first 11') and tying `token` to the ad identity used elsewhere. It stops short of explaining limit interactions explicitly, so not quite a 5.

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?

Opens with a specific verb+resource framing: it returns the seller behind an ad, their personal/business ad counts, business card fields (name, brand_token), and their ads. It explicitly distinguishes itself from dv_dealer and dv_post, so an agent can route without opening schemas.

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

Usage Guidelines5/5

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

States the use case ('judge a seller — one flat or fifty cars?') and names alternatives with the condition that selects them: 'For a dealer's whole page call dv_dealer with the brand_token (dv_post does not give one).' Exclusions and caveats (no personal-seller ad list, dealer list capped at 11) are spelled out.

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