Skip to main content
Glama
pfaeffli
by pfaeffli

add_my_vacation

Book vacation time for the authenticated user by specifying start and end dates, with optional half-day booking for single-day entries in Clockodo.

Instructions

Add a vacation for the authenticated user.

Args: date_since: Start date (YYYY-MM-DD) date_until: End date (YYYY-MM-DD) half_day: Book a half day. Clockodo only allows this for a single day, so date_since must equal date_until.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
half_dayNo
date_sinceYes
date_untilYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.8.0
    • addedInput schema / properties / half_day
      Added value: +{
      +  "default": false,
      +  "title": "Half Day",
      +  "type": "boolean"
      +}
  2. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already disclose the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=true). The description adds a genuine behavioral constraint not present in structured data: half_day is only accepted by Clockodo for a single day, requiring date_since == date_until. It omits any mention of permissions or failure behavior.

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?

Front-loaded with the one-line purpose followed by a compact Args block. Every line earns its place and there is no filler; the formatting is slightly schema-like but efficient.

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 simple three-parameter mutation with annotations covering the safety/idempotency profile, the description covers purpose, all parameters, formats, and the key half-day edge case. No output schema exists, so nothing about return values is owed, though failure/permission behavior is unaddressed.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate, and it does: it documents all three parameters and supplies the YYYY-MM-DD format for both dates as well as the half_day cross-field constraint. It does not mention the false default for half_day, but this is a solid effort given zero schema coverage.

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

Purpose4/5

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

States a specific verb ('Add') and resource ('a vacation') scoped to the authenticated user, which is immediately distinguishable from edit_my_vacation, delete_my_vacation, and add_my_sick_day. It does not explicitly name or contrast those siblings, so a 4 rather than a 5.

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

Usage Guidelines2/5

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

The description says nothing about when to use this tool versus edit_my_vacation or add_my_sick_day, nor any prerequisites. The half_day note is a domain constraint, not usage guidance.

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