Skip to main content
Glama

Create an event

create_event
Destructive

Schedule a calendar event in Microsoft 365 with start and end times, subject, optional location, and attendees. Invites attendees, so use resolved addresses and check free time first.

Instructions

Create a calendar event. If it has attendees, they are invited, which reaches real people, so get their addresses from resolve_person and check the slot with find_free_time first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endYesYYYY-MM-DDTHH:MM
startYesYYYY-MM-DDTHH:MM
subjectYes
locationNo
attendeesNoaddresses from resolve_person

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

The description discloses that attendees are actually invited and that this reaches real people, which is valuable behavioral context beyond the annotations. It does not contradict the openWorldHint or destructiveHint annotations, and it makes the real-world side effect concrete.

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 tight sentences with no wasted words. The most important caveat—inviting real people—is front-loaded, and the required setup steps are placed right after the core purpose.

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 create tool with no output schema, it covers the critical safety and precondition context well. It does not describe the return value or what happens after creation, but the essential usage guidance is present and sufficient for correct invocation.

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 60%, and the description mainly reinforces the attendees parameter with 'addresses from resolve_person', which is already in the schema. It does add indirect context about start/end by advising a free-time check, but it adds little beyond the schema for subject and location.

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 description states 'Create a calendar event' with a specific verb and resource, clearly distinguishing it from sibling tools like update_event and cancel_event. The additional note about inviting attendees makes the scope even clearer.

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?

The description gives explicit preconditions: get attendee addresses from resolve_person and check availability with find_free_time before creating the event. It lacks an explicit 'when not to use' or alternative routing, but the usage context is clear and actionable.

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