buyer-intelligence
Server Details
Find verified global B2B buyers by category & country. Free anonymous discovery. SGX-listed.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 12 of 12 tools scored.
Each tool has a clearly distinct purpose, covering buyer intelligence, discovery, contact enrichment, product search, quoting, ordering, payment mandates, and group buy pools. No two tools have overlapping functionality.
All tools follow a consistent verb_noun pattern in snake_case (e.g., analyze_buyer_intelligence, find_buyers, place_order), making it easy to infer actions and targets.
12 tools is well-scoped for a buyer intelligence and procurement platform, covering the full workflow without being overwhelming or too sparse.
The core transaction loop (search, request quote, list quotes, place order) is complete, and tools cover buyer discovery and intelligence. Minor gaps exist (e.g., no order cancellation, no join group buy pool), but agents can accomplish the primary tasks.
Available Tools
12 toolsanalyze_buyer_intelligenceAInspect
Deep company intelligence for a buyer: corporate registry verification, customs import records, supply chain mapping, decision-maker profiling, risk flags. Returns 0-100 score with evidence chain.
| Name | Required | Description | Default |
|---|---|---|---|
| country_iso | No | ISO 3166-1 alpha-2 country code | |
| target_domain | Yes | Buyer's website domain | |
| target_company_name | No | Buyer's company name |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide behavioral hints (readOnlyHint=false, openWorldHint=true). Description adds the output format (0-100 score with evidence chain) and lists data sources, but does not disclose side effects, auth needs, or rate limits. Adequate but minimal added behavioral context.
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 sentences: first lists core capabilities, second specifies output format. Front-loaded with purpose and content. No redundant or filler language.
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 tool with 3 parameters (1 required) and no output schema, the description covers input use and output. Lists multiple data sources and score range. Minor gap: does not describe the evidence chain format or how the score is constructed, but adequate given annotations present.
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% (each parameter has a description). The tool description does not add further meaning beyond the schema, so baseline 3 applies. It does not clarify relationships or expected formats beyond what 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?
Description clearly states the tool analyzes a buyer using multiple data sources (corporate registry, customs, supply chain, decision-maker profiling, risk flags) and returns a 0-100 score with evidence chain. This differentiates it from sibling tools like 'find_buyers' (discovery) and 'enrich_buyer_contact' (contact enrichment).
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?
Description implies use for deep buyer intelligence but lacks explicit guidance on when to use this tool vs alternatives (e.g., 'use for due diligence, not for initial contact enrichment'). No when-not-to-use or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_discovery_taskARead-onlyIdempotentInspect
Poll a background buyer-discovery task created by find_buyers (acquisition.task_id) or submit_discovery_job. Returns status (working | completed | failed); when completed, includes the freshly gathered buyers. Use exponential backoff (start ~20s) and stop polling once status is completed or failed. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max buyers to return when completed (default 50, max 100) | |
| task_id | Yes | The task_id returned in find_buyers' acquisition field, or a discovery job_id |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds valuable context: the tool is free, returns specific statuses, and includes gathered buyers when completed. No contradiction; description enhances transparency about return behavior and cost.
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?
Four concise sentences, each adding value. The first sentence identifies the tool's purpose and source, the second explains output, the third gives usage guidance, and the fourth notes it's free. No redundancy or wasted words.
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 polling tool with no output schema, the description comprehensively covers what the agent needs: how to obtain the task_id, what statuses to expect, what happens on completion (buyers included), and polling strategy. This is sufficient for correct usage.
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 parameters described. The description adds the detail that limit defaults to 50 and max is 100, which is not in the schema. This provides practical guidance beyond the schema, earning a slight bonus above 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?
The description clearly states the tool polls a background buyer-discovery task from specific sources (find_buyers or submit_discovery_job) and returns status and buyers on completion. It distinguishes from siblings by specifying its role as a polling complement to creation tools.
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 explicit guidance on polling behavior: exponential backoff starting at ~20s and stopping on completed/failed. It also notes the tool is free. However, it does not explicitly exclude alternative usage or mention error scenarios (e.g., invalid task_id). Still, the guidance is actionable and clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_payment_mandateAInspect
Create an AP2 payment mandate: a pre-authorization that lets your agent place orders autonomously (human-not-present) within strict limits — total budget, optional per-order cap, currency, optional seller/category scope, and expiry. Returns a mandate_id to pass to place_order. Each order authorized against it is recorded as a verifiable intent and decrements the budget. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| currency | No | Currency, e.g. USD (default USD). Must match the order currency to authorize. | |
| expires_at | No | Optional ISO timestamp after which the mandate is no longer valid. | |
| seller_scope | No | Optional list of allowed seller_user_id UUIDs. Omit = any seller. | |
| category_scope | No | Optional list of allowed category codes (mall_category_code). Omit = any category. | |
| max_total_amount | Yes | Total spend budget for this mandate (required, > 0) | |
| max_per_order_amount | No | Optional per-order cap |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint false) and open world (openWorldHint true). The description adds behavioral details: orders decrement the budget, records are verifiable intents, and authentication is required. No contradictions with annotations, but could mention rate limits or idempotency.
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?
The description is concise: four sentences front-load the purpose, followed by limits, return value, and usage context. No redundancy or fluff.
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?
The description covers key aspects: purpose, limits, return value (mandate_id), and usage with place_order. Minor gaps: no mention of error scenarios or full response format (no output schema), but sufficient for typical use.
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 descriptions. The description summarizes parameters (budget, per-order cap, currency, scope, expiry) but does not add new meaning beyond the schema. Baseline 3 is appropriate as the schema already provides sufficient detail.
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 clearly specifies the verb 'create' and resource 'AP2 payment mandate'. It distinguishes from siblings by mentioning that the returned mandate_id is used with place_order, and contrasts with list_payment_mandates which lists existing mandates.
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?
The description explains when to use the tool: to pre-authorize autonomous orders. It provides context on setting limits and expiry, and notes authentication requirements. However, it does not explicitly state when not to use or compare with alternatives directly besides referencing place_order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
enrich_buyer_contactAInspect
Run 6-layer contact enrichment for a buyer: direct website scraping → proxy retry → BFS contact pages → LLM text extraction → vision screenshot → Serper fallback. Returns email, phone, WhatsApp, decision-maker names. Costs Zhimao Points.
| Name | Required | Description | Default |
|---|---|---|---|
| target_domain | Yes | Buyer's website domain (e.g. 'example-importer.com') | |
| target_company_name | No | Buyer's company name |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the multi-step scraping, LLM extraction, vision, and fallback procedures, and notes the cost. This adds significant behavioral context beyond annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true). No contradictions.
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?
The description is concise with two sentences, front-loaded with the tool's core action and components. No unnecessary words.
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?
Despite no output schema, the description specifies return fields (email, phone, WhatsApp, decision-maker names) and mentions cost. For a complex tool with multiple steps, it covers enough for an agent to understand usage and outcomes.
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 parameters target_domain and target_company_name. The description adds minimal extra meaning beyond the schema, only implying that target_domain is used for scraping. Baseline of 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 clearly states it performs 6-layer contact enrichment for a buyer, specifying the process steps and output fields. It is distinct from siblings like analyze_buyer_intelligence and find_buyers.
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?
The description explains the process flow and cost (Zhimao Points), implying when to use it for obtaining buyer contact details. It lacks explicit when-not or alternative tool suggestions, but provides sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_buyersARead-onlyIdempotentInspect
Search 500,000+ verified importers and distributors by product category and target country. Returns company profiles + a coverage object. When in-database coverage is thin (empty/partial), the response includes an acquisition task (task_id) — a background crawl is started automatically (free). Poll it with check_discovery_task until status=completed to get freshly gathered buyers. Contact details are not included — use enrich_buyer_contact to get them.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default 20, max 100) | |
| category | Yes | Product category (e.g. 'flour', 'stainless steel tableware', 'LED lighting') | |
| country_iso | No | ISO 3166-1 alpha-2 country code (e.g. MY, ID, KE, AE, GB) | |
| quality_grade | No | Filter by data quality. 'premium' = verified contact + multi-source evidence. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. Description adds that a background crawl may be started automatically (acquisition task) and returns a coverage object. No contradiction.
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?
Three sentences, front-loaded with the core purpose, efficient with no wasted words. Every sentence adds value.
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?
No output schema, but description explains return values (profiles, coverage, acquisition task) and mentions polling. Covers key behavioral aspects, though could mention error scenarios or more about coverage object.
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 baseline 3. Description adds context for category, country_iso, and quality_grade, but does not detail each parameter beyond what schema provides. Meets baseline with some added value.
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 clearly states the tool searches 500,000+ verified importers/distributors by product category and target country, distinguishing it from sibling tools like enrich_buyer_contact and check_discovery_task.
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?
Explicitly says when to use (for searching buyers), explains what to do when coverage is thin (poll check_discovery_task), and notes contact details are not included (use enrich_buyer_contact). Provides clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_group_buy_poolsARead-onlyIdempotentInspect
List open collective sourcing projects (联拼宝 / Lianpinbao). Multiple suppliers co-sell into shared buyer pools, reducing per-supplier MOQ. Find pools where you can join to access existing buyer demand.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Pool status (default: open) | |
| category | No | Filter by product category keyword (optional) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, etc. Description adds behavioral context about co-selling and MOQ reduction, which is useful beyond annotations.
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 clear, front-loaded sentences with zero fluff. Every part 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?
Given no output schema, the description adequately explains the tool's purpose and domain. It could mention response shape or pagination, but the simplicity of the tool makes it acceptable.
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 description doesn't need to elaborate on parameters. However, it could clarify the difference between 'open' and 'filling' statuses, which is only hinted by focusing on 'open'.
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 'List open collective sourcing projects' with specific verb and resource, and includes the Chinese name for disambiguation. Sibling tools like find_buyers and search_products are distinct, so no confusion.
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?
Description says 'Find pools where you can join to access existing buyer demand,' which implies usage context, but lacks explicit guidance on when not to use or comparisons to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_payment_mandatesARead-onlyIdempotentInspect
List your AP2 payment mandates with status, currency, total/per-order limits, consumed and remaining budget, scope and expiry. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, indicating safety. The description adds the authentication requirement and details the returned fields, which provides additional transparency beyond the annotations.
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?
The description is a single, well-structured sentence that front-loads the verb and resource, then lists relevant attributes. Every word adds value, with 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?
Without an output schema, the description compensates by listing the return fields (status, currency, limits, budget, scope, expiry). However, it does not mention pagination or ordering, which are not critical given no parameters.
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?
There are no parameters, so the description does not need to explain parameter semantics. Baseline of 4 is appropriate as no further info is required.
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 specifies the verb 'List' and the resource 'AP2 payment mandates' with a detailed list of attributes (status, currency, limits, budget, scope, expiry). It clearly distinguishes this tool from sibling tools like 'create_payment_mandate'.
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?
The description states 'Requires authentication' but does not explicitly specify when to use this tool versus alternatives or provide exclusions. Given the straightforward nature of listing mandates, it is minimally adequate but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_quotesARead-onlyIdempotentInspect
List the supplier quotes submitted for one of your inquiries (from request_quote). Returns each quote's id, unit price, total, MOQ, lead time and validity, plus acceptable_quote_ids you can pass to place_order. Requires authentication; only the inquiry's buyer (or the product's supplier) may read it.
| Name | Required | Description | Default |
|---|---|---|---|
| inquiry_id | Yes | The inquiry_id returned by request_quote |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds access control details (only buyer or supplier) and specifies the exact return fields, providing valuable context beyond annotations.
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?
The description is concise (three sentences), front-loaded with the main action, and every sentence adds value—purpose, return details with linking, and auth constraints.
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?
Despite no output schema, the description specifies all returned fields and links to relevant tools. It covers auth and access. Minor omission of pagination or error handling, but adequate for the tool's simplicity.
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 inquiry_id described as 'The inquiry_id returned by request_quote'. The tool description doesn't add new parameter-level semantics, so a baseline score of 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 clearly states the tool lists supplier quotes for an inquiry, specifies returned fields, and links to related tools like request_quote and place_order, making the purpose unambiguous and distinct from 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?
The description implies usage after request_quote and before place_order by mentioning acceptable_quote_ids, and notes authentication and access restrictions. While it doesn't explicitly state when not to use, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
place_orderAIdempotentInspect
Accept a supplier quote and create an order (status pending_payment) for one of your inquiries. Pass the inquiry_id and the chosen quote_id (from list_quotes' acceptable_quote_ids). Optionally pass a mandate_id (from create_payment_mandate) to auto-authorize the order against an AP2 payment mandate within its limits — the response then includes mandate_authorization (authorized/declined + reason). Returns the order id, order_no and a payment next_step. Idempotent per inquiry: re-calling returns the existing order. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | Yes | The quote_id to accept (from list_quotes' acceptable_quote_ids) | |
| inquiry_id | Yes | The inquiry_id (from request_quote / list_quotes) | |
| mandate_id | No | Optional AP2 payment mandate id (from create_payment_mandate) to auto-authorize this order within pre-approved limits. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds substantial behavioral details beyond annotations: idempotency per inquiry, authentication requirement, order status, mandate authorization behavior, and return fields. No contradiction with annotations (idempotentHint, readOnlyHint).
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?
Description is well-structured with the main action first, then details. Slightly dense but every sentence adds value. Could be split for readability but remains efficient.
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?
Despite no output schema, description fully explains return fields (order id, order_no, payment next_step, mandate_authorization) and covers idempotency and authentication. Complete for a create operation with optional flow.
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%, but description adds sourcing context: quote_id from list_quotes' acceptable_quote_ids, inquiry_id from request_quote/list_quotes, mandate_id from create_payment_mandate, enhancing meaning beyond schema definitions.
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 clearly states the tool accepts a supplier quote and creates an order with status pending_payment. It explicitly distinguishes from siblings by referencing list_quotes, request_quote, and create_payment_mandate as input sources.
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?
The description provides clear usage context: after requesting a quote and listing quotes. It explains optional mandate for auto-authorization and notes idempotency for safe retries. Lacks explicit 'when not to use' but is still well-guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_quoteAInspect
Start a transaction by sending a quote request (inquiry) to a supplier for a specific product_id (get one from search_products). Returns an inquiry_id. Requires authentication — the inquiry is owned by the authenticated buyer. The supplier then submits a quote; poll it with list_quotes.
| Name | Required | Description | Default |
|---|---|---|---|
| quantity | No | Desired quantity (optional) | |
| buyer_note | No | Free-text note to the supplier (optional) | |
| product_id | Yes | Product id to request a quote for (from search_products) | |
| quantity_unit | No | Unit for the quantity, e.g. 'pcs', 'kg' (optional) | |
| destination_city | No | Destination city (optional) | |
| destination_country | No | Destination country ISO2 (optional) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false. Description adds authentication requirement and ownership details, enhancing transparency beyond annotations.
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 sentences, efficient, front-loaded with purpose and immediate usage guidance. No wasted words.
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?
No output schema, but description specifies return of inquiry_id. Explains workflow and authentication, complementing sibling tools and schema.
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 covers all parameters with descriptions (100% coverage). Description adds context for product_id but does not significantly enhance understanding 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?
The description clearly states the tool initiates a quote request (inquiry) for a specific product_id from search_products, returns an inquiry_id, and distinguishes itself from sibling tools like search_products and list_quotes.
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 explicit workflow: obtain product_id from search_products, then poll with list_quotes. Does not explicitly state when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_productsARead-onlyIdempotentInspect
Search live products listed by ProcureRadar suppliers by keyword, destination country, supplier country, or category. Returns product_id values needed to request a quote. Free & anonymous (IP rate-limited). This is the first step of the buyer-side transaction loop: search_products → request_quote → list_quotes → place_order.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Keyword (product title / SKU / supplier name) | |
| limit | No | Max results (default 20, max 50) | |
| category | No | Category code (mall_category_code), optional | |
| country_iso | No | Destination country ISO2 (filters by deliverable SKUs) | |
| supplier_country | No | Supplier origin country ISO2 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is safe. The description adds value by mentioning 'Free & anonymous (IP rate-limited)', which informs the agent of rate limits and cost implications. It also states that it returns product_id values, clarifying the output beyond the schema.
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?
The description is three sentences with no wasted words. The first sentence front-loads the verb and resource, the second states the output and use, and the third adds behavioral context and workflow positioning. Every sentence serves a distinct purpose.
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?
Given the tool's simplicity and the rich schema and annotation coverage, the description is largely complete. It explains the output (product_id values) and places the tool in a transaction sequence. It does not detail the return format (e.g., array of objects), but the lack of an output schema and the focus on consuming agents makes this acceptable.
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?
The input schema has 100% description coverage, so each parameter is already documented. The description reiterates the filter dimensions (keyword, destination country, supplier country, category) but does not add significant new meaning beyond the schema. It provides a natural language summary but no additional constraints or format details.
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 clearly states the verb 'Search', the resource 'live products listed by ProcureRadar suppliers', and scope 'by keyword, destination country, supplier country, or category'. It also distinguishes from siblings by positioning it as the first step in the buyer-side transaction loop and noting it returns product_id values needed for request_quote.
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?
The description explicitly defines the tool's role as the first step in a transaction loop (search_products → request_quote → list_quotes → place_order), making its usage context clear. It also notes that it is 'Free & anonymous (IP rate-limited)', which guides usage expectations. It does not explicitly mention when not to use it, but the workflow context implies that it is for initiating quotes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_discovery_jobAInspect
Explicitly submit an async batch buyer discovery job for a category + country. Returns a job_id; poll it with check_discovery_task until status=completed. Note: find_buyers already auto-starts a background crawl when coverage is thin, so usually you only need this for a forced/fresh deep crawl.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Product category to discover buyers for | |
| keywords | No | Additional keywords to refine the search | |
| country_iso | Yes | Target country ISO code |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (readOnlyHint=false) but not destructive. The description adds the async nature, return of job_id, and polling instruction. No contradiction. Could mention side effects or rate limits.
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?
Three efficient sentences with no waste. Front-loaded with action and key points.
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?
No output schema, but the description explains the job_id return and polling process. For an async job, this is sufficient. Could note expected polling duration or error handling.
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 schema documents all parameters. The description only repeats 'category' and 'country', not adding details on keywords or format. 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 clearly specifies the verb 'submit' and the resource 'async batch buyer discovery job' along with required inputs 'category + country'. It distinguishes from sibling 'find_buyers' by noting the auto-start behavior.
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?
The description explicitly states when to use this tool ('forced/fresh deep crawl') and when not ('find_buyers already auto-starts...'), and names the alternative 'find_buyers'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!