Skip to main content
Glama

Sonar Connections

by com.sonarconnections
OverviewDiscussionsAdmin

Pickup menu and order times

biz_menu
Read-only

The PICKUP MENU for a business served through this connector, with prices, allergens, how far ahead each item has to be ordered, and the pickup windows available on a date. longbeachbrunch is a neighborhood bakery that takes pickup pre-orders: cookies, brownies and bars, morning pastry, brunch boxes, party platters, custom cakes and holiday boxes, and a coffee bar. Pass a date to get that day's pickup windows alongside the menu; omit it for today in the business's own timezone. Item ids from here are what biz_order accepts, exactly as written. PICKUP ONLY: there is no delivery and no shipping. PAYMENT: the ORDER is placed here; paying for it, when the business takes payment, happens on that business's own Square checkout page reached through a sonarconnections.com/p/ link, or at the counter on collection. No card data passes through Sonar Connections and this tool has nowhere to put one. A business that does not take pickup orders (velvetandclay, brightpointdental) says so honestly with its opening hours attached. This is a demonstration business and the order book is a sandbox. The business may be given by NAME or by id: "Long Beach Brunch Bakehouse" and "longbeachbrunch" both reach the bakery, and a common short form ("the bakehouse", "the dentist") works too. A name we cannot place is refused with the list of businesses we do serve, never answered about a different one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoYYYY-MM-DD, defaults to today in the business timezone. Pickup windows for this date ride along with the menu.
businessNoWhich business, BY NAME OR BY ID. Optional, defaults to velvetandclay. Available: Velvet and Clay (velvetandclay), Brightpoint Dental (brightpointdental), Long Beach Brunch Bakehouse (longbeachbrunch). A common short form works too ("the bakehouse", "the dentist"). A name that does not clearly match one of these is REFUSED with the list, never silently answered about a different business.
businessIdNoAlias for `business`, accepted because every reply carries this name. Takes a NAME OR AN ID, exactly like `business`. Ignored when `business` is also given.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses pickup-only operation, no delivery/shipping, external Square payment, no card data handling, sandbox/demonstration nature, and honest refusal of unmatched business names. These are substantial behavioral disclosures not present in annotations. No contradiction found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence front-loads the purpose well, but the description is verbose, including a long list of bakery product categories and some repetition of schema details. The extra context is useful but could be tightened without losing value.

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 read-only tool with three optional parameters and no output schema, the description covers return content, date behavior, business resolution, payment exclusion, and non-pickup business handling. It provides all necessary information for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the schema already describes date and business thoroughly, including name/id aliases and short forms. The description reinforces this but adds little new parameter-level meaning, so baseline 3 applies.

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 clearly states the tool provides the pickup menu for a business with prices, allergens, lead times, and pickup windows for a date. It is specific about the resource and content, though it does not explicitly contrast with sibling tools like biz_info or biz_availability.

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?

Rich usage context is provided: date defaulting, business name/id forms, use of item ids with biz_order, external payment flow, and refusal behavior. However, it never explicitly says when to choose this tool over alternatives, e.g., when to use biz_info for business hours.

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

All Sonar Connections toolsInspect
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