Custom Blinds Shop

submit_enquiry

Legacy auth-required tool, prefer the open UCP flow (create_cart → create_checkout → complete_checkout) for credentialless checkout. Use submit_enquiry only when the customer wants a sales team follow-up by email rather than paying online. Requires Bearer token. Pass a configure_product output plus customer name, email, and phone. Team responds within 24 hours.

Input Schema

Name	Required	Description
`message`	Yes	Required enquiry message; at least 10 characters after trimming
`customer_name`	Yes	Customer full name
`customer_email`	Yes	Customer email address
`customer_phone`	Yes	Customer phone number
`product_config`	Yes	Product configuration from configure_product

Output Schema

Name	Required	Description	Default
`contact`	Yes
`message`	Yes
`success`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 20, 2026
- removedOutput schema / properties / contact / properties / contact_name
```
Removed value: -{
-  "type": "string"
-}
```
- removedOutput schema / properties / contact / properties / contact_phone
```
Removed value: -{
-  "type": "string"
-}
```
- addedOutput schema / properties / contact / properties / name
```
Added value: +{
+  "type": "string"
+}
```
- removedOutput schema / properties / enquiry_id
```
Removed value: -{
-  "type": "string"
-}
```
- changedOutput schema / required
```
Previous value: -[
-  "success",
-  "enquiry_id",
-  "message",
-  "contact"
-]New value: +[
+  "success",
+  "message",
+  "contact"
+]
```

Changed4 schema fields changedOct 10, 2026

changedInput schema / properties / message / description

Previous value: -"Additional message or questions from the customer"New value: +"Required enquiry message; at least 10 characters after trimming"

addedInput schema / properties / message / minLength
```
Added value: +10
```

changedInput schema / required

Previous value: -[
-  "product_config",
-  "customer_name",
-  "customer_email",
-  "customer_phone"
-]New value: +[
+  "product_config",
+  "customer_name",
+  "customer_email",
+  "customer_phone",
+  "message"
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "contact": {
+      "additionalProperties": true,
+      "properties": {
+        "contact_name": {
+          "type": "string"
+        },
+        "contact_phone": {
+          "type": "string"
+        },
+        "email": {
+          "type": "string"
+        },
+        "note": {
+          "type": "string"
+        },
+        "whatsapp": {
+          "type": "string"
+        }
+      },
+      "required": [],
+      "type": "object"
+    },
+    "enquiry_id": {
+      "type": "string"
+    },
+    "message": {
+      "type": "string"
+    },
+    "success": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "success",
+    "enquiry_id",
+    "message",
+    "contact"
+  ],
+  "type": "object"
+}

First observedMay 28, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations only declare readOnly=false and destructive=false; the description adds real behavioral context on top: legacy status, a Bearer token requirement, the 24-hour team response expectation, and the prerequisite that product_config comes from configure_product. It stops short of describing what happens on validation failure or whether duplicate enquiries are deduplicated.

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?

Four sentences, each doing distinct work: deprecation/routing, the use case, auth, and input provenance plus turnaround. The most important routing information is front-loaded.

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?

For a five-parameter mutation with a nested object, the description covers the prerequisite tool, auth, SLA, and the alternative path; return values are covered by the existing output schema. An agent has everything needed to decide and 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 schema carries the field-level detail and the baseline would be 3. The description earns a bump by disclosing provenance — that product_config must be a configure_product output — which the schema does not state.

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 makes clear this submits a sales enquiry by email rather than a purchase, and it explicitly positions itself against the create_cart → create_checkout → complete_checkout flow. The verb+resource are implied by the name and reinforced by 'sales team follow-up by email', though the first sentence is routing advice rather than a direct statement of what the call does.

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?

It states when to use (customer wants email follow-up instead of paying online) and when not to use (default to the credentialless UCP flow, named step by step). This is the strongest dimension of the definition — 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.