Skip to main content
Glama

Sonar Connections

by com.sonarconnections
OverviewDiscussionsAdmin

Set menu item availability

biz_set_item_availability
Idempotent

Marks one item on a business menu as sold out for today, or puts it back on. Needs a personal connector token, business, soldOut, and itemId or itemName. Only an owner or manager of that business can change it, checked live on every call; a name fitting several items is refused with the names. It works in two steps: a call without confirm returns a preview and a confirmToken and changes nothing; a call with confirm true and that token makes the change.

Input Schema

NameRequiredDescriptionDefault
itemIdNoThe item id from biz_menu.
confirmNoAbsent on the first call, which changes nothing; true with confirmToken makes the change.
soldOutYestrue marks it sold out today; false puts it back.
businessYesThe business by name or id, as biz_menu returned it.
itemNameNoOr the item name.
requestIdNoOptional caller id, 8 or more characters; a repeat returns the first result.
confirmTokenNoThe token the first call returned.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • changedInput schema / properties / business / description
      Previous value: -"Which business, by name or by id, as biz_menu returned it. Only a business the person is seated on can be changed."New value: +"The business by name or id, as biz_menu returned it."
    • changedInput schema / properties / confirm / description
      Previous value: -"Absent on the first call, which changes nothing. true, together with confirmToken, makes the change."New value: +"Absent on the first call, which changes nothing; true with confirmToken makes the change."
    • changedInput schema / properties / confirmToken / description
      Previous value: -"The token the first call returned. Needed when confirm is true."New value: +"The token the first call returned."
    • changedInput schema / properties / itemId / description
      Previous value: -"The menu item id, as biz_menu returned it. An id matches exactly one item."New value: +"The item id from biz_menu."
    • changedInput schema / properties / itemName / description
      Previous value: -"The item by name, when no id is at hand. Matched against that menu; a name that fits more than one item is refused with the names it fits."New value: +"Or the item name."
    • changedInput schema / properties / requestId / description
      Previous value: -"An id for this change chosen by the caller, at least 8 characters. A repeat with the same id and the same arguments returns the first result without changing anything a second time."New value: +"Optional caller id, 8 or more characters; a repeat returns the first result."
    • changedInput schema / properties / soldOut / description
      Previous value: -"true to mark the item sold out for today, false to put it back on the menu."New value: +"true marks it sold out today; false puts it back."
  2. Changed6 schema fields changed
    • changedInput schema / properties / business / description
      Previous value: -"Which business, BY NAME OR BY ID, exactly as biz_menu returned it. Only a business you are seated on can be changed."New value: +"Which business, by name or by id, as biz_menu returned it. Only a business the person is seated on can be changed."
    • changedInput schema / properties / confirm / description
      Previous value: -"Leave this out on the first call. Pass true with confirmToken to commit."New value: +"Absent on the first call, which changes nothing. true, together with confirmToken, makes the change."
    • changedInput schema / properties / confirmToken / description
      Previous value: -"The token the preview returned. Required when confirm is true."New value: +"The token the first call returned. Needed when confirm is true."
    • changedInput schema / properties / itemId / description
      Previous value: -"The menu item id, exactly as biz_menu returned it. Prefer it whenever you have one: an id can never be ambiguous."New value: +"The menu item id, as biz_menu returned it. An id matches exactly one item."
    • changedInput schema / properties / itemName / description
      Previous value: -"The item by name, when you have no id. Matched against that menu. A name that fits more than one item is refused with the names it fits, never guessed at."New value: +"The item by name, when no id is at hand. Matched against that menu; a name that fits more than one item is refused with the names it fits."
    • changedInput schema / properties / requestId / description
      Previous value: -"Your own id for this change, at least 8 characters. Sending the same one twice with the same arguments returns the first result instead of changing anything a second time."New value: +"An id for this change chosen by the caller, at least 8 characters. A repeat with the same id and the same arguments returns the first result without changing anything a second time."
  3. Added

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations, it discloses the highest-risk behavior: a call without confirm changes nothing and returns a confirmToken, and only a confirm plus that token mutates state. It also adds live permission checking, ambiguous-name rejection semantics and the idempotent repeat behavior, so an agent knows exactly what each call does to the system.

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?

Three sentences, front-loaded with the effect and with no filler. The middle sentence packs permissions and ambiguity handling into semicolon-linked clauses, which is dense but every clause carries operational information.

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 7-parameter mutation tool with no output schema, the description covers prerequisites, permissions, ambiguous input handling, idempotency and the two-step confirmation, and it explains what the first (preview) call returns. Nothing an agent needs to invoke it safely is missing.

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 would be 3, but the description adds semantics the schema cannot express: itemId and itemName are alternatives (neither is required in the schema, yet one is needed), and confirm/confirmToken form a coupled pair across two calls. Only requestId's repeat behavior is not echoed in the prose.

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 opening sentence gives a specific verb, resource and scope: mark one item on a business menu sold out for today, or reverse it. That single-item, today-only scope implicitly separates it from the sibling biz_availability, but no sibling is named explicitly as the alternative for store-level 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?

It states the two use cases (mark sold out, put back), the prerequisite authorization (owner or manager, checked live), and the mandatory two-step preview-then-confirm workflow, including that an ambiguous name is refused rather than guessed. It does not say when to reach for biz_availability or biz_menu instead, so routing to siblings is left to inference.

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