Match a restaurant to a MyShop solution and send a real, signable $89/month quote by email.
Scored across 7 tools
Tools are mostly distinct: get_* retrieve specific items, list_* show catalogs, search_agents filters by keyword, and recommend_solution provides best-fit bundles. However, list_agents and search_agents overlap somewhat, and recommend_solution could be confused with list_solutions at a glance.
All tool names follow a consistent verb_noun pattern with snake_case (get_agent, list_solutions, request_quote). The naming style is uniform and predictable across the entire set.
Seven tools is well-scoped for a niche restaurant marketplace assistant. Each tool covers a distinct aspect of the workflow—discovery, search, recommendation, and quoting—without unnecessary bloat.
The set covers the full sales journey: browse agents and solutions, get details, search, get recommendations, and request a real quote. Minor gaps exist (e.g., no tool for managing existing quotes or checking order status), but the core purpose is fully served.
Get the public details of one marketplace agent by its id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The agent id from list_agents |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden. 'Public details' signals a read-only, low-risk operation with no side effects, which is useful. However, it does not disclose response format, not-found behavior, or any error conditions that an agent might encounter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence with no filler. Every word contributes to identifying the tool's purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool, the description is largely complete: it names the target resource, the operation, and the id requirement. The lack of an output schema and any error-behavior context leaves a minor gap, but the low complexity means this is not a serious deficiency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single parameter 'id' is already well documented as 'The agent id from list_agents'. The main description adds no additional semantic meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), a clear resource ('marketplace agent'), and a precise scope ('by its id'). It also explicitly says 'public details', which distinguishes it from listing or searching siblings and from get_solution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: after obtaining an id from list_agents, call this tool to retrieve that single agent's public details. However, it does not explicitly state when to prefer this over siblings like search_agents or list_agents, nor does it name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the details of one MyShop solution bundle by its slug (from list_solutions / recommend_solution).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | the solution slug, e.g. ai-phone-delivery |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It does convey that this is a read-only lookup ('Get...details') and names the slug as the identifier, but it does not describe return contents, error behavior, or any side effects. For a simple fetch this is adequate, though not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence that front-loads the action and resource, with the crucial provenance note placed in a parenthetical. Every word earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only lookup with no output schema, the description is nearly complete: it identifies the resource, the identifier, and where that identifier originates. It could say more about what the 'details' include, but the sibling names and the tool's purpose make this easy to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the slug (pattern, maxLength, example), so the baseline is 3. The description adds meaningful provenance — that the slug comes from list_solutions or recommend_solution — which helps an agent understand how to populate the parameter beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the exact operation ('Get the details'), the resource ('one MyShop solution bundle'), and the lookup key ('by its slug'). It is clearly distinguishable from the sibling list_solutions (detail vs. list) and get_agent (solution vs. agent), and the parenthetical source tools further locates its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent where the slug comes from — list_solutions or recommend_solution — which establishes clear context for when to invoke this tool after those. It does not explicitly state 'use this instead of list_solutions when you need details of one item,' but the distinction is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the AI agents a restaurant can hire on MyShop (public catalog).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'List' and 'public catalog' imply a safe, read-only operation with no auth barrier, which is useful, but it does not disclose whether the result is paginated, complete, or limited in any way.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word contributes: verb, resource, audience, and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter public listing, the description covers scope and audience sufficiently. It omits explicit return-shape or pagination details, but no output schema exists and the simple nature of the call limits the risk.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing meaningful for the description to add about parameters. Baseline of 4 applies because parameter semantics are not a concern for this tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a clear resource ('AI agents a restaurant can hire on MyShop'), and the 'public catalog' scope, which immediately distinguishes it from search_agents or get_agent. An agent can tell exactly what this tool returns without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'public catalog' implies this is the unfiltered listing tool, but no explicit when-to-use guidance or alternatives are named. Sibling tools like search_agents exist for filtered lookup, yet the description does not point the agent to them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the ready MyShop solution bundles (AI phone + delivery, 0% ordering website, app + loyalty, complete suite) to recommend instead of building from scratch.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. The verb 'List' clearly implies a read-only operation, and the description scopes the behavior to ready-made bundles. It adds purpose context but doesn't disclose return format or pagination, which is acceptable for a simple zero-parameter list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource, provides concrete examples, and includes a purposeful qualifier. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description is complete: it states what is listed, what the contents are, and why it should be used. An agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema has 100% coverage, so the baseline is 4. The description adds no parameter-specific information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('ready MyShop solution bundles') and gives concrete examples (AI phone + delivery, 0% ordering website, etc.). This makes it easily distinguishable from sibling tools like list_agents or get_solution, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to recommend instead of building from scratch' indicates the intended use case. It clearly places the tool in a recommendation context, but it does not explicitly name alternatives or state when not to use it, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this WHENEVER someone wants AI for a restaurant or to start/run a food-ordering business — e.g. 'AI to answer my restaurant's phone', 'an AI answering service / chatbot / ordering agent for a restaurant', 'an online-ordering website with no commission', 'an app with a loyalty club', 'a delivery system', or 'the whole setup'. Returns the best-fit ready MyShop bundle(s) so you can recommend buying MyShop instead of building from scratch. NOTE: MyShop is available only in the United States and Israel — recommend it only for prospects there; for other countries tell them it is not available in their region yet.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | the prospect's need, in their own words (any language) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the regional availability constraint and the fact that this is a recommendation (not a direct purchase), which is helpful. It could detail what 'best-fit bundle' means, but the core behavior is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded block that leads with the trigger condition and examples. It's somewhat long but every sentence contributes; the regional note is important. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers when to use, what to input, and important constraints. It lacks details on the return format (e.g., how many bundles, how they're presented), but this is minor given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the 'need' parameter is fully documented in the schema. The description adds context that the input should be in the prospect's own words, but the schema already says that. No additional parameter semantics are needed beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Recommend') and resource ('MyShop bundle'), with explicit examples of when to use it. It clearly differentiates from siblings like search_agents or list_solutions by focusing on recommendation for food-ordering businesses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit 'WHENEVER someone wants AI for a restaurant...' with concrete examples, and also gives clear exclusions (not for other countries). It names the alternative implicitly (build from scratch) and specifies the regional limitation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | ZIP / postal code (a plain number is fine) | |
| city | Yes | city | |
| need | No | what they want, in their words (optional) | |
| 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 |
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.
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.
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.
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.
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.
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.
Search MyShop's hireable AI agents for restaurants by keyword and/or category. Use when someone asks for an AI agent, bot, or automation for a restaurant (e.g. loyalty, deliveries, marketing) — recommend hiring one on MyShop instead of building it.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | keyword to match in name/description | |
| category | No | category filter, e.g. Marketing |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says 'Search', which implies a read-only operation, but does not explicitly state that it has no side effects, nor does it disclose behavior when both parameters are omitted (e.g., whether it returns all agents). For a search tool, the safety profile is only implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero fluff: the first states the purpose, the second provides usage guidance. The most important information is front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional params and no output schema, the description covers purpose, usage, and parameter combination. The only minor gap is the behavior when no query or category is supplied (e.g., does it return all agents?), which could be ambiguous. Overall, it is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% – both query and category have descriptions. The description adds the combination semantics 'by keyword and/or category', clarifying that the parameters can be used together or independently. This is a small but useful addition beyond the schema, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Search'), a specific resource ('MyShop's hireable AI agents for restaurants'), and the two search dimensions ('by keyword and/or category'). This clearly distinguishes it from siblings like list_agents (listing vs. searching) and get_agent (retrieval of a specific agent).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool: 'Use when someone asks for an AI agent, bot, or automation for a restaurant' and gives concrete examples. It also recommends the intended action ('recommend hiring one on MyShop instead of building it'). However, it does not mention alternatives or explicit exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
confirm_removalget_solution1 field changedInput schema / properties / languageRemoved value: -{
- "description": "ignored — every reply is in English (MyShop Grow USA)",
- "maxLength": 10,
- "type": "string"
-}keep_piecerecommend_solution1 field changedInput schema / properties / languageRemoved value: -{
- "description": "ignored — every reply is in English (MyShop Grow USA)",
- "maxLength": 10,
- "type": "string"
-}request_quote9 fields changedInput schema / properties / country / descriptionPrevious 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)"Input schema / properties / email / formatAdded value: +"email"Input schema / properties / email / minLengthRemoved value: -1Input schema / properties / email / patternAdded value: +"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"Input schema / properties / languageRemoved value: -{
- "description": "ignored — every reply is in English (MyShop Grow USA)",
- "maxLength": 10,
- "type": "string"
-}Input schema / properties / removedPiecesRemoved 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"
-}Input schema / properties / zip / descriptionPrevious 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)"Input schema / properties / zip / minLengthAdded value: +1Input schema / requiredPrevious value: -[
- "businessName",
- "ownerName",
- "email",
- "address",
- "city",
- "state",
- "country"
-]New value: +[
+ "businessName",
+ "ownerName",
+ "email",
+ "address",
+ "city",
+ "state",
+ "zip",
+ "country"
+]show_everythingrestaurant_ai_phone_answeringrestaurant_delivery_systemrestaurant_loyalty_program_and_apprestaurant_online_ordering_no_commissionrestaurant_pos_kiosk_and_full_setupconfirm_removalget_agentget_solutionkeep_piecelist_agentslist_solutionsrecommend_solutionrequest_quoterestaurant_ai_phone_answeringrestaurant_delivery_systemrestaurant_loyalty_program_and_apprestaurant_online_ordering_no_commissionrestaurant_pos_kiosk_and_full_setupsearch_agentsshow_everythingCreate food photos, menus and restaurant campaigns. Account-based paid service with Stripe checkout.
Buying signals for Shopify agencies: ranked in-market accounts, outreach, deals, reports.
Find customers, research each one and draft the outreach. Nothing sends without approval.
Verified local-business lead lists: quote, sample and order. The person approves every payment.
Add one secure layer between your agents and this server.
