Search a B2B wholesale marketplace: products, services, suppliers and prices.
Scored across 6 tools
Each tool targets a distinct resource and action: three get_* detail lookups keyed to different entities (company, product, service), two domain-scoped searches, and one category listing. The detail-vs-search split is clearly signposted in descriptions, so misselection is unlikely.
Uniform snake_case verb_noun convention across all six tools (get_/list_/search_ plus singular or plural noun). Nouns match the domain entities consistently, making the surface predictable.
Six tools is well-scoped for a B2B directory covering three entity types (companies, products, services) plus discovery and search. Each tool earns its place with no redundancy.
Read-only coverage of detail lookups plus product/service search is coherent, but there is no way to search or list companies directly, so buyers can only reach a seller through a product hit. Category listing also has no companion tool to browse offers within a category beyond a keyword search.
A seller company on B2B Market: what it sells, its categories, city, and its latest products and services.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Answer language: ru (default), uz, en or ch (Chinese) | |
| slug | Yes | Company slug: the part after /@ in its URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and openWorldHint, so the safety profile is covered. The description adds useful payload context (what fields the profile includes), but says nothing about auth, error behavior for unknown slugs, or how many 'latest' items are returned.
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?
A single compact sentence with no filler, and the resource identity is front-loaded. It reads as a title restatement rather than a lead verb phrase, which slightly weakens the opening.
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 two-parameter read with no output schema, the description gives a reasonable picture of the returned payload. It still leaves open error handling for invalid slugs and the volume or pagination of the 'latest products' list.
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 description coverage is 100%, so both slug and lang are already documented in the schema, and the baseline is 3. The description adds no parameter detail beyond what the schema provides.
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?
The description names the exact resource (a seller company profile) and enumerates what comes back: categories, city, latest products and services. That distinguishes it well from get_product and get_service, though it is a noun phrase with no explicit retrieval verb.
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?
It never states when to call this tool versus search_products, list_categories, or the sibling get_product/get_service, nor does it say the lookup is keyed by a URL slug. Usage is only implied by the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full details of one product: price, seller, specifications, description, category and similar products.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Answer language: ru (default), uz, en or ch (Chinese) | |
| slug | Yes | Product slug: the part after /product/ in its URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds useful behavioral context by listing what the response contains (including similar products), which matters since no output schema exists.
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?
A single front-loaded sentence with zero filler. Every element (scope, returned fields) earns its place.
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?
With annotations covering safety/idempotency and the schema covering both parameters, the only missing structured artifact is an output schema. The description compensates by enumerating the returned fields, making it nearly complete for an agent to call correctly.
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 coverage is 100%, with both slug and lang fully documented in the schema, so the description need not repeat parameter details. It adds no meaning beyond the schema, which is the expected baseline for a fully documented 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?
States a specific verb and resource ('Full details of one product') and enumerates the returned data (price, seller, specifications, description, category, similar products). The singular 'one product' implicitly distinguishes it from the list-oriented sibling search_products, though no alternative is named.
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?
Usage is only implied: an agent can infer this is for retrieving a single product by slug, but the description never states when to prefer it over search_products or how a slug is obtained. No exclusions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full details of one service: price, provider, city, description and similar services.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Answer language: ru (default), uz, en or ch (Chinese) | |
| slug | Yes | Service slug: the part after /oneService/ in its URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, open-world and non-destructive behavior, so the description only needs to add context. It does add value by naming the returned content, including the non-obvious 'similar services', but says nothing about error behavior for a bad slug or how related services are chosen.
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?
It is a single front-loaded sentence with no filler. The field list is useful but slightly plain, keeping it just below the highest mark.
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?
With no output schema, the description carries the job of describing the return payload, and listing price, provider, city, description and similar services does that adequately. It is slightly incomplete about error handling and the nature of 'similar services', but sufficient for a simple read-only lookup.
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 description coverage is 100%, and the schema fully explains both slug and lang, including the enum values. The description does not mention either parameter, so it neither adds nor detracts from the schema; baseline 3 is appropriate.
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?
The description states a specific resource and scope: full details of a single service, keyed by slug. This implicitly distinguishes it from search_services (list/search) and the other get_* lookups for company/product, but it never names those siblings explicitly.
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?
Usage is only implied: an agent can infer this is for fetching details when it already has a service slug. There is no explicit when-to-use guidance, no mention of alternatives like search_services, and no stated preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Product or service categories with the number of offers in each and the category page URL.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | products (default) or services | |
| lang | No | Answer language: ru (default), uz, en or ch (Chinese) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds the useful detail that each category carries an offer count and a page URL, but says nothing about ordering, whether counts are live, or scope of the category set.
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?
A single tight sentence with no padding, and the most decision-relevant fact (offer counts and URLs are included) is front-loaded. It is arguably a touch too terse given the tool's role as a discovery endpoint.
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?
With only two fully documented optional parameters and no output schema, the description should compensate by characterizing the returned list. It partially does, but omits pagination, sort order, and how categories relate to the product/service search tools, leaving real gaps for a discovery tool.
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 description coverage is 100% and both parameters carry enums with documented defaults, so the schema fully handles semantics. The description adds no parameter information and does not even hint that the result can be scoped to products or services.
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?
The description identifies the resource (product/service categories) and the payload (offer counts plus category page URL), so the agent knows what comes back. But it is a bare noun phrase with no verb and no differentiation from siblings like search_products or get_product, which also surface category data.
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?
There is no statement of when to call this versus the five sibling tools, nor any prerequisite or exclusion. The agent must infer from the name alone that this is the discovery/browse entry point rather than a search or lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search wholesale products on B2B Market by keywords (any of ru/uz/en/zh). Returns title, price, seller and page URL. Optionally limit to a product category (see list_categories).
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Answer language: ru (default), uz, en or ch (Chinese) | |
| limit | No | How many results (default 10) | |
| query | Yes | What to look for, e.g. "cement M400" or "pine lumber" | |
| category_id | No | Product category id from list_categories |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld/non-destructive, so safety is covered; the description adds value the annotations cannot by listing the response fields (title, price, seller, page URL) — important with no output schema. It says nothing about result caps or ranking/pagination behaviour beyond what the schema implies.
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?
Two tightly packed sentences: capability and return shape first, optional narrowing and the cross-reference second. No filler.
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 four-parameter search tool with full schema coverage and no output schema, the description covers purpose, return fields and the category dependency adequately. The incomplete lang/zh-vs-ch signal and absence of any hint about result volume keep it from being complete.
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 coverage is 100%, so the four parameters are already documented; the description only reinforces that query accepts multiple scripts and that category_id comes from list_categories. It adds no detail for lang or limit, and its "zh" language code conflicts with the schema's "ch" enum value, which could confuse an agent.
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?
States a specific verb and resource ("Search wholesale products on B2B Market") plus the query domain (keywords in ru/uz/en/zh) and the returned fields. It is clearly distinguishable from get_product and search_services by resource, though it never explicitly contrasts itself with those siblings.
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?
Gives clear context for when to use it (keyword lookup, optional category narrowing) and routes the agent to list_categories for category ids. It stops short of stating exclusions, e.g. that exact-id lookups should go to get_product.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search business services on B2B Market (logistics, advertising, construction, consulting…). Returns title, price, provider and page URL.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Answer language: ru (default), uz, en or ch (Chinese) | |
| limit | No | How many results (default 10) | |
| query | Yes | What service to look for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive behavior, so the safety profile is covered. The description does add value by naming the returned fields (title, price, provider, page URL), which matters since no output schema exists, but says nothing about result ordering, pagination or truncation behavior.
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?
Two short sentences, purpose first, return shape second, with zero filler. Every clause earns its place.
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 three-parameter read-only search with a fully documented schema, the description supplies the missing piece – the return fields – since there is no output schema. It stops short of explaining result ordering or whether results span multiple languages, which would be the last gap to close.
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 description coverage is 100% – query, limit and lang all have their own descriptions and an enum for lang – so the schema carries parameter meaning. The description adds nothing beyond what the schema states, which merits the baseline 3.
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?
States a specific verb and resource ("Search business services on B2B Market") with concrete domain examples, which tells an agent this is service search rather than product search. It never names siblings like search_products or get_service, so differentiation is left to inference from the word "services".
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?
There is no explicit when-to-use or when-not-to-use guidance and no reference to alternatives such as get_service (single lookup) or search_products (item search). The only usage signal is implicit in the examples of service categories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_companyget_productget_servicelist_categoriessearch_productssearch_servicesSearch and buy products from sellers and verified warehouses, sell surplus stock, post requests.
Global B2B trade: verified manufacturers, product search, sanctions screening, HS codes.
Search and compare 200,000+ global suppliers by brief, name, HS code or country. Free, no key.
Search 160k+ Russian B2B products from 8,900+ verified manufacturers (EN/RU).
Add one secure layer between your agents and this server.
