market_listingsFresh classified listings extracted from Telegram groups across the OTC network — Thailand (th), UAE (ae), Turkey (tr), Vietnam (vn), Georgia (ge), USA (us), Russia (ru): rent, sale, services, jobs, exchange. Filter by country and listing type.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Listing type filter ('wanted' = demand: сниму/куплю/ищу, any kind) | |
| limit | No | Max results (default 10) | |
| country | No | OTC country code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It mentions freshness, source (Telegram), and filterability, but does not explicitly state it is read-only, nor describe pagination, rate limits, or output structure. This is a moderate coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence conveys source, scope, and filters, but lists countries and types that already exist in the schema, causing mild redundancy. Still compact and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool, the description covers source, scope, and filters. But without annotations or output schema, it lacks an explicit read-only statement and return format details, leaving some uncertainty for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema fully describes all three parameters with enums and default values. Description only repeats that filtering by country and type is possible, adding little beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool browses fresh classified listings from Telegram groups across specified countries, with filtering by type and country. It distinguishes itself from sibling tools by focusing on marketplace ads rather than stats or generic post search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context about the data source and filtering options, implying use for browsing classifieds. However, it does not explicitly mention when to use this over siblings like search_posts or market_stats, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct data need: ranked channel discovery, exact channel lookup, marketplace listings, marketplace stats, post-content search, and catalog entity search. Even the two search tools are clearly separated by whether they search post content or Telegram catalog entries.
Names are readable and consistently snake_case, but they mix verb-led names like search_posts and search_telegram with noun-led names like channel_stats, market_listings, market_stats, and best_channels_by_category. The market_* and search_* pairs are helpful, but there is no uniform verb_noun pattern across the set.
Six tools is a well-scoped size for a Telegram catalog and search server. Each tool earns its place by covering channel discovery, channel lookup, post search, and marketplace data without redundancy.
The read-only surface is largely complete: search, top channels, exact stats, and marketplace stats/listings are all covered. A direct way to retrieve recent posts for a specific channel or enumerate all categories would close the remaining minor gaps.