Mahonia

One catalog product, every variant

get_catalog_product

Read-onlyIdempotent

One product's variants (sizes, lengths, temperature ratings) with the cited weight and source of each. Give a catalog id from search_catalog, or the brand and product name.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	A catalog row id; its siblings are the other variants.
`name`	No	The product name without brand or variant.
`brand`	No

Output Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	The product name, without brand or variant.
`brand`	Yes
`category`	Yes
`variants`	Yes	Every active variant, in variant order.
`gear_type`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 12, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "brand": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "category": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "gear_type": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "name": {
+      "description": "The product name, without brand or variant.",
+      "type": "string"
+    },
+    "variants": {
+      "description": "Every active variant, in variant order.",
+      "items": {
+        "properties": {
+          "id": {
+            "description": "The catalog row id, the one add_items and create_list take as catalog_id.",
+            "type": "integer"
+          },
+          "kcal": {
+            "description": "Calories per unit, on food.",
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "source_url": {
+            "description": "The page the weight was read from.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "variant": {
+            "description": "Size, length or rating; null on a product sold one way.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "verified": {
+            "description": "Whether the cited weight has been verified.",
+            "type": "boolean"
+          },
+          "weight_g": {
+            "description": "The cited weight in grams, to a tenth.",
+            "type": "number"
+          },
+          "weight_source": {
+            "description": "Where the weight comes from.",
+            "enum": [
+              "manufacturer",
+              "measured",
+              "community",
+              "imported"
+            ],
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "variant",
+          "weight_g",
+          "verified",
+          "weight_source",
+          "kcal",
+          "source_url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "brand",
+    "name",
+    "gear_type",
+    "category",
+    "variants"
+  ],
+  "type": "object"
+}

First observedSep 12, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds that results carry weights and their sources, which is useful framing but largely a summary of what the output schema already encodes. It says nothing about behavior on unknown ids, multiple brand/name matches, or result limits.

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 compact sentences with zero filler, and the core payload (variants plus cited weight and source) is front-loaded before the invocation guidance.

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?

With an output schema present, the description need not enumerate return fields, and it adequately covers both input modes and the shape of the payload. A brief note on id-vs-name precedence would close the remaining gap.

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 67% and one parameter (brand) is undocumented in the schema; the description compensates by explaining that id and the brand+name pair are alternative lookup modes and that the id comes from search_catalog. It does not, however, state precedence when both are supplied or how name matching works.

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?

Specific verb and resource: retrieves one product's variants (sizes, lengths, temperature ratings) along with each variant's cited weight and source. It also distinguishes itself from the sibling search_catalog by naming it as the origin of the id, so an agent can tell the lookup tool from the discovery tool.

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 states the two ways to invoke it: 'Give a catalog id from search_catalog, or the brand and product name.' That routes the agent through search_catalog first when it lacks an id. It stops short of explicit when-not-to-use guidance or failure behavior for ambiguous names.

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

All Mahonia 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.