F
licenseNot graded
qualityD
maintenanceEnables AI agents to browse product catalogs, search products with filters, and initiate checkouts, generating order summaries and checkout URLs.
-
ForthClear Liquidation Marketplace
Server Details
Search surplus and overstock inventory, request bulk quotes, and check out.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Available Tools
12 toolsbulk_export_ordersExport orders as CSVARead-onlyInspect
Export the calling seller's orders as CSV (Order ID, Product, Buyer, Quantity, Total, Status, Date). Thin adapter over POST /api/seller/orders/bulk-export — orders not owned by the caller are silently skipped. Returns the CSV body as a string plus the suggested filename.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| order_ids | Yes | Order ids belonging to the calling seller (max 200/request). Orders owned by anyone else are skipped. |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/title annotations, the description discloses two important behaviors: orders not owned by the caller are silently skipped, and the return value is the CSV body plus a suggested filename. This tells the agent exactly what to expect despite the lack of an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry all essential information: output format, column list, endpoint nature, scoping behavior, and return shape. There is no redundancy or filler.
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?
Given a single parameter, full schema coverage, and read-only annotations, the description provides everything needed to invoke the tool correctly. The explicit return format compensates for the missing output schema.
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%, including ownership and max 200 per request, so the schema already documents the only parameter. The description repeats the ownership constraint but adds no new parameter-level detail; baseline 3 is appropriate.
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?
The description opens with a specific verb and resource: 'Export the calling seller's orders as CSV', and clarifies the exact columns. This distinguishes it from sibling tools, none of which perform bulk order export.
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?
The description establishes clear context: it is for exporting order data as CSV and is scoped to the seller's own orders. It does not explicitly name alternatives or exclusion conditions, but the sibling list contains no comparable export tool, so the intended use is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bulk_mark_shippedBulk mark orders shippedAIdempotentInspect
Mark up to 200 of the calling seller's orders as shipped, optionally writing a shared tracking number / URL / carrier to every order. Thin adapter over POST /api/seller/orders/bulk-mark-shipped — same per-order ownership filter, idempotent re-runs, auto-detected carrier when only a tracking number is supplied. Returns per-order success/failure buckets.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| order_ids | Yes | Order ids belonging to the calling seller (max 200/request). Orders owned by anyone else are skipped. | |
| carrier_name | No | Carrier for the shipment. Omit to infer it from tracking_number. | |
| tracking_url | No | Tracking URL written to every listed order. | |
| tracking_number | No | Tracking number written to every listed order. Supplying this without carrier_name auto-detects the carrier. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses meaningful behaviors: idempotent re-runs, per-order ownership filtering, auto-detection of carrier when only a tracking number is supplied, shared tracking values written to every order, and per-order success/failure buckets in the response. This adds substantial context beyond the idempotentHint and destructiveHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences front-load the primary action, then add endpoint mapping, behavioral guarantees, and return format. Every sentence earns its place and there is no filler or repetition of schema content.
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?
For this complexity level, the description is complete: it states the batch limit, ownership constraint, optional tracking behaviors, idempotency, and the response summary. Since there is no output schema, the explicit mention of 'per-order success/failure buckets' gives the agent enough expectation of the return shape without over-specifying.
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?
The schema already covers all parameter descriptions at 100%, giving a baseline of 3. The description adds value by explaining the shared behavior of the optional tracking fields and the auto-detection relationship between carrier_name and tracking_number, which is not fully explicit in the schema alone.
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?
The description uses a specific verb and resource: 'Mark up to 200 of the calling seller's orders as shipped', which clearly distinguishes this bulk order action from sibling tools like bulk_export_orders and bulk_update_listings. It also specifies key constraints such as ownership, batch size, and optional tracking fields.
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?
The description gives clear context for when to use the tool: marking the caller's orders as shipped in bulk, with re-runs being idempotent and ownership enforced. It does not explicitly name alternatives or state when not to use the tool, but no sibling tool competes for the same action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bulk_update_listingsBulk update listing prices or MOQADestructiveInspect
Bulk update prices or minimum order quantities across up to 200 of the calling seller's product listings. Thin adapter over POST /api/products/bulk-update-price and /bulk-update-moq — same seller-ownership filter and per-product validation. Choose mode='price_set' (value=USD), 'price_percent_increase' / 'price_percent_decrease' (value=percent), or 'moq_set' (value=integer units).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | What to change and how: price_set writes an absolute USD price, price_percent_increase / price_percent_decrease adjust the current price by a percentage, moq_set writes a minimum order quantity. | |
| value | Yes | USD price for price_set, percent (0-1000) for percent modes, integer units (1-999999) for moq_set. | |
| product_ids | Yes | ForthClear product ids to update (max 200/request). |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds genuine value beyond annotations: the 200-per-request limit, the seller-ownership filter, per-product validation, and the fact that it is a thin adapter over two specific endpoints, which tells the agent the behavior mirrors those APIs. It does not disclose partial-failure semantics or what happens when some products fail validation, a gap for a destructive bulk operation.
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?
Roughly 60 words across three sentences, with the core purpose front-loaded in sentence one, mechanics in sentence two, and mode selection guidance in sentence three. Every sentence earns its place; no filler or repetition of the title. Minor deduction only because the adapter/endpoint detail in sentence two is somewhat implementation-specific, though still useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive bulk mutation with no output schema, the definition covers invocation well (what, scope, cap, modes, validation) but omits the response shape and partial-failure behavior — an agent cannot know whether a bulk call is all-or-nothing or per-item, nor what the return payload reports. These are material gaps given destructiveHint=true and the absence of an output schema.
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% — mode, value, and product_ids all carry descriptive text including the mode/value pairing and bounds. The description's third sentence reinforces the mode-to-value mapping ('price_set (value=USD)', 'moq_set (value=integer units)') but adds nothing the schema does not already state. Baseline 3 is appropriate since the schema carries the load and the description only confirms it.
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?
The first sentence names a specific verb ('Bulk update'), a concrete resource ('product listings'), and exact fields (prices or minimum order quantities), plus the 200-listing ceiling and owner scope ('calling seller's'). It is immediately distinguishable from every sibling: none of bulk_export_orders, bulk_mark_shipped, or create_listing cover price/MOQ mass mutation.
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 context is established: the operation applies only to the calling seller's own listings, caps at 200 per request, and reuses the same ownership filter and per-product validation as the underlying endpoints. The mode descriptions effectively tell the agent when each call form is appropriate. It stops short of explicitly naming alternatives or stating when not to use this tool, so no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_listingCreate a listingBInspect
Create a new product listing (seller tool)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sku | No | Seller's own stock-keeping unit, shown to buyers and used for reconciliation. | |
| name | Yes | Listing title shown to buyers and matched by catalogue search. | |
| category | Yes | Catalogue category. One of: electronics, apparel, home_goods, beauty, sports, kitchenware, office_supplies, toys, food_beverage, tools, other. | |
| quantity | Yes | Units available in this lot. | |
| condition | Yes | Standard liquidation condition grade (Task #72) | |
| description | No | Listing body copy: condition detail, packaging, lot composition. Buyers filter on its presence and agents summarise it. | |
| price_per_unit | Yes | Price in cents | |
| original_retail_price | No | Original retail price in cents |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| listing | Yes | |
| message | Yes | |
| success | Yes |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral detail beyond what annotations already provide: no explanation of side effects, listing visibility, duplicate/SKU behavior, auth requirements, or validation outcomes. It does not contradict the annotations, but it does not meaningfully increase transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence with no filler or repeated examples. It is short but appropriately structured for a tool whose detailed requirements live in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema, output schema, and annotations make the tool callable, but the description omits usage context, behavioral expectations, and relationships to sibling tools. It is minimally viable but not genuinely complete for an agent facing a variety of seller tools.
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 the schema fully documents all parameters. The description itself mentions no parameters, but the baseline of 3 applies because the structured schema carries the semantic burden.
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?
The description clearly identifies the action ('Create') and the resource ('new product listing'), and adds seller context. It distinguishes creation from sibling update tools, though it largely restates the title with only a little extra scope information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus bulk_update_listings or other seller tools, and no mention of prerequisites or alternatives. The word 'new' hints at create-vs-update, but that is minimal and not helpful enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pricing_recommendationGet pricing recommendationARead-onlyInspect
Get AI-powered pricing recommendation for inventory (seller tool)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Catalogue category. One of: electronics, apparel, home_goods, beauty, sports, kitchenware, office_supplies, toys, food_beverage, tools, other. | |
| quantity | No | Lot size being priced; recommendations scale with volume. | |
| condition | Yes | Standard liquidation condition grade (Task #72) | |
| original_retail | Yes | Original retail price in cents |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| tips | Yes | |
| factors | Yes | |
| price_range | Yes | |
| recommended_price | Yes | |
| discount_from_retail | Yes | Percent below original retail. |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as read-only and non-destructive, so the description does not need to repeat that. It adds that the output is an AI-powered recommendation rather than a guaranteed market price, but it does not discuss response behavior, edge cases, or any additional requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no filler; the core action and domain are front-loaded. Every phrase ('AI-powered,' 'pricing recommendation,' 'inventory,' 'seller tool') adds useful targeting information.
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 simple, read-only recommendation tool with full parameter documentation and an output schema, the description is largely sufficient. The only meaningful gap is the absence of explicit usage conditions, but an agent can still identify the tool and invoke it correctly from the structured fields.
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 the parameters are already well documented. The description adds no extra meaning about category, condition, quantity, or original_retail beyond that baseline.
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?
The description pairs a specific verb 'Get' with the resource 'pricing recommendation,' scoped to inventory and seller use. This clearly distinguishes the tool from siblings such as search_inventory or get_product_details, which cover different operations and resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context ('for inventory' and 'seller tool') but no explicit when-to-use or when-not-to-use guidance, and it names no alternative tools. The appropriate usage is implied rather than stated: call this when a seller needs an AI-powered pricing recommendation for inventory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_detailsGet product detailsBRead-onlyInspect
Get detailed information about a specific product
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | Product ID (format: product_123) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| price | Yes | Unit price in cents. |
| seller | No | |
| category | Yes | |
| condition | No | |
| description | No | |
| quote_required | Yes | |
| original_retail | No | |
| quantity_available | Yes |
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond that, such as response scope, pagination, or any special constraints. With an output schema present, some return details are covered, but the description itself contributes little.
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?
The description is a single short sentence with no redundant words, and it front-loads the core action. It could be slightly more informative by naming a sibling or specifying the return type, but for a simple get-by-id tool this is appropriately concise.
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?
This is a low-complexity tool with one parameter, full schema coverage, an output schema, and annotations covering safety. The description provides enough context to understand the tool's core purpose, and the missing usage guidance is partially mitigated by the clear 'specific product' wording. A more explicit sibling distinction would improve completeness, but nothing critical is missing.
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%, and the only parameter, product_id, is already documented with its format ('product_123'). The description does not add any additional semantic meaning, but the schema fully compensates, so the baseline of 3 is appropriate.
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?
The description uses a clear verb ('Get') and resource ('product'), and narrows the scope to a 'specific product,' which distinguishes it from broader search/list siblings like search_inventory. However, it does not explicitly name a sibling or clarify what 'detailed information' includes, leaving some ambiguity about which tools it contrasts with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'specific product' implies this is the right tool when a single product_id is known, rather than for bulk operations or inventory search. There is no explicit guidance about when not to use it or which sibling might be a better alternative, so the usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_quote_requestsGet incoming quote requestsARead-onlyInspect
Get pending quote requests for seller's products (seller tool)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Which of the calling seller's quote requests to return: pending (awaiting a reply), responded, or all. | pending |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| quotes | Yes | |
| message | Yes |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations by clarifying that results are scoped to the calling seller's products and that the default view is pending requests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. The key scoping information ('seller's products', 'seller tool') is included without repeating the schema's parameter details.
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 one-parameter read-only tool with an output schema and annotations covering safety, the description is nearly complete. It falls slightly short of 5 because it does not acknowledge the responded/all statuses or clarify the relationship to the closely related quote-request tools.
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 coverage is 100%: the status parameter has a clear description, enum values, and a default. The description adds no parameter-level meaning beyond what the schema already provides, so a baseline 3 is appropriate.
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?
The description identifies a specific verb and resource ('Get ... quote requests') and narrows scope to the seller's own products, which separates it from request_quote and respond_to_quote. It is slightly less than 5 because it says 'pending' as if that were the entire purpose, while the schema shows status can return responded or all requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context by marking this as a seller tool for incoming requests, so an agent can infer it is for viewing rather than creating or replying. However, it never explicitly states when to prefer this over respond_to_quote, request_quote, or seller_inbox_summarise, nor does it name those alternatives or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quick_buyQuick buyAInspect
One-step purchase for products with instant checkout enabled (seller opt-in) and orders under bulk threshold. For products without instant checkout or larger orders, use request_quote instead.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| quantity | Yes | Number of units to purchase | |
| buyer_name | No | Buyer's full name | |
| product_id | Yes | Product ID (format: product_123) | |
| buyer_email | Yes | Buyer's email address | |
| buyer_company | No | Buyer's company name |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that the purchase is one-step and depends on seller opt-in, but it does not disclose side effects like immediate charge, order confirmation, or whether the purchase is irreversible. Annotations only indicate non-read-only and non-idempotent, so more behavioral context would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy; the primary use case is front-loaded and the alternative is given in the second sentence. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers eligibility and alternatives well, but with no output schema, it does not tell the agent what to expect after a purchase (order ID, confirmation, or error behavior). This is the main missing piece for a side-effecting transaction tool.
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 all parameters are already documented in the schema. The description itself adds no parameter-level meaning, which is acceptable at the baseline.
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?
The description names a specific action ('One-step purchase'), a clear resource (products with instant checkout enabled and under bulk threshold), and contrasts with request_quote. This distinguishes it from siblings without requiring schema access.
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?
It explicitly states the conditions for quick_buy (instant checkout enabled and under bulk threshold) and the fallback to request_quote for products without instant checkout or larger orders. This is direct when-to-use/when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_quoteRequest a bulk quoteBInspect
Request a bulk quote for a product (buyer tool)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| message | No | Additional message to seller | |
| quantity | Yes | Number of units to quote | |
| buyer_name | No | Buyer's full name | |
| product_id | Yes | Product ID (format: product_123) | |
| buyer_email | Yes | Buyer's email address (required) | |
| target_price | No | Target price per unit in cents (optional) | |
| buyer_company | No | Buyer's company name |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| quote | Yes | |
| message | Yes | |
| success | Yes |
TDQS
B3.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond the annotations. It does not say that a quote request record is created, that the seller is notified, that it is non-idempotent, or anything about scope or side effects. Annotations already signal mutation, but the description itself contributes no extra behavioral transparency.
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?
The description is extremely concise and front-loaded with the core action. The '(buyer tool)' parenthetical adds genuinely useful contextual information. It loses one point because the main clause largely restates the title, but there is no wasteful or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple action with a fully documented schema, the description is minimally adequate. It covers what the tool does and who it is for. However, it leaves usage alternatives and behavioral outcomes unstated, which an agent may need when deciding between request_quote, quick_buy, and quote-related sibling tools.
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 the parameter definitions already document product_id, quantity, buyer_email, and optional fields. The description adds no param-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.
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?
The description uses a specific verb ('request'), a clear resource ('a bulk quote for a product'), and a critical contextual tag ('buyer tool'). This distinguishes it from seller-facing siblings like respond_to_quote and get_quote_requests, and the 'bulk' qualifier separates it from quick_buy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '(buyer tool)' implies this is for buyer-initiated quote requests, and 'bulk' implies it is for bulk purchasing rather than quick single purchases. However, there is no explicit when-to-use guidance, no mention of alternatives, and no warning not to use it for seller-side quote actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
respond_to_quoteRespond to a quote requestBInspect
Respond to a buyer's quote request (seller tool)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | accept the buyer's terms as asked, counter with a different price (requires counter_price), or decline the request. | |
| message | No | Optional note sent to the buyer alongside the decision. | |
| counter_price | No | Counter offer price in cents (for counter action) | |
| quote_request_id | Yes | Id of the quote request to answer, as returned by get_quote_requests. |
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is mutating but not destructive, non-idempotent, and not read-only. The description adds almost nothing about consequences: accepting, countering, or declining presumably changes the quote request state and notifies the buyer, but this is left unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence expresses the core action and audience with zero filler. The parenthetical '(seller tool)' is efficient and useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no mention of prerequisites, action-specific validation, or what happens after the response is submitted. Given this tool changes state across three distinct actions, the description alone leaves too much for the agent to infer from schema and sibling names.
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%, and the schema already explains the action enum, counter_price requirement, and quote_request_id origin. The description adds only seller/buyer framing, not additional parameter meaning.
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?
The description states a specific verb and resource: 'Respond to a buyer's quote request'. Adding '(seller tool)' distinguishes it from the buyer-side sibling request_quote, though it does not explicitly name that sibling. The purpose is clear enough for selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The seller-tool label implies this is for sellers responding to quote requests, but there is no explicit when-to-use guidance, no mention of get_quote_requests as a prerequisite, and no contrast with request_quote. Usage context is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_inventorySearch inventoryBRead-onlyInspect
Search available liquidation inventory with filters
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum listings to return (default 20, max 100). | |
| query | No | Search query | |
| category | No | Product category | |
| condition | No | Standard liquidation condition grade (Task #72) | |
| max_price | No | Maximum price in cents |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Catalogue matches before the limit is applied. |
| message | Yes | |
| products | Yes |
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the notion of 'available' inventory but doesn't disclose return behavior, sorting, or that all parameters are optional filters. With annotation coverage, this is adequate but not rich.
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?
The description is one sentence, front-loaded with the core action, and contains no filler. 'with filters' is slightly generic but doesn't waste words; it could have been more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a fully described schema and an output schema, and annotations cover safety, so the gaps are mostly around usage guidance and sibling differentiation. An agent can reasonably infer how to call it, but not when to prefer it over related read tools.
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 coverage is 100%; each parameter already has a description including default/max for limit and the enum for condition. The description's generic 'with filters' adds no parameter-specific meaning beyond the schema, so the baseline 3 applies.
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?
The description states a specific verb ('Search') and resource ('available liquidation inventory'), and mentions filters. It doesn't explicitly differentiate from sibling read tools like get_product_details, but the verb 'search' implies a list/scoped query rather than a single-item lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs alternatives, or when to use a sibling like get_product_details for individual item lookups. The description is a bare directive with no exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
seller_inbox_summariseSummarise seller inboxARead-onlyInspect
Read-only digest of the calling seller's inbox: pending quote requests, orders at risk of missing their ship-by deadline, and orders with reported issues. Useful for a daily standup or cron-driven agent that decides which bulk action to run next.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max items to surface in each bucket. | |
| window_hours | No | Look-ahead window for ship-by-date risk detection (default 24h). |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds behavioral context by specifying the three buckets of information and reaffirms 'Read-only digest', which is consistent. It doesn't introduce new security or mutation concerns, and the added detail about content goes 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the digest contents and followed by a concrete use case. Every word earns its place—no redundancy, filler, or restating of the title. It is highly compact and informative.
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 tool with no output schema, the description adequately explains what the digest includes and when to use it. It does not detail the output format (e.g., counts vs. items), but given the tool's summarize nature and the presence of sibling tools for granular details, this is acceptable. The safety profile is covered by annotations, so the description is complete enough for selection and invocation.
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?
The input schema covers 100% of the two parameters (limit and window_hours) with descriptions, including defaults and bounds. The tool description does not add extra parameter semantics beyond restating the input's purpose. Since schema coverage is high, the baseline of 3 applies; no additional value is provided.
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?
The description uses a specific verb ('summarise') and resource ('seller's inbox') and enumerates concrete content categories: pending quote requests, at-risk orders, and reported issues. This clearly distinguishes it from sibling tools like get_quote_requests or bulk_mark_shipped, which focus on single actions or data types.
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?
It states the intended context: 'Useful for a daily standup or cron-driven agent that decides which bulk action to run next.' This clarifies when to use it, aligning with the decision-making workflow. It does not explicitly mention when not to use it or name alternatives, but the use case is clear and enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
- Changed
create_listing1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "listing": { + "properties": { + "category": { + "type": "string" + }, + "condition": { + "type": [ + "string", + "null" + ] + }, + "id": { + "type": "string" + }, + "image_url": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "original_retail": { + "type": [ + "integer", + "null" + ] + }, + "price": { + "description": "Unit price in cents.", + "type": "integer" + }, + "quantity": { + "type": "integer" + }, + "sku": { + "type": [ + "string", + "null" + ] + }, + "status": { + "type": "string" + }, + "view_url": { + "description": "Buyer-facing listing page.", + "type": "string" + } + }, + "required": [ + "id", + "name", + "category", + "quantity", + "price", + "status", + "view_url" + ], + "type": "object" + }, + "message": { + "type": "string" + }, + "success": { + "type": "boolean" + } + }, + "required": [ + "success", + "message", + "listing" + ], + "type": "object" +}
- Changed
request_quote1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "message": { + "type": "string" + }, + "quote": { + "properties": { + "expected_response": { + "description": "Human-readable SLA, e.g. \"24-48 hours\".", + "type": "string" + }, + "id": { + "type": "integer" + }, + "product_id": { + "type": "string" + }, + "product_name": { + "type": "string" + }, + "quantity": { + "type": "integer" + }, + "seller_company": { + "type": "string" + }, + "status": { + "type": "string" + }, + "target_price": { + "description": "Buyer target per unit, as supplied.", + "type": [ + "number", + "null" + ] + } + }, + "required": [ + "id", + "product_id", + "product_name", + "quantity", + "status", + "expected_response" + ], + "type": "object" + }, + "success": { + "type": "boolean" + } + }, + "required": [ + "success", + "message", + "quote" + ], + "type": "object" +}
10 tool updates
- Changed
bulk_export_orders1 field changed- added
Input schema / properties / order_ids / descriptionAdded value: +"Order ids belonging to the calling seller (max 200/request). Orders owned by anyone else are skipped."
- Changed
bulk_mark_shipped4 fields changed- added
Input schema / properties / carrier_name / descriptionAdded value: +"Carrier for the shipment. Omit to infer it from tracking_number." - added
Input schema / properties / order_ids / descriptionAdded value: +"Order ids belonging to the calling seller (max 200/request). Orders owned by anyone else are skipped." - added
Input schema / properties / tracking_number / descriptionAdded value: +"Tracking number written to every listed order. Supplying this without carrier_name auto-detects the carrier." - added
Input schema / properties / tracking_url / descriptionAdded value: +"Tracking URL written to every listed order."
- Changed
bulk_update_listings1 field changed- added
Input schema / properties / mode / descriptionAdded value: +"What to change and how: price_set writes an absolute USD price, price_percent_increase / price_percent_decrease adjust the current price by a percentage, moq_set writes a minimum order quantity."
- Changed
create_listing6 fields changed- added
Input schema / properties / category / descriptionAdded value: +"Catalogue category. One of: electronics, apparel, home_goods, beauty, sports, kitchenware, office_supplies, toys, food_beverage, tools, other." - added
Input schema / properties / category / enumAdded value: +[ + "electronics", + "apparel", + "home_goods", + "beauty", + "sports", + "kitchenware", + "office_supplies", + "toys", + "food_beverage", + "tools", + "other" +] - added
Input schema / properties / description / descriptionAdded value: +"Listing body copy: condition detail, packaging, lot composition. Buyers filter on its presence and agents summarise it." - added
Input schema / properties / name / descriptionAdded value: +"Listing title shown to buyers and matched by catalogue search." - added
Input schema / properties / quantity / descriptionAdded value: +"Units available in this lot." - added
Input schema / properties / sku / descriptionAdded value: +"Seller's own stock-keeping unit, shown to buyers and used for reconciliation."
- Changed
get_pricing_recommendation4 fields changed- added
Input schema / properties / category / descriptionAdded value: +"Catalogue category. One of: electronics, apparel, home_goods, beauty, sports, kitchenware, office_supplies, toys, food_beverage, tools, other." - added
Input schema / properties / category / enumAdded value: +[ + "electronics", + "apparel", + "home_goods", + "beauty", + "sports", + "kitchenware", + "office_supplies", + "toys", + "food_beverage", + "tools", + "other" +] - added
Input schema / properties / quantity / descriptionAdded value: +"Lot size being priced; recommendations scale with volume." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "discount_from_retail": { + "description": "Percent below original retail.", + "type": "number" + }, + "factors": { + "items": { + "type": "string" + }, + "type": "array" + }, + "price_range": { + "properties": { + "high": { + "type": "number" + }, + "low": { + "type": "number" + } + }, + "required": [ + "low", + "high" + ], + "type": "object" + }, + "recommended_price": { + "type": "number" + }, + "tips": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "recommended_price", + "price_range", + "discount_from_retail", + "factors", + "tips" + ], + "type": "object" +}
- Changed
get_product_details1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "category": { + "type": "string" + }, + "condition": { + "type": [ + "string", + "null" + ] + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "original_retail": { + "type": [ + "integer", + "null" + ] + }, + "price": { + "description": "Unit price in cents.", + "type": "integer" + }, + "quantity_available": { + "type": "integer" + }, + "quote_required": { + "type": "boolean" + }, + "seller": { + "properties": { + "company": { + "type": "string" + }, + "verified": { + "description": "True once the seller has a Stripe account.", + "type": "boolean" + } + }, + "required": [ + "company", + "verified" + ], + "type": "object" + } + }, + "required": [ + "id", + "name", + "category", + "quantity_available", + "price", + "quote_required" + ], + "type": "object" +}
- Changed
get_quote_requests2 fields changed- added
Input schema / properties / status / descriptionAdded value: +"Which of the calling seller's quote requests to return: pending (awaiting a reply), responded, or all." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "message": { + "type": "string" + }, + "quotes": { + "items": { + "properties": { + "buyer_company": { + "type": "string" + }, + "created_at": { + "description": "ISO-8601 timestamp.", + "type": "string" + }, + "id": { + "type": "integer" + }, + "message": { + "type": [ + "string", + "null" + ] + }, + "product_id": { + "type": "string" + }, + "product_name": { + "type": "string" + }, + "quantity": { + "type": "integer" + }, + "status": { + "type": "string" + }, + "target_price": { + "description": "Buyer target in cents.", + "type": [ + "integer", + "null" + ] + } + }, + "required": [ + "id", + "product_id", + "quantity", + "status", + "created_at" + ], + "type": "object" + }, + "type": "array" + }, + "total": { + "type": "integer" + } + }, + "required": [ + "quotes", + "total", + "message" + ], + "type": "object" +}
- Changed
quick_buy1 field changed- removed
Input schema / properties / shipping_countryRemoved value: -{ - "description": "Two-letter country code (e.g., US, GB)", - "type": "string" -}
- Changed
respond_to_quote3 fields changed- added
Input schema / properties / action / descriptionAdded value: +"accept the buyer's terms as asked, counter with a different price (requires counter_price), or decline the request." - added
Input schema / properties / message / descriptionAdded value: +"Optional note sent to the buyer alongside the decision." - added
Input schema / properties / quote_request_id / descriptionAdded value: +"Id of the quote request to answer, as returned by get_quote_requests."
- Changed
search_inventory3 fields changed- added
Input schema / properties / limit / descriptionAdded value: +"Maximum listings to return (default 20, max 100)." - removed
Input schema / properties / min_discountRemoved value: -{ - "maximum": 100, - "minimum": 0, - "type": "integer" -} - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "message": { + "type": "string" + }, + "products": { + "items": { + "properties": { + "category": { + "type": "string" + }, + "condition": { + "type": [ + "string", + "null" + ] + }, + "discount_percent": { + "description": "Null when the listing has no original retail price on file.", + "type": [ + "integer", + "null" + ] + }, + "id": { + "description": "Opaque listing id, `product_<n>`.", + "type": "string" + }, + "name": { + "type": "string" + }, + "price": { + "description": "Unit price in cents.", + "type": "integer" + }, + "quantity": { + "type": "integer" + } + }, + "required": [ + "id", + "name", + "category", + "quantity", + "price" + ], + "type": "object" + }, + "type": "array" + }, + "total": { + "description": "Catalogue matches before the limit is applied.", + "type": "integer" + } + }, + "required": [ + "products", + "total", + "message" + ], + "type": "object" +}
12 tool updates
- First observed
bulk_export_orders - First observed
bulk_mark_shipped - First observed
bulk_update_listings - First observed
create_listing - First observed
get_pricing_recommendation - First observed
get_product_details - First observed
get_quote_requests - First observed
quick_buy - First observed
request_quote - First observed
respond_to_quote - First observed
search_inventory - First observed
seller_inbox_summarise
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Related MCP Connectors
Search real parts with datasheet-provenance specs, check compatibility and compose priced BOMs.
Turn designs into shipped parts: quote 3D printing, CNC, and decals, then check out.
Wholesale BOM pricer: send a parts list, get a priced line-by-line quote by email in minutes.
Search multi-merchant supply, checkout, and track orders via MCP.
Related MCP Servers
- AlicenseNot gradedqualityNot gradedmaintenanceEnables searching for electronic components through the Nexar Supply API, providing detailed part information including manufacturer, pricing, specifications, and datasheets.-
- AlicenseAqualityBmaintenanceSearches electronic components across DigiKey and Mouser, enabling keyword search, part details, and merged offers with price comparison.4MIT
- AlicenseBqualityAmaintenanceEnables Claude to search and manage electronic components, PCB parts, and manufacturing services through direct access to the Source Parts API. Provides comprehensive product search, pricing, inventory checking, and parametric filtering capabilities for electronics procurement.1001Apache 2.0
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A3.6/5.0
Disambiguation4/5
Most tools target distinct resource/action pairs: search vs details, quote request vs response, bulk export vs bulk ship. The main overlaps are get_quote_requests vs seller_inbox_summarise and quick_buy vs request_quote, but their descriptions provide enough boundary to avoid serious misselection.
Naming Consistency4/5
The majority of tools follow a verb_noun pattern with a clear bulk_ prefix for bulk operations. Minor deviations like quick_buy and seller_inbox_summarise (object before verb) slightly break the pattern, but the naming remains broadly predictable.
Tool Count5/5
12 tools is well within the ideal range for a two-sided marketplace server. Each tool covers a meaningful seller or buyer workflow without feeling redundant or bloated.
Completeness3/5
Core workflows are covered: search, product details, quote negotiation, listing creation, bulk updates, bulk shipping, and export. Notable gaps include no single listing delete/update, no buyer-facing order or quote status tool, and no action to resolve reported issues surfaced by seller_inbox_summarise.