Skip to main content
Glama

list_leave_periods

Read-only

Retrieve leave periods for a week or date range before logging time, so you can avoid days already marked as leave.

Instructions

List leave periods over a week or a period. Useful before logging time: Gryzzly refuses a declaration on a day already declared as leave.

Input Schema

NameRequiredDescriptionDefault
toNoLast day of an explicit period.
fromNoFirst day of an explicit period.
weekNoA week: `this week`, `last week`, `2026-W38`, or a date inside it.
limitNoHow many objects to return. Upstream maximum is 1000.
usersNoWhose leaves to read, by name, email or id. Defaults to everyone.
offsetNoHow many objects to skip, for the next page.

Output Schema

NameRequiredDescriptionDefault
noteNoSet when the answer is worth a word of explanation.
countYesHow many objects match the filters upstream, beyond this page.
itemsYesThe objects.
returnedYesHow many objects this answer carries.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description adds a non-obvious domain rule not present in structured fields (the system refuses a declaration on a day already declared as leave). It does not discuss pagination behavior, though limit/offset in the schema imply it.

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 sentences, zero filler: the first states what is listed and its scope, the second earns its place by explaining the concrete downstream benefit. The core action is front-loaded.

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

Completeness5/5

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

An output schema exists, so return values need not be explained, and the input schema fully documents all six optional parameters. With annotations covering the read-only/open-world profile and the description covering when-to-use and the leave-conflict rule, an agent has everything needed to call it correctly.

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 all six parameters (to, from, week, limit, users, offset) are already documented with examples and defaults in the schema. The description adds no parameter-level syntax or format detail, so the baseline of 3 applies.

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 and resource ('List leave periods') plus the scoping dimension ('over a week or a period'), which maps to the week/from/to parameters. It does not name the sibling singular lookups (get_leave_period) or the sibling list tools, so the agent must infer differentiation from the name alone.

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?

Gives an explicit usage context tied to a sibling workflow: 'Useful before logging time,' which routes the agent to call this before log_time/log_time_bulk. No when-not guidance or explicit alternative-naming, but the when-to-use signal is concrete and actionable.

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