Sliq

Create calendar event

create_calendar_event

Destructive

Use search_emails or search_calendar to find email addresses for prior attendees. For new attendees whose email you don't have, use find_email. Dict with success status and event details

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": {
      "subject": "<subject>",
      "start_datetime": "<start_datetime>",
      "end_datetime": "<end_datetime>"
    },
    "name": "create_calendar_event"
  }
}

Input Schema

Name	Required	Description
`body`	No	Optional event description/notes (plain text)
`subject`	Yes	Event title
`location`	No	Optional event location
`provider`	No	Which calendar to use ('outlook' or 'google'). Only needed if the user has both connected -- ask them which to use, then pass it here.
`attendees`	No	Optional list of attendees. Each is an object with required "email" and optional "name". Examples: [{"email": "alice@acme.com", "name": "Alice Smith"}] or [{"email": "alice@acme.com"}].
`in_person`	No	ALMOST ALWAYS OMIT THIS PARAMETER or set to false. ONLY set to true if the user literally says "in-person", "in person", "at my office", or "no video link". If there is ANY ambiguity, do NOT set this to true. A video meeting link is automatically added when this is false (the default).
`end_datetime`	Yes	End time as ISO 8601 in the user's LOCAL timezone, not UTC (e.g., "2026-02-17T11:00:00"). Do not include a timezone offset or Z suffix. Default to 30 minutes after start if user does not specify.
`on_behalf_of`	No	A teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account.
`start_datetime`	Yes	Start time as ISO 8601 in the user's LOCAL timezone, not UTC (e.g., "2026-02-17T10:00:00"). Do not include a timezone offset or Z suffix.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 6, 2026

changedInput schema / properties / on_behalf_of / description

Previous value: -"An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."New value: +"A teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."

Changed1 schema field changedOct 21, 2026

changedInput schema / properties / attendees / anyOf

Previous value: -[
-  {
-    "items": {
-      "description": "An email/calendar recipient. `name` is optional — both Gmail and Outlook\nbackends fall back to empty string when omitted, so the model can pass just\n`{\"email\": \"alice@acme.com\"}` if it doesn't have a display name handy.\nKeeping `name` required at the schema layer caused agents to burn tool\nretries guessing the right shape (SLI-12622).",
-      "properties": {
-        "email": {
-          "type": "string"
-        },
-        "name": {
-          "type": "string"
-        }
-      },
-      "required": [
-        "email"
-      ],
-      "title": "Recipient",
-      "type": "object"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "description": "An email/calendar recipient. `name` is optional — both Gmail and Outlook\nbackends fall back to empty string when omitted, so the model can pass just\n`{\"email\": \"alice@acme.com\"}` if it doesn't have a display name handy.\nKeeping `name` required at the schema layer caused agents to burn tool\nretries guessing the right shape (SLI-12622).",
+      "properties": {
+        "email": {
+          "type": "string"
+        },
+        "name": {
+          "default": "",
+          "type": "string"
+        }
+      },
+      "required": [
+        "email"
+      ],
+      "title": "Recipient",
+      "type": "object"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

Changed2 schema fields changedOct 19, 2026

addedInput schema / properties / on_behalf_of

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
+}

changedInput schema / properties / provider / anyOf

Previous value: -[
-  {
-    "enum": [
-      "outlook",
-      "google"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "outlook",
+      "google"
+    ],
+    "title": "Provider",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

First observedSep 15, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false and destructiveHint=true; the description usefully adds that a video conferencing link is created by default and that user confirmation is mandatory before the call. It does not explain why the operation is flagged destructive (invites/notifications being sent to attendees, and irreversibility of a sent invite), which is a real gap for a mutation tool the harness marks destructive.

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?

The summary block is front-loaded with the core action and the confirmation rule, then the prerequisite routing, so an agent gets the essentials in the first two sentences. Minor waste from the XML-style <summary>/<returns> wrapper, though the returns line earns its place since no output schema exists.

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 mutation tool with no output schema, the description covers the confirmation gate, the default video-link behavior, provider choice, and attendee resolution, and it gives a rough return shape. It still leaves the destructive side effect (invites dispatched to attendees) and multi-calendar/timezone edge cases undocumented.

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 adds meaning on top: it ties in_person to the auto-video-link consequence and describes the attendee-email sourcing workflow (search_emails/search_calendar/find_email) that the schema's per-property text does not. It stops short of guidance on provider selection conflicts or on_behalf_of, both of which live only in the schema.

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?

States a specific verb and resource ('Create a calendar event in the user's connected calendar') and immediately scopes it to Outlook or Google. It also discloses the default side effect (a Zoom/Meet/Teams link is auto-added unless in_person=true), which makes it unmistakable against siblings like update_calendar_event or search_calendar.

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?

Gives an explicit precondition ('ALWAYS present the event details to the user and ask for explicit confirmation before calling this tool') and routes the agent to alternatives for a prerequisite sub-task: search_emails/search_calendar for prior attendees' addresses, find_email for new ones. When-to-use and when-to-delegate are both stated.

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

All Sliq 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?