catalog

Server Details

Maritime VSAT spares: part search, fitment, supersession and quote requests for satmarin.com

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 31 days
Last Tested: 2026-10-13 15:43
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.3/5.0

Scored 2026-09-14 15:55 across 4 tools

Disambiguation5/5

Each tool covers a distinct operation: searching parts, checking fitment, resolving supersession, and requesting a quote. There is no meaningful overlap in purpose.

Naming Consistency5/5

All tools follow a consistent verb_noun snake_case convention: check_compatibility, get_quote, resolve_supersession, search_parts. The naming pattern is predictable and readable.

Tool Count5/5

Four tools is a well-scoped size for a catalog server, covering the essential user-facing operations without redundancy or unnecessary clutter.

Completeness5/5

The tool set covers the core catalog interactions: finding parts, checking fitment, handling discontinued products via supersession, and requesting quotations. No obvious metric gaps appear for a read-only catalog with quote functionality.

Available Tools

4 tools

check_compatibilityCheck compatibilityA

Read-only

Inspect

Does a part fit a given antenna model? Give sku or product_id, plus antenna_model. Answers from catalog fitment data only: true or false when the part has model-level fitment data, "unknown" when it has none or is fitted only at series level. An unrecognised model, or a brand or series name, returns an error instead of an answer.

ParametersJSON Schema

Name	Required	Description
`sku`	No	Part number. Give this or product_id.
`product_id`	No	Catalog product id. Give this or sku.
`antenna_model`	Yes	One antenna model, name or slug, e.g. v100NX or v60E. Case and spacing are ignored.

Output Schema

ParametersJSON Schema

Name	Required	Description
`sku`	Yes
`url`	Yes
`basis`	Yes
`compatible`	Yes
`antenna_model`	Yes	The resolved model slug.

TDQS

A4.4/5.0

Behavior4/5

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

The description goes beyond the readOnlyHint annotation by explaining the tool's decision logic: it returns true/false only when model-level fitment data exists, 'unknown' when only series-level data exists, and an error for unrecognized models. This is valuable behavioral context that the annotation alone does not provide.

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 compact and front-loaded: it states the core question, the required inputs, and the output behavior in three sentences. Every sentence adds meaningful information, and there is no redundancy with the schema or annotations.

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?

The description is complete for a read-only lookup tool: it covers inputs, output values, edge cases, and error behavior. The output schema exists, so return values are already documented. A minor gap is that it doesn't explicitly state that sku and product_id are mutually exclusive, but the schema's 'Give this or product_id' phrasing implies it.

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 parameters with descriptions, so the baseline is 3. The description adds value by clarifying that sku and product_id are alternatives ('Give this or product_id') and that antenna_model is case-insensitive and can be a name or slug. This enhances the schema's parameter documentation.

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 clearly states the tool's function: checking whether a part fits a given antenna model. It specifies the required inputs (sku or product_id, plus antenna_model) and the exact output semantics (true/false/unknown/error), which distinguishes it from sibling tools like search_parts or get_quote.

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 explains when to use the tool: when you need fitment data for a part and antenna model. It also clarifies what inputs to provide and what happens with unrecognized models or series-level data. It doesn't explicitly name alternatives, but the sibling list and the specific fitment focus make the usage context clear.

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

get_quoteRequest a quotationAInspect

Request a formal quotation for catalog parts. Creates a quote request and returns its reference; Satmarin replies within one working day. This call emails nothing to the requester.

ParametersJSON Schema

Name	Required	Description
`items`	Yes	1 to 20 lines. Every part number must be a live, quotable catalog product.
`notes`	No	Optional free text, up to 1000 characters.
`contact`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	Yes
`message`	Yes
`reference`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

Annotations indicate readOnly=false and destructive=false, so the tool is expected to create something without destruction. The description adds that it returns a reference, replies within one day, and emails nothing to the requester. This provides behavioral context beyond the annotations, such as asynchronous response and no email confirmation.

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 compact and front-loads the primary purpose and outcome. Two sentences with no fluff, and each part adds value: purpose, formal nature, output reference, response time, and a note about email behavior.

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?

The description covers the request procedure, response timing, and what is not emailed. Given the output schema exists (likely defines the reference), and the schema has adequate parameter details, the description is complete for the agent to use. It could be more complete with explicit mention that no immediate quote is returned, but the 'replies within one day' implies that.

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 items and contact in detail (67% coverage). The description does not repeat parameter details but clarifies the quote process and that items must be live catalog parts (though that is also in schema). It adds no new parameter semantics but the schema already handles it. Coverage is high so baseline is 3, and the description's slight clarification justifies a 4.

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 states that the tool requests a formal quotation for catalog parts and creates a quote request with a returned reference. It is specific to catalog quote creation, which differentiates it from sibling tools like search_parts. However, it does not explicitly contrast with each sibling, so a slight deduction.

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 implies usage context (requesting formal quotes) but does not explicitly state when to use this instead of siblings like check_compatibility or resolve_supersession. It provide no explicit when-not-to-use guidance. The context that it emails nothing is a minor guidance about what to expect.

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

resolve_supersessionResolve supersessionA

Read-only

Inspect

Is a part discontinued, and what replaces it? Give sku or product_id. Follows the replacement chain to the latest live product: successors lists the live replacements, supersedes lists the parts this one replaced.

ParametersJSON Schema

Name	Required	Description	Default
`sku`	No	Part number. Give this or product_id.
`product_id`	No	Catalog product id. Give this or sku.

Output Schema

ParametersJSON Schema

Name	Required	Description
`eol`	Yes
`sku`	Yes
`successors`	Yes
`supersedes`	Yes
`no_replacement`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

The description adds value beyond the read-only annotation by explaining the replacement chain behavior (follows chain to latest live product, lists successors and supersedes). This is useful context not provided by the schema. However, it doesn't disclose details like whether the tool returns partial chains or handles multiple inputs, but the annotation covers safety, so a 3 is appropriate.

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 efficient with minimal waste, clearly stating the purpose and the output fields (successors/supersedes) upfront. The key information is front-loaded, and every sentence earns its place.

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?

Given the tool's moderate complexity (2 parameters, one optional, with output schema), the description provides enough context to call it correctly. It explains the input selection and the replacement chain output. The presence of an output schema reduces the need to describe return values, so a 4 is justified.

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%, so both parameters are already documented in the schema. The description reinforces that you provide either sku or product_id, but doesn't add new details such as preferred input or precedence. Baseline 3 is correct given the high schema coverage.

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 states the tool resolves part discontinuation and provides successors, with a specific resource (parts) and action (resolve supersession). It distinguishes from siblings like search_parts (which searches for parts) and get_quote (pricing) by focusing on lifecycle and replacement chain, though it doesn't explicitly name alternatives.

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 provides clear context for when to use this tool: when a part is discontinued and you need to find replacements, and it implies the replacement chain behavior. However, it doesn't explicitly state when not to use it or mention alternatives, so guidance is good but not fully explicit.

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

search_partsSearch partsA

Read-only

Inspect

Search the Satmarin catalog by part number, model or free text. Order: exact SKU (case and separators ignored), SKU prefix, then words found in the title or description in any order. A word that names an antenna model, such as v100NX, also matches parts fitted to that model. Use the model filter to restrict results to one model or series.

ParametersJSON Schema

Name	Required	Description
`brand`	No	Exact brand slug, e.g. intellian.
`limit`	No	Default 10, maximum 25.
`model`	No	Antenna model or series, name or slug, e.g. v100NX or v-Series. Case and spacing are ignored; an unrecognised model returns an error.
`query`	Yes	Part number, model or free text.
`part_type`	No	Part type slug.

Output Schema

ParametersJSON Schema

Name	Required	Description
`match`	Yes
`total`	Yes
`results`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already convey readOnlyHint=true, covering the safety profile. The description goes beyond that by disclosing result ranking logic (exact SKU, prefix, then word order), case/separator handling for SKUs, and the non-obvious rule that antenna model words match parts fitted to that model. These are useful, non-schema-findable behavioral details.

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 four sentences long, with the core action front-loaded and no repeated information from the schema. Each sentence carries distinct value: the search purpose, the ranking, the model-word behavior, and the filter tip - so no waste.

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 the 100% schema description coverage, an existing output schema, and a readOnly annotation, the description supplies the only missing context: how search results are ordered and how the model filter should be used. No additional undocumented information is necessary to call the tool correctly.

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. The description adds value beyond the schema by explaining the relevance of the model parameter (restrict to model or series), and clarifies that the query accepts model words and how those match. This materially improves parameter understanding without being redundant.

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 states a specific verb (search), a specific resource (the Satmarin catalog), and enumerates the supported keys (part number, model, free text). It also specifies the exact ranking order of results, which makes it clearly distinguishable from non-search siblings like check_compatibility or get_quote.

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 provided: what you can search by, the order semantics, and a recommendation to use the model filter to scope results to a model or series. The description does not explicitly name alternative tools, but siblings are all non-search functions, so the when-to-use is essentially unambiguous.

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.

4 tool updatesSep 14, 2026

Changedcheck_compatibility4 fields changed

changedInput schema / properties / antenna_model / description

Previous value: -"Model slug or common name."New value: +"One antenna model, name or slug, e.g. v100NX or v60E. Case and spacing are ignored."

addedInput schema / properties / product_id / description
```
Added value: +"Catalog product id. Give this or sku."
```

addedInput schema / properties / sku / description

Added value: +"Part number. Give this or product_id."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "antenna_model": {
+      "description": "The resolved model slug.",
+      "type": "string"
+    },
+    "basis": {
+      "enum": [
+        "model_subcategory",
+        "no_fitment_data",
+        "series_level_fitment"
+      ],
+      "type": "string"
+    },
+    "compatible": {
+      "enum": [
+        true,
+        false,
+        "unknown"
+      ]
+    },
+    "sku": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "sku",
+    "antenna_model",
+    "compatible",
+    "basis",
+    "url"
+  ],
+  "type": "object"
+}

Changedget_quote1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "message": {
+      "type": "string"
+    },
+    "reference": {
+      "type": "string"
+    },
+    "status": {
+      "enum": [
+        "received"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "reference",
+    "status",
+    "message"
+  ],
+  "type": "object"
+}

Changedresolve_supersession3 fields changed

addedInput schema / properties / product_id / description
```
Added value: +"Catalog product id. Give this or sku."
```

addedInput schema / properties / sku / description

Added value: +"Part number. Give this or product_id."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "eol": {
+      "type": "boolean"
+    },
+    "no_replacement": {
+      "type": "boolean"
+    },
+    "sku": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "successors": {
+      "items": {
+        "properties": {
+          "sku": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "title": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "sku",
+          "title",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "supersedes": {
+      "items": {
+        "properties": {
+          "sku": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "title": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "sku",
+          "title",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "sku",
+    "eol",
+    "successors",
+    "supersedes",
+    "no_replacement"
+  ],
+  "type": "object"
+}

Changedsearch_parts3 fields changed

changedInput schema / properties / brand / description

Previous value: -"Exact brand slug."New value: +"Exact brand slug, e.g. intellian."

changedInput schema / properties / model / description

Previous value: -"Antenna model slug."New value: +"Antenna model or series, name or slug, e.g. v100NX or v-Series. Case and spacing are ignored; an unrecognised model returns an error."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "match": {
+      "enum": [
+        "exact_sku",
+        "prefix",
+        "text"
+      ],
+      "type": "string"
+    },
+    "results": {
+      "items": {
+        "properties": {
+          "brand": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "compatible_models": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "eol": {
+            "type": "boolean"
+          },
+          "part_type": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "price": {
+            "description": "EUR, ex works, VAT excluded. null when the part is discontinued or has no list price.",
+            "properties": {
+              "amount": {
+                "type": "number"
+              },
+              "basis": {
+                "enum": [
+                  "EXW"
+                ],
+                "type": "string"
+              },
+              "currency": {
+                "enum": [
+                  "EUR"
+                ],
+                "type": "string"
+              }
+            },
+            "required": [
+              "amount",
+              "currency",
+              "basis"
+            ],
+            "type": [
+              "object",
+              "null"
+            ]
+          },
+          "product_id": {
+            "type": "integer"
+          },
+          "sku": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "superseded_by": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "title": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "sku",
+          "product_id",
+          "title",
+          "brand",
+          "part_type",
+          "compatible_models",
+          "price",
+          "eol",
+          "superseded_by",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "total": {
+      "minimum": 0,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "results",
+    "total",
+    "match"
+  ],
+  "type": "object"
+}

4 tool updatesSep 12, 2026
- First observedcheck_compatibility
- First observedget_quote
- First observedresolve_supersession
- First observedsearch_parts

Related MCP Connectors

whobuildsit — space & defence hardware suppliers
com.whobuildsit
Find space and defence hardware suppliers and parts by specification, process and certification.
71
Jurk Shenzhen Electronic Component Sourcing B
uk.co.jurk
Shenzhen sourcing for hard-to-find, obsolete and EOL electronic components.
E-commerce & Retail
211
onlinecomponents-searchOAuth
com.onlinecomponents
Search real-time stock, pricing, and specs for electronic components on OnlineComponents.com
E-commerce & Retail Search
1
partsiq
io.github.partstable
Parts research for IT hardware brokers: PN normalization, validation, and pricing
Research & Data E-commerce & Retail Developer Tools
2

Related MCP Servers

Partglyph MCP Gateway
Research & Data Workplace & Productivity
akramyaslam
A
license
Not graded
quality
D
maintenance
Deterministic industrial parts replacement engine with official catalogs and expert accuracy checks
Updated 4 months ago (2026-06-07 01:22 UTC)
MIT
orbit-sentinel-mcp
Aerospace & Astrodynamics Search Government Data
Viventine-Space
A
license
A
quality
B
maintenance
Search 419,000+ LLM-extracted space regulatory filings from the FCC, ITU, UNOOSA, and FAA. Semantic search, entity dossiers, spectrum-band holdings, launch licenses, filing trends, and alerts.
Updated a day ago (2026-10-12 15:47 UTC)
22
1
MIT
Lift-Spares Parts Finderofficial
E-commerce & Retail Search
Elegant-Lift-Sweden-AB
F
license
Not graded
quality
B
maintenance
Enables finding elevator and lift spare parts in the Lift-Spares catalog by part number, description, make, model, or part type in any language, and retrieving a part's full identification details or requesting parts that are not on the website. Returns product page and cart links for ordering on the shop, without placing orders itself.
Updated 11 days ago (2026-10-02 11:36 UTC)
-
eosl-mcp
Search Open Data
Kranny36
A
license
A
quality
A
maintenance
Source-backed hardware end-of-life (EOL/EOSL) lookups by part number for enterprise gear — support status, end-of-sale and end-of-support dates, with the vendor's own bulletin URL on every answer. Unknown parts return found:false, never a guess.
Updated a month ago (2026-09-11 12:56 UTC)
5
1
Apache 2.0