Skip to main content
Glama
Sign In

Convika

by com.convika
OverviewDiscussionsAdmin

Start taking orders

enable_orders

Use this tool when the user wants a Convika page (ホームページ, ランディングページ, Webサイト) to take orders: a buy button, an order form, or a request such as 「購入ボタンを付けて」「注文フォームにして」「このページで注文を受け付けたい」.

It reads the item names and prices the page's saved HTML shows, and each item's image from the page when one sits beside it (imageUrl, else null), and saves them as a DRAFT price list for the page. It never confirms a price and never turns orders on. The seller finishes on the dashboard, at setupUrl: checks each item, price and image, chooses how buyers pay and how each item is handed over, enters the seller's details, and agrees to the order terms. Show the user setupUrl and the steps in sellerMustFinish, and don't tell the user the page takes orders yet.

Each item has its own ways of receiving: pickup, delivery, online (a session the seller holds online), visit (the seller goes to the buyer), or digital (a file or link sent by email). A buyer can only order items together that share a way, and the order page states that way's delivery timing and cancellation terms. Pass itemModes with your reading of the page, by each item's name as the page shows it (a consultation on Zoom → online, a PDF or a download → digital); leave an item out when the page doesn't say. They are saved on the draft only, as suggestions the seller checks in setup; nothing is sold until the seller confirms. Each returned item's fulfilmentModes is what is saved for it (null = none yet).

status: "draft_saved" (a new draft from the page), "no_prices_found" (the page shows no price Convika could read; the seller adds items in setup), "confirmed_list_kept" (the seller already confirmed a list; nothing changed, itemModes included), "already_taking_orders" (nothing changed). Calling it again replaces only an unconfirmed draft.

Buy buttons: give the page's buttons or links the attribute data-convika-order (an empty value opens the whole order form) with save_page_content. They lead to the order form once the seller starts orders; until then they stay as written. Sellers can also take card payments by connecting a Stripe account in the order setup on the dashboard (two-step verification required).

Input Schema

NameRequiredDescriptionDefault
siteIdYesThe ID of the page to take orders on
itemModesNoYour reading of how each item is handed over, saved on the draft for the seller to check in setup. Leave an item out when the page doesn't say.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / itemModes
      Added value: +{
+  "description": "Your reading of how each item is handed over, saved on the draft for the seller to check in setup. Leave an item out when the page doesn't say.",
+  "items": {
+    "properties": {
+      "modes": {
+        "description": "How the item is handed over: pickup, delivery, online, visit, or digital (one or more)",
+        "items": {
+          "enum": [
+            "pickup",
+            "delivery",
+            "online",
+            "visit",
+            "digital"
+          ],
+          "type": "string"
+        },
+        "maxItems": 5,
+        "minItems": 1,
+        "type": "array"
+      },
+      "name": {
+        "description": "The item's name as the page shows it",
+        "maxLength": 100,
+        "minLength": 1,
+        "type": "string"
+      }
+    },
+    "required": [
+      "name",
+      "modes"
+    ],
+    "type": "object"
+  },
+  "maxItems": 100,
+  "type": "array"
+}
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only say non-read-only, non-destructive, non-idempotent. The description adds substantial context the annotations cannot: it saves a DRAFT only, never confirms a price or turns orders on, enumerates all four status values and their meanings, and clarifies that a repeat call replaces only an unconfirmed draft (directly relevant given idempotentHint=false).

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?

Front-loaded with the trigger sentence and organized by topic (draft behavior, statuses, itemModes, buttons, Stripe). It is long and repeats the 'nothing is sold yet' idea more than once, and the Stripe/two-step verification aside is peripheral, but nearly every sentence carries operative 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?

There is no output schema, and the description compensates by documenting status outcomes, setupUrl and sellerMustFinish handoff, and the fulfilmentModes return value. An agent has enough to call the tool and correctly report the result without over-claiming that orders are live.

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 is 3, but the description meaningfully extends itemModes: it explains how to infer modes from page content (Zoom consultation → online, PDF/download → digital), that items should be omitted when the page is silent, and that values are proposals stored on the draft with returned fulfilmentModes reflecting what was actually saved.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise trigger and outcome: making a Convika page take orders, with concrete instantiations (buy button, order form) and multilingual user phrasings. An agent can immediately tell this apart from read-side siblings like get_orders or content-editing siblings like save_page_content.

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 gives strong when-to-use signals (explicit request patterns in English and Japanese) and post-call instructions (show setupUrl and sellerMustFinish, don't claim the page takes orders yet). It does not explicitly name alternatives (e.g., get_orders for viewing, save_page_content for wiring buttons) as exclusion paths, so it stops short of a full routing statement.

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

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