Get Appointment

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

Annotations already cover the read-only, idempotent, non-destructive nature. The description adds the required OAuth scope and the exact endpoint, which is useful, but it does not disclose return format, error behavior, or any other notable traits. With annotations present, the bar is lower and a 3 is appropriate.

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 short but starts with a redundant repetition of the title ('Get Appointment Get appointment by ID'). It is not poorly structured, but the redundant opening could be trimmed. Overall it is concise but not optimally front-loaded.

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 lookup by ID, the description plus annotations and complete schema are nearly sufficient. However, there is no output schema and no hint of what fields are returned, and the schema's note about 'modify original series' is a confusing distraction in a read-only tool. The description could have clarified the response shape or explicitly routed to calendar event listing tools.

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?

Schema description coverage is 100% for the only parameter, so the description does not need to compensate. The description itself adds no parameter semantics beyond the endpoint path, but the baseline of 3 is correct when the schema fully documents the parameter.

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 specifies a clear verb and resource: 'Get appointment by ID' with the explicit endpoint path. It distinguishes itself from the many list/search calendar tools by focusing on a single appointment ID, though it does not explicitly name sibling alternatives.

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?

Usage is implied: use this tool when you have an event/appointment ID and need that single appointment. However, there is no explicit guidance on when not to use it or which sibling to choose instead (e.g., calendars_get_calendar_events for listing).

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