Ignix

Create a bookable service

create_booking_service

Add a service customers can book on the public booking page. Needs name and durationMin. Optional: buffers in minutes, the price as shown (free text, e.g. "35 €" or "from 40"), who does it (resourceIds of people/rooms from get_booking_settings; omit for anyone), where it happens (videoMode: "none" in person, "meet" a Google Meet link per booking, "link" the business's own https video room), category and photo, and charge to take the full amount online when booking (only with Stripe connected; otherwise refused). For activities (tours, classes) use partyMode "seats": a booking of N people takes N spots and is charged per person; for restaurants use "tables": each person/room is a table type and a booking takes one table that fits; partyMin/partyMax bound the party and slotStepMin sets its own slot step (e.g. 90-minute sittings). It is public at once: confirm the price and charge with the user.

Input Schema

Name	Required	Description
`name`	Yes	Up to 80 characters.
`price`	No	Price as shown to customers, free text up to 40 characters. Empty removes it.
`active`	No	false hides it from booking without deleting it.
`charge`	No	Amount charged online when booking, e.g. "25" or "19.99", in the bookings currency. Needs Stripe connected. "" stops charging. Omit to leave it as is.
`category`	No	Groups services on the public page. Up to 40 characters.
`imageUrl`	No	Public http(s) URL of a photo for the public page.
`partyMax`	No	Most people per booking with seats/tables (partyMin-500). Above 1, customers are asked how many.
`partyMin`	No	Fewest people per booking with seats/tables (1-500). Default 1.
`partyMode`	No	"none" normal appointments (one booking = one spot); "seats" activities, tours, classes, tastings (a booking of N people takes N spots; the charge is per person); "tables" restaurants (each resource is a table type, its spots = how many tables of that type; a booking takes one table that fits the party).
`videoLink`	No	https link of the business's own video room, with videoMode "link".
`videoMode`	No	"none" in person, "meet" a Google Meet link per booking, "link" the business's own video room (videoLink).
`description`	No	Up to 500 characters.
`durationMin`	Yes	Minutes, 5-720.
`resourceIds`	No	People/rooms that do it (ids from get_booking_settings). [] = anyone.
`slotStepMin`	No	Own slot step for this service in minutes (10, 15, 20, 30, 45, 60, 75, 90, 105, 120, 150, 180, 240), e.g. 90 for restaurant sittings. null = the workspace rule.
`workspaceId`	No	Defaults to the workspace this connection is scoped to.
`bufferAfterMin`	No	Free minutes kept after (cleaning, travel), 0-240.
`idempotencyKey`	No	Optional. A unique id for this action (16-128 chars: letters, digits, _ : . -). If you are unsure whether a call went through (timeout, network error), repeat it with the SAME idempotencyKey and the same arguments: you get the original result and nothing is done twice.
`bufferBeforeMin`	No	Free minutes kept before, 0-240.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 21, 2026

addedInput schema / properties / partyMax

Added value: +{
+  "description": "Most people per booking with seats/tables (partyMin-500). Above 1, customers are asked how many.",
+  "type": "number"
+}

addedInput schema / properties / partyMin

Added value: +{
+  "description": "Fewest people per booking with seats/tables (1-500). Default 1.",
+  "type": "number"
+}

addedInput schema / properties / partyMode

Added value: +{
+  "description": "\"none\" normal appointments (one booking = one spot); \"seats\" activities, tours, classes, tastings (a booking of N people takes N spots; the charge is per person); \"tables\" restaurants (each resource is a table type, its spots = how many tables of that type; a booking takes one table that fits the party).",
+  "enum": [
+    "none",
+    "seats",
+    "tables"
+  ],
+  "type": "string"
+}

addedInput schema / properties / slotStepMin

Added value: +{
+  "description": "Own slot step for this service in minutes (10, 15, 20, 30, 45, 60, 75, 90, 105, 120, 150, 180, 240), e.g. 90 for restaurant sittings. null = the workspace rule.",
+  "type": [
+    "number",
+    "null"
+  ]
+}

AddedOct 18, 2026

TDQS

A4/5.0

Behavior4/5

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

Goes beyond the annotations by warning that the service is public immediately and that the price/charge should be confirmed with the user first, and by disclosing that `charge` is refused unless Stripe is connected. Annotations already cover readOnly/openWorld/idempotency, so this added side-effect disclosure is the valuable layer.

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-loads the required fields (name, durationMin) and then walks through the optional concepts; nearly every clause carries parameter-specific information rather than filler. It is a single dense paragraph, so it reads as a wall of text where light structuring would aid scanning.

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?

For a 19-parameter creation tool with no output schema, it covers the consequential fields — charge, partyMode, videoMode, resourceIds, buffers — and flags the user-confirmation requirement. Minor fields (active, imageUrl, workspaceId, idempotencyKey) are left to the schema, which is adequate since those carry their own descriptions.

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 baseline is 3, but the description adds genuine meaning: it groups 19 parameters into a coherent narrative (buffers, price as free text, who performs it, where, category/photo, online charge) and supplies examples such as 90-minute sittings for slotStepMin. Some of the partyMode/videoMode text duplicates the enum descriptions.

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?

States a specific verb and resource — adding a bookable service that appears on the public booking page — which immediately scopes it to the booking domain. It never explicitly distinguishes itself from the closely-named sibling create_booking_resource, so sibling differentiation is only implicit (services vs. resources).

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?

Gives real routing guidance for optional choices: use partyMode "seats" for tours/classes, "tables" for restaurants, resourceIds from get_booking_settings, and omit resourceIds for anyone. It does not say when to use this versus update_booking_service or create_booking_resource, so it stops short of full when/when-not guidance.

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

All Ignix tools Inspect

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

Need Help?