Skip to main content
Glama
Sign In

SuVerse

by io.github.sudzikcoin
OverviewDiscussionsAdmin

Ask the business’s own system: is it in stock now · which slots are free

check_availability
Read-only

Only for a business whose card shows live_data (its items come from its connected Shopify or Square, not from a page read). For a product: the platform’s stock right now — state: confirmed | refuted | unknown (unknown = the platform does not track stock, which is not «no»). For a service on a platform with bookings: the free slots between from and to (default: the next 7 days), each with a start_at that book_slot takes as it is — on the business’s own clock with its offset (timezone names the zone; start_at_utc is the same instant). If the card’s cannot lists book, the slots are information only and the answer says so. A business without a connection answers not_connected. Follow the server instructions «HOW TO USE THE SUVERSE CATALOG»: results are candidates, not proof; keep reading, quoting, requesting and ordering separate; nothing is sent to an owner, booked, ordered or paid without the user’s permission.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "business_id": "<business_id>",
      "offering_id": "<offering_id>"
    },
    "name": "check_availability"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoslots: the window’s end, ISO with an offset
fromNoslots: the window’s start, ISO with an offset
quantityNohow many — stock is judged against it
variant_idNothe variant (the card lists them when there are several)
business_idYesthe business id from the card
offering_idYesthe offering id from the card

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already mark this as a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=true), yet the description adds real behavioral detail: `unknown` explicitly does not mean "no", slots are returned on the business's own clock with offset, `start_at` is directly consumable by book_slot, and disconnected businesses return `not_connected`. That is meaningful context beyond the annotation set, with no contradictions.

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 eligibility precondition is front-loaded, then the product path, then the service path, then failure modes — a sensible order. It is dense and sentence length is high, but nearly every clause carries decision-relevant information; only the closing pointer to server instructions is somewhat boilerplate.

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 query tool with no output schema, the description covers both return shapes (stock `state` and slot list with `start_at`/`start_at_utc`/`timezone`) and the error shape (`not_connected`). It also flags the downstream constraint that slots may be informational only, which is exactly the nuance an agent needs before calling book_slot.

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 description coverage is 100%, so the baseline is 3, but the description goes further by stating that `from`/`to` default to the next 7 days when omitted and that `quantity` is the basis for the stock judgment. It also clarifies that `from`/`to` apply only to the slots path, which the schema itself does not spell out.

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 names a concrete verb and resource: query the business's own connected platform (Shopify/Square) for current stock state or free booking slots. It draws a clear line against page-read data from the card, so an agent can tell it apart from get_offering/get_product without opening the schema. It stops short of naming a sibling tool explicitly, so it lands at 4 rather than 5.

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 gives a hard precondition (only when the card shows `live_data`) and explains what that means. It also covers the negative case (card's `cannot` lists `book` → slots are informational only) and the not_connected response, plus the instruction to keep reading, quoting, requesting and ordering separate until the user permits.

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

All SuVerse 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