Skip to main content
Glama

SuVerse

One business in full: what it sells, what can be done, how it reaches you

get_card
Read-only

transparency: the SuVerse Transparency rating — how much the business publishes about itself (not the quality of its work), A–D, each item with its source page and read date. Free. One business in full, in the same shape for every trade: who it is (name, trade, address, telephone, e-mail, opening hours, time zone), everything it sells (60 offerings a page, cheapest first; offerings_page says how many there are and the next offset), the six actions with their links and required_fields, how the thing reaches the buyer (delivery, pickup, on_site, at_customer — with the published area, the fee and the order deadline), and how fresh each part of that is. live_data (platform, synced_at) when the shelf is the business’s own connected system: then every offering carries source: connector with its variants (each with inventory: units in stock as the platform counts them, null = unknown), and an action with method connected is taken through place_order / book_slot on this door.

Use it when the user asks «can they deliver to me», «are they open now», «what else do they do», or when search_catalog offered a business with nothing listed and the next step is a telephone call. 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": {
      "id": "<id>"
    },
    "name": "get_card"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesthe business id from search_catalog
offerings_limitNoofferings on this page (default 60, at most 200)
offerings_offsetNo11-05: where this page of offerings starts (default 0); offerings_page.next_offset gives the next one

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior5/5

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

The annotations already mark this as read-only, non-destructive, and not open-world, but the description adds substantial behavioral context: free access, pagination shape, cheapest-first offerings, freshness metadata, live_data, connector inventory with null meaning unknown, and the connected action flow. It also warns that results are candidates and that nothing is sent, booked, ordered, or paid without permission. This does not contradict the annotations.

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 description is informative but dense and not front-loaded: it opens with a transparency-rating field definition before stating the tool’s core purpose. Some return-shape detail is justified because there is no output schema, but the long semicolon-separated run could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of explaining the returned business profile, offerings, actions, delivery modes, freshness, live_data, inventory, and permission boundaries. It is broadly complete for correct invocation, though a few return fields are described only at a high level.

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%, so id, offerings_limit, and offerings_offset are already well documented in the schema. The description reinforces the 60-per-page behavior and next-offset concept, plus cheapest-first ordering, but most of that is output or pagination context rather than additional input-parameter meaning.

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 states that this returns one business in full, including identity, offerings, actions, delivery, and freshness, which is a specific resource and scope. It names search_catalog as a related retrieval path but does not explicitly distinguish itself from the similarly named sibling get_business.

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 provides concrete triggers such as when the user asks whether a business delivers, is open now, or does something else, and when search_catalog surfaced a business with nothing listed. It also points to place_order/book_slot for connected actions, though it gives no explicit when-not guidance or full comparison against alternatives.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.