Skip to main content
Glama
debanjanbasu

grr

by debanjanbasu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

calendar.acl.insert

Creates an access control rule that grants a user or group a role on a calendar, enabling shared calendar access with optional notifications.

Instructions

Creates an access control rule [HTTP POST] — creates or triggers a change; refused under --readonly safety profiles. Returns the API's response resource as JSON — request body is a JSON AclRule object accepting etag, id, kind, role, scope; pass it via params or whole via body_file Siblings over the same resource: delete, get, list, patch, update, watch.

Input Schema

NameRequiredDescriptionDefault
queryNoExtra KEY=VALUE query pairs for endpoints whose parameters Discovery does not describe.
paramsNoParameter map merged into the request; typed parameters win.
dry_runNoReturn the request that would be sent, without sending it.
body_fileNoRead the request body from this file ('-' for stdin) instead of building one from the parameters. The body is a JSON AclRule object.
calendarIdYes[URL path segment] Calendar identifier. To retrieve calendar IDs call the calendarList.list method. If you want to access the primary calendar of the currently logged in user, use
request_bodyNoRequest body of type AclRule: pass it via `params` (merged into the built body) or whole via `body_file`.
sendNotificationsNo[query parameter] Whether to send notifications about the calendar sharing change. Optional. The default is True.

Output Schema

NameRequiredDescriptionDefault
idNo
etagNo
kindNo
roleNo
scopeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / body_file / description
      Previous value: -"Read the request body from this file ('-' for stdin) instead of building one from the parameters."New value: +"Read the request body from this file ('-' for stdin) instead of building one from the parameters. The body is a JSON AclRule object."
    • addedInput schema / properties / request_body
      Added value: +{
+  "description": "Request body of type AclRule: pass it via `params` (merged into the built body) or whole via `body_file`.",
+  "properties": {
+    "etag": {
+      "type": "string"
+    },
+    "id": {
+      "type": "string"
+    },
+    "kind": {
+      "type": "string"
+    },
+    "role": {
+      "type": "string"
+    },
+    "scope": {
+      "properties": {
+        "type": {
+          "type": "string"
+        },
+        "value": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    }
+  },
+  "type": "object"
+}
  2. Changed3 schema fields changed
    • changedInput schema / properties / calendarId / description
      Previous value: -"Calendar identifier. To retrieve calendar IDs call the calendarList.list method. If you want to access the primary calendar of the currently logged in user, use"New value: +"[URL path segment] Calendar identifier. To retrieve calendar IDs call the calendarList.list method. If you want to access the primary calendar of the currently logged in user, use"
    • changedInput schema / properties / sendNotifications / description
      Previous value: -"Whether to send notifications about the calendar sharing change. Optional. The default is True."New value: +"[query parameter] Whether to send notifications about the calendar sharing change. Optional. The default is True."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "etag": {
+      "type": "string"
+    },
+    "id": {
+      "type": "string"
+    },
+    "kind": {
+      "type": "string"
+    },
+    "role": {
+      "type": "string"
+    },
+    "scope": {
+      "properties": {
+        "type": {
+          "type": "string"
+        },
+        "value": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    }
+  },
+  "type": "object"
+}
  3. First observed

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations available, the description carries the safety burden itself: it marks this as a mutating POST, notes it is blocked under --readonly profiles, and says it returns the API response resource. It omits real-world side effects such as the sharing grant being sent and the sendNotifications implication, which keeps it out of the top band.

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?

A single dense sentence, but front-loaded with the verb, resource and HTTP method before moving to body handling and siblings. Slightly crammed by em-dashes, yet every clause contributes something actionable.

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?

An output schema exists, so return-value description is unnecessary, and the description still covers mutation semantics, readonly rejection and body-passing mechanics. The only material gap for a zero-annotation mutation tool is the absence of permission/scope requirements and side effects like notification emails.

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 AclRule fields and the calendarId/sendNotifications semantics are already documented. The description's restatement of etag/id/kind/role/scope adds little, though the note that the body can go via `params` or whole via `body_file` clarifies the two intake paths.

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+resource ('Creates an access control rule') with the HTTP method, and explicitly positions the tool against the six siblings on the same resource (delete, get, list, patch, update, watch). An agent can immediately tell this is the create path for calendar ACLs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It names the sibling operations over the same resource, which implies the create-vs-modify boundary, and it flags that the call is refused under --readonly safety profiles. But it never states when to prefer insert over patch/update (e.g., new grantee vs. changing an existing rule), so the choice is left to inference.

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

Deploy Server

Other Tools