Custom Blinds Shop

request_price_match

Read-only

Submit a price match claim when the customer has found the same blind at a lower price elsewhere. Custom Blinds matches verified South African retailer prices for identical product, dimensions, and specs. Returns a pre-filled WhatsApp link to the claims team. Not applicable to: Blinds Direct (same supplier), clearance or flash-sale prices, or out-of-stock items. Requires product_id and competitor_price_zar at minimum.

Input Schema

Name	Required	Description
`width_mm`	No	Window width in mm
`height_mm`	No	Window height/drop in mm
`product_id`	Yes	Product the customer wants to match (e.g. roller-blockout)
`customer_name`	No	Customer name
`competitor_url`	No	URL to competitor product page or quote
`competitor_name`	No	Name of the competitor (e.g. 'Blind Empire')
`customer_whatsapp`	No	Customer WhatsApp number for follow-up
`competitor_price_zar`	Yes	Competitor's price in ZAR (incl. VAT)

Output Schema

Name	Required	Description	Default
`note`	Yes
`message`	Yes
`success`	Yes
`exclusions`	Yes
`whatsapp_url`	Yes
`claim_summary`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 10, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "claim_summary": {
+      "additionalProperties": true,
+      "properties": {
+        "competitor": {
+          "type": "string"
+        },
+        "competitor_price_zar": {
+          "type": "string"
+        },
+        "dimensions": {
+          "type": "string"
+        },
+        "product_id": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "product_id",
+        "dimensions",
+        "competitor",
+        "competitor_price_zar"
+      ],
+      "type": "object"
+    },
+    "exclusions": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "message": {
+      "type": "string"
+    },
+    "note": {
+      "type": "string"
+    },
+    "success": {
+      "type": "boolean"
+    },
+    "whatsapp_url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "success",
+    "claim_summary",
+    "whatsapp_url",
+    "message",
+    "exclusions",
+    "note"
+  ],
+  "type": "object"
+}

First observedMay 28, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=true, and the description adds meaningful context beyond that: it discloses the actual output shape (a pre-filled WhatsApp link rather than a database write), the eligibility filter the claim is validated against, and the matching criteria. It does not cover turnaround, what happens if the claim is rejected, or any rate/auth constraints, so it is strong but not exhaustive.

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?

Three well-ordered sentences: purpose first, then exclusions, then requirements, with zero filler. Slightly dense in the exclusion clause, but every sentence carries distinct information.

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?

An output schema exists, yet the description still tells the agent the salient return value (WhatsApp link), plus eligibility rules and required inputs. For an 8-parameter, non-destructive submission tool, an agent has everything needed to decide and call 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 a baseline of 3 applies, but the description adds real value by naming the two minimum required fields and by explaining that product, dimensions, and specs must be identical for a claim to be verified — which is exactly why width_mm/height_mm exist. It stops short of describing competitor_url or customer_whatsapp usage.

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 ('Submit a price match claim') plus the triggering condition ('customer has found the same blind at a lower price elsewhere'). The scope is narrowed further by naming what qualifies (verified South African retailer prices, identical product/dimensions/specs), which leaves no ambiguity against sibling tools like get_price or submit_enquiry.

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?

Gives an explicit positive condition (customer found a lower price at another retailer), explicit exclusions ('Not applicable to: Blinds Direct, clearance or flash-sale prices, or out-of-stock items'), and the minimum prerequisites. This is textbook when/when-not guidance with no inference required.

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

All Custom Blinds Shop 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.