MyShop - solutions for restaurants

Request a MyShop quote

request_quote

Create a REAL MyShop price quote for a prospect and return a link they can open to review, sign and pay. BEFORE calling this, ASK the prospect for and collect ALL of: their business name, the BUSINESS OWNER'S NAME (never leave it empty), email, phone, and their FULL ADDRESS — street, city, state, ZIP and country. The full address is required because it tells us the country and state the offer is for. MyShop is a flat $89/month for everything and is available only in the United States and Israel.

Input Schema

TableJSON Schema

Name	Required	Description
`zip`	Yes	ZIP / postal code (a plain number is fine)
`city`	Yes	city
`need`	No	what they want, in their words (optional)
`email`	Yes	the prospect's email — the quote link is tied to it
`phone`	No	phone number (recommended)
`state`	Yes	state / region — tells us which state the offer is for
`address`	Yes	street address
`country`	Yes	country: US or IL (MyShop is available only in these)
`ownerName`	Yes	the business OWNER'S full name — ask for it, never leave empty
`businessName`	Yes	the prospect's business/restaurant name

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedSep 17, 2026

changedInput schema / properties / country / description

Previous value: -"the prospect country for the address record. EVERY quote is issued by the American company: English document, English email, US dollars. Never quote or imply a price in shekels and never promise a Hebrew document."New value: +"country: US or IL (MyShop is available only in these)"

addedInput schema / properties / email / format
```
Added value: +"email"
```
removedInput schema / properties / email / minLength
```
Removed value: -1
```

addedInput schema / properties / email / pattern

Added value: +"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"

removedInput schema / properties / language

Removed value: -{
-  "description": "ignored — every reply is in English (MyShop Grow USA)",
-  "maxLength": 10,
-  "type": "string"
-}

removedInput schema / properties / removedPieces

Removed value: -{
-  "description": "every piece switched off in THIS conversation via confirm_removal, e.g. ['pos'] — it is written into the quote line and the receipt. Omit if nothing was switched off.",
-  "items": {
-    "maxLength": 60,
-    "type": "string"
-  },
-  "maxItems": 9,
-  "type": "array"
-}

changedInput schema / properties / zip / description

Previous value: -"ZIP / postal code. OPTIONAL — omit it if the prospect did not say one. Never guess: leave it out and the server returns the real ZIPs for their city as numbered choices to confirm."New value: +"ZIP / postal code (a plain number is fine)"

addedInput schema / properties / zip / minLength
```
Added value: +1
```

changedInput schema / required

Previous value: -[
-  "businessName",
-  "ownerName",
-  "email",
-  "address",
-  "city",
-  "state",
-  "country"
-]New value: +[
+  "businessName",
+  "ownerName",
+  "email",
+  "address",
+  "city",
+  "state",
+  "zip",
+  "country"
+]

First observedSep 17, 2026

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations, the description carries the full behavioral burden. It clearly discloses that the tool creates a real quote (not a draft or simulation), returns a signed/payment link, and mentions the flat pricing. It does not detail side effects like whether a quote can be canceled, but for this purpose the coverage is strong.

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 description is somewhat long but every sentence adds value: purpose, prerequisites, the specific data points, the reason for the address requirement, and the pricing/availability note. It is front-loaded with the core action before details.

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?

The description explains the return value (a reviewable/signable/payable link), enumerates all required inputs, clarifies why certain fields matter, and notes the geographic constraint. With 10 parameters fully documented in the schema and no output schema, nothing essential is missing for an agent to call this 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 adds meaningful context beyond the schema: ownerName must never be empty, the full address is required for country/state determination, email is tied to the quote link, and the country enum is explained in business terms. This elevates it above baseline.

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 specific verb ('Create a REAL MyShop price quote'), the target resource (a quote), and the outcome (a link to review, sign, and pay). It is unmistakably distinct from the sibling tools, which all deal with agents and solutions.

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?

Explicitly instructs the agent to collect all required prospect information BEFORE calling, and specifies that the full address is mandatory because it determines the country and state. It also states the availability limitation to the US and Israel, giving clear conditions for when the tool may be invoked.

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

All MyShop - solutions for restaurants 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?