calendar_get_calendar

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

The description accurately indicates a read-only operation, consistent with the readOnlyHint and non-destructive annotations. It does not describe error cases or authorization behaviors, but the annotations already cover the main safety aspects.

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

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

The description is brief, direct, and free of extraneous detail. Two sentences convey the core operation and the special default behavior without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read operation, the description covers the main input behavior and return focus. However, the lack of accountId semantics and the absence of any output schema or return-shape hints leave some gaps for an agent needing to call this tool correctly in a multi-account context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

calendarId is well described with the 'default' special value, but accountId has no schema description and is not explained in the tool description. Since one of two required parameters lacks semantic guidance, the description only partially compensates for the 50% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Read') and the resource ('a selected accessible calendar' plus its Graph-reported permissions). It also clarifies the special default value for resolving /me/calendar, making the tool's purpose unambiguous.

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

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

The description implies usage when calendar metadata or permissions are needed, and the default resolution is helpful. However, it does not explicitly contrast with sibling tools like calendar_list_calendars or calendar_get_event, leaving the selection of this tool somewhat implicit.

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