get_time_off_policy
Retrieve a single time-off policy by its ID to view rules and configurations for a specific workspace.
Instructions
Get a single time-off policy by id.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| policy_id | Yes | ||
| workspace_id | No |
Retrieve a single time-off policy by its ID to view rules and configurations for a specific workspace.
Get a single time-off policy by id.
| Name | Required | Description | Default |
|---|---|---|---|
| policy_id | Yes | ||
| workspace_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('get') but does not elaborate on behavior such as required permissions, side effects, or response format. Since no annotations are provided, the description carries full burden, and a simple 'get' is acceptable but minimal. No contradiction with annotations as none exist.
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 a single, front-loaded sentence with no extraneous words. Every word serves a purpose, making it highly concise and easy to parse.
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?
Given the lack of schema descriptions and no output schema, the description is too sparse. It does not explain the optional parameter workspace_id, nor does it reference sibling tools for context (e.g., list_time_off_policies). For a simple get tool, some additional behavioral context would improve completeness.
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 0%, so the description must compensate. It only mentions 'by id,' which explains policy_id, but fails to clarify the purpose of the optional workspace_id parameter. This leaves ambiguity about whether workspace_id is needed and how it affects the query.
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 'Get a single time-off policy by id,' specifying the verb (Get) and resource (time-off policy), and identifies the key parameter (id). However, it does not differentiate from sibling tools like list_time_off_policies, which is a related alternative.
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?
No guidance is provided on when to use this tool versus alternatives. For example, it does not mention that list_time_off_policies should be used to fetch multiple policies or when the policy_id is unknown. This omission limits the agent's ability to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tracegazer/clockify-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server