FavCRM

create_booking

Create a new booking for a member. Use get_available_slots first to find valid times, then create the booking with the service, member, date, and time.

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": {
      "serviceId": "<serviceId>",
      "accountId": "<accountId>",
      "bookingDate": "<bookingDate>",
      "startTime": "<startTime>",
      "endTime": "<endTime>"
    },
    "name": "create_booking"
  }
}

Input Schema

Name	Required	Description
`notes`	No	Booking notes
`endTime`	Yes	End time in HH:MM format
`staffId`	No	Staff member ID
`outletId`	No	Outlet/location ID. Required when the company has multiple outlets and the member has no default outlet.
`accountId`	Yes	The member/account ID
`serviceId`	Yes	The service ID
`startTime`	Yes	Start time in HH:MM format
`resourceId`	No	Resource ID
`bookingDate`	Yes	Date in YYYY-MM-DD format

Output Schema

Name	Required	Description
`data`	Yes	Tool result payload — shape varies per tool, see the tool description
`summary`	Yes	One-line human-readable summary of the action
`renderType`	Yes	UI rendering hint for the result

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 6, 2026

addedInput schema / properties / outletId

Added value: +{
+  "description": "Outlet/location ID. Required when the company has multiple outlets and the member has no default outlet.",
+  "type": "string"
+}

First observedJun 8, 2026

TDQS

A4.2/5.0

Behavior3/5

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

The annotations already establish that this is a write operation without an idempotency guarantee, while the description adds the useful availability-check dependency. It does not disclose what happens for invalid or newly unavailable slots, the booking's initial confirmation state, notification side effects, or duplicate-submission behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences front-load the purpose and then give the prerequisite workflow. Apart from minor repetition of 'create,' there is no filler, and both sentences support selection or invocation.

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?

Combined with the fully documented input schema, output schema, and annotations, the description is sufficient for most correct calls and addresses the key availability prerequisite. It is not fully complete for a nine-parameter write because confirmation state, failure or duplication behavior, and optional staff/resource assignment behavior remain unstated.

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%, including date/time formats and the conditional outletId requirement, so the schema performs most of the parameter documentation. The description's references to service, member, date, time, and valid slots add limited context but do not explain how slot results map to startTime and endTime.

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 opening sentence specifies the operation, resource, and target: creating a new booking for a member. Calling it a new booking and positioning get_available_slots as a preliminary lookup distinguish the tool from lookup and booking-lifecycle siblings such as confirm_booking and reschedule_booking.

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 provides an explicit workflow: use get_available_slots first to find valid times, then create the booking. This gives the agent concrete sequencing guidance and names the related tool, though it does not explicitly redirect existing-booking changes to reschedule_booking.

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

All FavCRM 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.