Custom Blinds Shop

get_ar_visualizer_url

Read-only

Returns the link to the Custom Blinds Visualiser (See it before you buy it), pre-selected to the product when it is supported. The customer adds a photo of their window (any angle), picks a blind and colour, and previews it on their own window. A preview of colour and style, not a measuring tool. No measuring or marking. A name and WhatsApp number are needed; 2 free previews per customer. Also returns the measuring guide (mode 'measure' makes it the main url) and the list of supported products. A customer still unsure of sizes can order with best guess sizes, receive a free tape measure and confirm before production starts. Use when a customer wants to see how a blind or colour will look before ordering, or is unsure how to measure.

Input Schema

Name	Required	Description	Default
`mode`	No	Which link goes in url: visualize (own-window visualiser), measure (measuring guide) or both (visualiser, the default). Both links are always returned.
`product_id`	No	Optional. Pre-select a product in the visualiser (e.g. roller-blockout, double-roller-zebra, outdoor-blinds).

Output Schema

Name	Required	Description	Default
`url`	Yes
`note`	Yes
`product_id`	No
`measure_url`	Yes
`visualiser_url`	Yes
`supported_products`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 26, 2026

changedInput schema / properties / mode / description

Previous value: -"Which tool to surface. Default: both."New value: +"Which link goes in url: visualize (own-window visualiser), measure (measuring guide) or both (visualiser, the default). Both links are always returned."

changedInput schema / properties / product_id / description

Previous value: -"Optional. Pre-select a product in the visualizer (e.g. roller-blockout, venetian-25mm-aluwood)."New value: +"Optional. Pre-select a product in the visualiser (e.g. roller-blockout, double-roller-zebra, outdoor-blinds)."

addedOutput schema / properties / measure_url
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / supported_products

Added value: +{
+  "items": {
+    "additionalProperties": true,
+    "properties": {
+      "label": {
+        "type": "string"
+      },
+      "product_id": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "product_id",
+      "label"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / visualiser_url
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / required

Previous value: -[
-  "url",
-  "note"
-]New value: +[
+  "url",
+  "visualiser_url",
+  "measure_url",
+  "note"
+]

Changed7 schema fields changedOct 20, 2026

removedOutput schema / properties / ar_measurement_note
```
Removed value: -{
-  "type": "string"
-}
```
removedOutput schema / properties / ar_measurement_url
```
Removed value: -{
-  "type": "string"
-}
```

addedOutput schema / properties / product_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

removedOutput schema / properties / product_visualizer_note
```
Removed value: -{
-  "type": "string"
-}
```
removedOutput schema / properties / product_visualizer_url
```
Removed value: -{
-  "type": "string"
-}
```
addedOutput schema / properties / url
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / required

Previous value: -[
-  "note"
-]New value: +[
+  "url",
+  "note"
+]

Changed1 schema field changedOct 10, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "ar_measurement_note": {
+      "type": "string"
+    },
+    "ar_measurement_url": {
+      "type": "string"
+    },
+    "note": {
+      "type": "string"
+    },
+    "product_visualizer_note": {
+      "type": "string"
+    },
+    "product_visualizer_url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "note"
+  ],
+  "type": "object"
+}

First observedMay 28, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations declare readOnlyHint=true, and the description adds substantial context beyond that: two free previews per customer, the requirement for a name and WhatsApp number, that both links are always returned, and that unsupported products fall back to ordering with best-guess sizes plus a free tape measure. These are real operational constraints an agent needs before calling.

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?

The purpose and scope are front-loaded in the first sentence, and the usage cue is placed last where it is most useful. It loses a point for mild redundancy, since 'not a measuring tool' and 'No measuring or marking' restate the same idea in consecutive sentences.

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, so return values need not be described. Given a two-parameter read-only tool, the description covers the product scope, the preview limits, the contact-data prerequisite, and the measuring fallback — everything an agent would need to call it 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 still adds meaning the schema does not spell out plainly: 'both links are always returned' regardless of mode, and that product pre-selection only applies 'when it is supported' with the supported list returned alongside. That extra semantic lift from mode selection earns a 4.

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 opens with a specific verb and resource ('Returns the link to the Custom Blinds Visualiser'), states the pre-selection scope ('pre-selected to the product when it is supported'), and clarifies what the artifact is and is not ('A preview of colour and style, not a measuring tool'). An agent can distinguish this from siblings like get_product_recommendation or request_swatch 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?

Usage is explicit: 'Use when a customer wants to see how a blind or colour will look before ordering, or is unsure how to measure,' and the mode enum is explained in terms of which link becomes primary. It doesn't name specific sibling tools as alternatives or state when NOT to call it, but the context is otherwise clear enough to route correctly.

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.