catalog

Check compatibility

check_compatibility

Read-only

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.

Input Schema

TableJSON 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

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 14, 2026

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"
+}

First observedSep 12, 2026

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.

All catalog tools Inspect

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?