Ignix

Add a person or room for bookings

create_booking_resource

Add a person or room that can be booked, with its weekly hours (in the business time zone), days off and spots (customers at the same time: 1 for a person, 6 for a class). When Google Calendar is connected it gets its own Google calendar. Which services it does is set on the service (resourceIds). For a restaurant, add one per table type: spots = how many tables of that type, partyMin/partyMax = the party sizes it seats.

Input Schema

Name	Required	Description
`name`	Yes	Up to 80 characters, e.g. "Ana" or "Room 2".
`hours`	Yes	Weekly hours: {"mon": [["09:00","14:00"],["16:00","20:00"]], "tue": [...], ...}. Days mon…sun; a missing day is closed.
`spots`	No	Customers at the same time, 1-500. Default 1. For a restaurant table type: how many tables of that type.
`active`	No	false stops it from being booked without deleting it.
`timeOff`	No	Whole days off, both inclusive. Replaces the current list.
`partyMax`	No	Restaurant table type only: most people it seats. null = no limit.
`partyMin`	No	Restaurant table type only: fewest people it seats. Default 1.
`workspaceId`	No	Defaults to the workspace this connection is scoped to.
`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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 21, 2026

addedInput schema / properties / partyMax

Added value: +{
+  "description": "Restaurant table type only: most people it seats. null = no limit.",
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedInput schema / properties / partyMin

Added value: +{
+  "description": "Restaurant table type only: fewest people it seats. Default 1.",
+  "type": "number"
+}

changedInput schema / properties / spots / description

Previous value: -"Customers at the same time, 1-500. Default 1."New value: +"Customers at the same time, 1-500. Default 1. For a restaurant table type: how many tables of that type."

AddedOct 18, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnly=false, openWorld=true, idempotent=false and destructive=false, so the mutation profile is known. The description adds a genuinely useful side effect — a Google Calendar is created when Calendar is connected — plus the business-time-zone interpretation of hours. It does not discuss duplicate-creation risk on retry or what is returned, leaving the idempotency story entirely to the schema.

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 core action and packs semantics into five dense sentences with little filler. The trailing restaurant sentence is slightly tangential but earns its place as a domain-specific modeling rule rather than restating the schema.

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 9-parameter nested mutation with no output schema, the description covers purpose, side effects, time-zone semantics and the restaurant variant well. It never states what a successful call returns (e.g. the new resource id needed for update/delete), which is the main remaining gap since no output schema exists.

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 the baseline is 3. The description does add meaning beyond the schema for 'spots' with concrete examples (1 for a person, 6 for a class) and ties spots/partyMin/partyMax to the restaurant table-type model, which is real added value, but the remaining parameters are left to the schema.

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?

Opens with a specific verb and resource: 'Add a person or room that can be booked', and immediately scopes what the object carries (weekly hours, days off, spots). It implicitly separates itself from create_booking_service by noting services are assigned on the service (resourceIds), though it never names a sibling tool directly.

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 concrete context for when this shape applies, including the restaurant modeling rule ('add one per table type') and the routing hint that service linkage belongs on the service object, not here. It stops short of explicit exclusions such as 'to change an existing resource use update_booking_resource'.

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?