Skip to main content
Glama

hr_leave_planning_loop

Destructive

Plan employee leave schedules and manage leave requests by sending objectives and structured inputs to the HR domain agent. Resolve staffing coverage needs efficiently.

Instructions

Run the hr domain agent action leave_planning_loop.

Routes through the platform's domain-agent dispatcher under your JWT, tenant, and company scope.

Args: message: Free-text objective for the action. inputs: Optional JSON string of structured inputs for the action.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputsNo{}
messageNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.4/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true, readOnly=false, and idempotent=false, but the description adds no explanation of what side effects the leave planning loop may have, what it mutates, or how long it runs. The dispatcher routing and JWT/tenant/company scope is useful execution context but not behavioral transparency for a destructive action.

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?

The description is tight: an imperative first line, one sentence on routing/scope, then a compact Args list. There is no filler beyond the mildly redundant leading sentence.

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

Completeness2/5

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

For a destructive, open-world agent loop with two free-form parameters, the description leaves out the actual purpose of leave planning, the kinds of objectives to provide, and what the loop will do. It is not enough for an agent to decide whether to invoke this tool or what a correct call looks like.

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?

The description adds basic semantics beyond the schema: message is a 'free-text objective' and inputs is an 'Optional JSON string of structured inputs.' However, it doesn't specify what structured inputs are valid, what key/value shapes the underlying action expects, or any examples, so it only partially compensates for 0% schema coverage.

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

Purpose2/5

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

The description says only 'Run the hr domain agent action `leave_planning_loop`' and explains the dispatcher routing, but never states what leave planning actually does or what outcome it produces. It does not distinguish this tool from other HR actions like hr_leave_request or dispatch_domain_agent beyond the opaque action name.

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?

No when-to-use or when-not-to-use guidance is provided; it never mentions alternatives or conditions that would select this over other HR tools. The only contextual clue is 'domain-agent dispatcher' routing, which is mechanism, not usage policy.

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

Deploy Server

Other Tools