Mati Logistics — supplier sourcing

by com.matilogistics

Overview Discussions Admin

Server Details

Find suppliers ranked for fit across customs records, catalogues and directories

Ownership verified

Status: Healthy
Uptime: 81.8% over 22 days
Last Tested: 2026-10-21 19:26
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.5/5.0

Scored 2026-10-17 09:00 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct role: discover_suppliers searches for candidates, get_supplier inspects one supplier, get_coverage describes the database, and get_usage reports quota. There is no overlap in purpose and the descriptions reinforce when to use each.

Naming Consistency5/5

All four names follow a consistent verb_noun snake_case pattern (discover_suppliers, get_coverage, get_supplier, get_usage). The only variation is discover vs get, which accurately reflects a search action versus retrieval.

Tool Count4/5

Four tools is on the lean side but each earns its place for a focused, read-only supplier-sourcing server. It covers search, detail, scope-checking, and quota, though it feels minimal with no result-refinement or pagination tools.

Completeness4/5

The surface covers the core sourcing loop well: assess coverage, discover ranked suppliers, inspect a single supplier, and check usage. Minor gaps exist around refining or paginating large result sets, but the read-only lifecycle is essentially complete with no dead ends.

Available Tools

4 tools

discover_suppliersDiscover suppliersA

Read-only

Inspect

Finds suppliers and manufacturers for a product or category and ranks them by fit with the request. Use it when someone needs suppliers for something, from a specific part to a broad category. It searches everything Mati Logistics holds (US customs records, supplier catalogues, industry directories and registers, company websites) and scores each candidate against the request. Returns the ranked list, often dozens of companies, each with a 0-100 fit score, a one-line reason, its role (manufacturer, packer_brand, distributor), country, shipment and catalogue counts, and the url of its page; plus how many companies were searched. Only search_for is needed: a sentence saying what kind of suppliers are wanted. phrases and hs_headings are optional search terms; when left out they are written from search_for, and the result shows the terms used under search_terms. Read-only, no side effects. Takes 10-20 seconds. Spends about one credit of a connected account; without an account, one free search a day per network address.

ParametersJSON Schema

Name	Required	Description
`phrases`	No	6-16 short phrases (1-3 words) covering the request widely, as goods are written on a customs filing or a catalogue. Put the goods themselves first, exactly as the person means them ('taco shells'), then the closest variants, then the wider terms: for a category, its main products and the trade's terms ('soybean oil', 'tallow', 'shortening', 'olive oil' for oils and fats). Every word of a phrase must match, so keep them short; no country names.
`countries`	No	Supplier countries to require, full English names. Empty unless the person asked.
`attributes`	No	Up to 3 things a buyer of these goods would compare suppliers on, as short column names in the person's language — whatever fits this request: for oils and fats, 'Oil types', 'Organic', 'Bulk or packaged'; for fasteners, 'Standards', 'Materials'. Each is filled per supplier from our records and shown as a column. Never the kind of company or its country: every row shows those already. Empty for none.
`search_for`	Yes	What kind of suppliers are you looking for? A sentence: the goods, and any location, kind of company (maker or distributor), certification or other requirement. Results are ranked against it.
`hs_headings`	No	Up to 6 four-digit HS headings for the goods (1507 soybean oil, 1502 tallow). Empty if unsure.
`company_types`	No	Only these kinds of company: manufacturer (makes it), packer_brand (packs or sells it under its brand), distributor (imports, trades, resells). Empty unless the person asked for a kind.
`exclude_slugs`	No	Suppliers to leave out, by slug: for similar or alternative suppliers, the one they started from. Empty otherwise.
`exclude_countries`	No	Supplier countries to leave out. Empty unless the person asked.

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the readOnly/openWorld annotations: it discloses latency (10-20 seconds), cost (about one credit), a rate limit (one free search a day per network address without an account), and confirms no side effects. These are exactly the operational facts an agent needs before firing a slow, credit-spending search.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and usage first, then behavioral and parameter detail. It is dense and the closing cost sentence is long, but nearly every clause carries information the agent would otherwise have to guess at.

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?

With no output schema, the description carries the return contract fully — ranked list, 0-100 fit score, reason, role, country, shipment/catalogue counts, page url, plus the searched-company count. Latency, credit cost and the free-search fallback round out a complete picture for an 8-parameter search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: only search_for is required, phrases/hs_headings are optional and auto-derived from search_for, and the derived terms come back under search_terms — an input/output linkage the schema does not express.

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?

States a specific verb (finds), resource (suppliers/manufacturers for a product or category) and the differentiating behavior — ranking by fit with the request. This clearly separates it from retrieval siblings like get_supplier or get_coverage.

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?

"Use it when someone needs suppliers for something, from a specific part to a broad category" gives clear scope and spans narrow-to-broad requests. It stops short of explicitly excluding or routing to siblings (e.g. get_supplier for a known company), so it is context without exclusions.

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

get_coverageGet coverageA

Read-onlyIdempotent

Inspect

Returns what the Mati Logistics supplier database covers: a summary (total suppliers and industries), then the kinds of data held on a supplier (company facts, products, capabilities, certifications, customers, people, contact fields) as a list of fields, then each industry with its supplier count, main countries, number of sub-industries with a sample, and a link. Use it to judge whether a search here suits a request, and for phrases to search with. Takes no arguments. Read-only, no side effects, free.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally; the description nonetheless adds that it takes no arguments, has no side effects, and is free (a cost/rate-limit signal not present in annotations). It stops short of describing pagination or response size behavior.

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?

Dense but front-loaded: the coverage summary and per-industry breakdown come first, followed by the usage hint and the no-argument/read-only notes. The long chained sentence describing return structure is information-dense rather than padded.

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?

With no output schema present, the description carries the burden of explaining the return shape and does so thoroughly (summary totals, field list, per-industry counts, countries, sample sub-industries, link). Nothing an agent needs to decide to call it is missing.

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?

Zero parameters, which is the baseline-4 case, and the description reinforces this with 'Takes no arguments,' removing any ambiguity about whether filters are accepted.

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?

States a specific verb and resource ('Returns what the Mati Logistics supplier database covers') and then enumerates the concrete sections of the response (summary, supplier field kinds, per-industry counts). An agent can distinguish this coverage/overview tool from get_supplier or discover_suppliers without opening any schema.

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?

Explicitly states when to use it: 'to judge whether a search here suits a request, and for phrases to search with.' This gives clear usage context, though it does not name a sibling alternative (e.g., discover_suppliers) as the contrasting action.

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

get_supplierGet supplierA

Read-onlyIdempotent

Inspect

Returns one supplier's public profile on Mati Logistics. Use it to look closer at a supplier from discover_suppliers. Returns its overview, highlights, products, customers, capabilities, certifications, shipment count, similar suppliers and the url of its page; fields the page shows only to signed-in readers are left out and counted as locked. Contact details are never included; the page and its rfq_url are how to reach the supplier. Read-only, no side effects, free.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	The supplier's slug, as returned by discover_suppliers (e.g. "acme-valves-co"). A /supplier/<slug> path is accepted too.

TDQS

A4.4/5.0

Behavior5/5

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

Even though annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, the description adds substantial non-obvious behavior: signed-in-only fields are omitted and counted as `locked`, contact details are never returned, and `rfq_url` is the reach mechanism. That is exactly the kind of disclosure annotations cannot carry.

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?

A single dense paragraph that is front-loaded with the core purpose and the sibling link, then the return-field list. It is on the long side, but nearly every clause carries information the agent needs.

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

Completeness5/5

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

There is no output schema, yet the description enumerates the returned sections (overview, highlights, products, customers, capabilities, certifications, shipment count, similar suppliers, url) and the locked-field behavior, so an agent knows what to expect without a 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 coverage is 100% and the slug parameter is fully documented there, including the '/supplier/<slug>' path variant. The description adds no parameter-level syntax or format detail beyond the schema, so the baseline of 3 applies.

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?

States a specific verb and resource ('Returns one supplier's public profile') and explicitly scopes it to a single supplier, which distinguishes it from the plural discover_suppliers sibling. An agent can tell immediately what it retrieves.

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?

Explicitly says to use it 'to look closer at a supplier from discover_suppliers,' tying it to the upstream call and making the discover-then-detail flow obvious. It doesn't state explicit when-not conditions, but the alternative is implied clearly.

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

get_usageGet usageA

Read-onlyIdempotent

Inspect

Returns how much supplier search this connection has left and how to get more. Use it before a search, or after one is refused. Without an account: the free searches left today and when they reset. With a connected account: the credits left and about how many searches they cover. Takes no arguments. Read-only, no side effects, free.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint/destructiveHint/idempotent, but the description adds real value: it discloses that output differs by account state, includes quota reset timing, and notes the call is free. This is exactly the kind of rate-limit/auth-state context the annotations cannot convey.

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?

Sentences are short and front-loaded, with the return semantics early and the argument/behavior notes last. The closing 'Read-only, no side effects' mildly duplicates the annotations, so it is not perfectly waste-free.

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?

With no output schema and no parameters, the description carries the full burden for return values and does so for both account states, including reset behavior. Nothing an agent needs to invoke or interpret this call is missing.

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 tool takes zero parameters, so the baseline is 4. The description confirms this explicitly with 'Takes no arguments,' leaving no ambiguity for the agent.

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 resource (remaining supplier-search allowance) and states exactly what it returns, breaking the result into two modes (free searches left today vs. credits left with an account). An agent can distinguish this quota-lookup from data-returning siblings like discover_suppliers or get_supplier purely from the text.

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 gives explicit when-to-use conditions: 'Use it before a search, or after one is refused.' That is clear operational context. It stops short of naming alternatives or when-not-to-use cases, so it does not reach the top of the scale.

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.

1 tool updateOct 9, 2026

Changeddiscover_suppliers4 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

removedInput schema / properties / request

Removed value: -{
-  "description": "What the person wants, in a sentence, as the scoring brief: the goods, and any location, kind of company (maker or distributor), certification or other requirement they gave.",
-  "type": "string"
-}

addedInput schema / properties / search_for

Added value: +{
+  "description": "What kind of suppliers are you looking for? A sentence: the goods, and any location, kind of company (maker or distributor), certification or other requirement. Results are ranked against it.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "request"
-]New value: +[
+  "search_for"
+]

1 tool updateOct 9, 2026
- Changeddiscover_suppliers1 field changed
  - changedInput schema / required
```
Previous value: -[
-  "request",
-  "phrases"
-]New value: +[
+  "request"
+]
```
8 tool updatesOct 9, 2026
- Addeddiscover_suppliers
- Addedget_coverage
- Removedget_product
- Changedget_supplier1 field changed
  - changedInput schema / properties / slug / description
```
Previous value: -"The supplier slug from a search result."New value: +"The supplier's slug, as returned by discover_suppliers (e.g. \"acme-valves-co\"). A /supplier/<slug> path is accepted too."
```
- Addedget_usage
- Removedmatch_bom
- Removedsearch_products
- Removedsearch_suppliers
5 tool updatesSep 30, 2026
- First observedget_product
- First observedget_supplier
- First observedmatch_bom
- First observedsearch_products
- First observedsearch_suppliers

Publisher details

Operator: Mati Logistics · Publisher source
Operator website: https://matilogistics.com/ · Publisher source
Vendor relationship: Not applicable
Documentation: https://www.matilogistics.com/mcp · Publisher source
Trust center: Not available
Restrictions: Not applicable

Related MCP Connectors

Gemalli B2B Trade A
com.gemalli
Global B2B trade: verified manufacturers, product search, sanctions screening, HS codes.
E-commerce & Retail Legal & Compliance Search
211
The Company Atlas
io.github.IndoTender
Global customs trade data and company registry. Search shipments, and look up legal entities.
Search Government Data Research & Data
2
Vibe Manufacturing B
com.vibe-manufacturing
Find manufacturers worldwide, match a part spec to suppliers, estimate cost, request quotes.
E-commerce & Retail Search
241
ProspOAuth
cc.prosp
B2B prospect discovery: find companies by industry, size and market, checked against registers.
CRM Marketing Search
1

Related MCP Servers

Market Map MCP Server
jam4fox99
A
license
Not graded
quality
C
maintenance
Analyzes early government notices to produce an evidence-backed map of plausible supplier companies with deterministic scoring and exact citation validation.
Updated 3 months ago (2026-07-20 21:05 UTC)
MIT
Manufacturer and Supplier
Search Web Scraping Browser Automation
mambalabsdev
A
license
Not graded
quality
B
maintenance
Give it a product and a country and it searches Google for manufacturers, wholesalers, and distributors, reads each candidate company's own website, and returns only the ones whose pages back up the claim, with quoted evidence, the domain, and a confidence score. Directories, marketplaces, and social networks are filtered out, and a free summary row reports how many sites were found and checked when nothing qualifies.
Updated 6 hours ago (2026-10-21 13:32 UTC)
1
MIT
genome-map
Finance Research & Data
rdcahalane
A
license
Not graded
quality
D
maintenance
Access industrial fingerprint data for insight into supply chain and company performance
Updated 5 months ago (2026-05-09 21:15 UTC)
MIT
databid
Search Research & Data
indiano881
A
license
Not graded
quality
D
maintenance
Agent-native company intelligence. AI agents search and retrieve structured, verified company context (certifications, capabilities, capacity, lead times) for manufacturing & supply chain via 5 MCP tools.
Updated 7 months ago (2026-04-04 17:40 UTC)
MIT

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?