Skip to main content
Glama
Sign In

Tulina

by ai.tulina.mcp
OverviewDiscussionsAdmin

calendar_event

An event in a calendar — list, read, create, fix or delete one.

op:

  • "list" (default): list events from a calendar over a time range (ordered by start). Returns {events: [{id, summary, start, end, ...}], count}.

  • "get": get a single calendar event by id (event_id, detailed — adds description, attendees, recurrence, reminders).

  • "create": create a calendar event (summary + start, optional attendees = guest emails). ⚠️ Writes into a real calendar. With send_updates="none" (default) the guests are added but nobody is emailed — pass "all" to send the invitations. meet=True attaches a Google Meet link (returned as hangoutLink).

  • "update": fix an existing event (event_id + what changes). PATCHES — only the fields you pass are touched, everything else (attendees, recurrence, reminders, meeting link) is left alone. Use this instead of creating a second event. attendees, when passed, REPLACES the whole guest list (Google's rule for lists): pass everyone — read the current guests with op="get" — and [] removes them all.

  • "rm": delete an event (event_id). Irreversible. Returns what was deleted (summary + start), read before the deletion — so that deleting the wrong id does not look exactly like deleting the right one.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "calendar_event"
  }
}

Input Schema

NameRequiredDescriptionDefault
opNolist (default) | get | create | update | rm.list
endNoop="create" — end time. If omitted, defaults to start + 1h (timed) or same day (all-day). ⚠️ For an all-day event Google reads the end DATE as exclusive: pass the next day to cover one full day.
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
meetNoop="create" — True attaches a Google Meet link, returned as `hangoutLink`; `meet_status="pending"` means Google is still creating it (read the event again with op="get").
queryNoop="list" — free-text search over event fields.
startNoop="create" — start time: ISO 8601 datetime (timed) or 'YYYY-MM-DD' (all-day).
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
_run_idNoOBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
accountNoemail of the Google account to use — same choice as `_account`.
all_dayNoop="create" — treat start/end as dates (YYYY-MM-DD). ⚠️ A 10-character `start` ('YYYY-MM-DD') is treated as all-day even when all_day is False (CalendarClient.create_event).
summaryNoop="create" — event title.
_accountNoCompte à OPÉRER quand plusieurs existent. `oto_identity(op='list')`.
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
event_idNoop="get" — the event id (from op="list").
locationNoop="create" — event location.
time_maxNoop="list" — upper bound, ISO 8601. Omit either bound to leave it open.
time_minNoop="list" — lower bound, ISO 8601 (e.g. '2026-06-18T00:00:00Z'). For "today" pass today's 00:00; for "next 7 days" pass now.
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
attendeesNoop="create"/"update" — guest email addresses. On update it REPLACES the guest list (`[]` removes every guest).
calendar_idNocalendar id (default 'primary'). Ids come from calendar_calendars.primary
descriptionNoop="create" — event description.
max_resultsNoop="list" — max events to return (default 20).
send_updatesNoop="create"/"update"/"rm" — whether attendees get an email. Default **"none"**: fixing a typo must not mail twelve people, and cancelling silently is the lesser surprise. Pass "all" deliberately.none

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full burden and does so well: it flags that create "Writes into a real calendar," that send_updates="none" silently skips invitations, that update is a PATCH leaving unmentioned fields alone, that attendees REPLACES the whole guest list per Google's rule, and that rm is irreversible with a read-before-delete return. Gaps remain around timezone handling and permission/scoping, but the mutation and side-effect profile is unusually well disclosed.

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 single-sentence purpose line is front-loaded and the per-op bullets map one-to-one onto the enum values, which is the right structure for a 5-op tool. It loses a point for restating schema-level warnings (all-day end exclusivity, send_updates rationale) that already live in the parameter descriptions.

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 23-parameter, five-operation tool with no annotations and no output schema, the description supplies return shapes for list and rm and names hangoutLink for Meet, plus the destructive-operation story. It stops short of describing return values for get/create/update and says nothing about timezone or account/org scoping, which leaves modest gaps against the tool's complexity.

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 description coverage is 100%, so the schema already documents every one of the 23 parameters in detail, including the same all-day/exclusive-end and send_updates warnings the description repeats. The description adds cross-parameter flow knowledge (read guests via op="get" before an update) but little else beyond the schema, so the baseline 3 applies.

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 line names the resource (calendar event) and enumerates the five verbs it covers (list, read, create, fix, delete), then each op is broken out with its own specific semantics. An agent can tell immediately that this single tool handles the full event lifecycle, distinct from calendar_calendars which only supplies calendar ids.

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?

Every op carries its selection condition: "get" is for a single detailed event, "update" explicitly says "Use this instead of creating a second event," and update/rm flows are prescribed ("read the current guests with op=\"get\""). The send_updates guidance ("Pass \"all\" deliberately") tells the agent when-not-to-use a default.

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

All Tulina toolsInspect
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