mcp-jp-paid-leave

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.0
Disambiguation5/5
Each tool addresses a distinct aspect of Japanese paid leave: attendance rate check, entitlement calculation, grant schedule listing, proportional entitlement, carryover, mandatory five-day check, and company policy application. There is no overlap in purpose.
Naming Consistency4/5
Most tools follow a verb_noun pattern (e.g., check_attendance_rate, calculate_entitlement), but 'proportional_entitlement' lacks a verb, introducing a minor inconsistency.
Tool Count5/5
Seven tools cover the core computations and checks for paid leave without being excessive. Each tool serves a necessary function, and the count is well-scoped for the domain.
Completeness5/5
The set covers all essential aspects of Japanese paid leave management: eligibility conditions, entitlement calculation (standard and proportional), grant scheduling, carryover, mandatory five days, and company policy. No obvious gaps for the intended purpose.
Average 3.8/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool returns determination and remaining days, implying a read-only query, but does not explicitly state side effects, authorization needs, or rate limits. The description is adequate but minimal for a check tool.
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 a single, dense sentence that conveys the essential information without fluff. It is front-loaded with the target condition and then states the outputs. However, it could be broken into multiple sentences for readability, but it earns a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (legal requirement, 6 parameters, no output schema), the description explains the legal basis and what it returns (determination and remaining days), but it does not specify the return format or how parameters interact. With full schema coverage, it is adequate but could be more complete.
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 each parameter has a description. The tool description adds no parameter-specific meaning beyond the schema; it only gives high-level context about the legal requirement. Thus baseline score 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: determining if the mandatory five-day paid leave requirement applies and returning the fulfillment status and remaining days. It specifies the target population (workers with 10+ days granted) and cites the relevant law, distinguishing it from siblings like 'check_attendance_rate' or 'calculate_entitlement' by its unique legal focus.
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 does not provide any guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or how it differs from siblings like 'calculate_entitlement' or 'apply_company_policy'. This leaves the agent to infer usage context without explicit instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool corrects policy below legal minimum and returns a warning. However, it does not mention whether the operation is destructive, idempotent, or requires authorization. For a mutation tool, more behavioral context is needed.
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?
The description is two sentences, front-loaded with the primary action, and adds the special case in the second sentence. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and the description does not explain what is returned (e.g., adjusted days, warning object). It also lacks information on error handling beyond the warning case. Given the simplicity, more details on return format would improve completeness.
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 the schema already documents both parameters. The description adds no new semantic information beyond echoing the parameter roles. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies company policy additions on top of legal minimum days, and includes corrective behavior when policy is below legal. The verb ('apply') and resource ('company policy addition') are specific, and the tool is distinct from siblings like calculate_entitlement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used after legal minimum days are computed, but it does not explicitly state when to use it versus alternatives (e.g., calculate_entitlement or check_attendance_rate). No exclusion criteria or 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses a non-obvious behavior: if some reference dates fall before 2001-04-01, those are marked as supported:false and the call does not error. This is good transparency, though other behaviors like error conditions are not mentioned.
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?
The description is a single, concise paragraph. It is front-loaded with the main purpose and follows with an important edge case. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details about the output format (it says returns a list but not the structure). Also, parameter dependencies like uniformBasisMonthDays being required for uniform mode are not explained, though they are in the schema. Given the tool has 7 parameters and no output schema, more context would be beneficial.
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 baseline is 3. The description adds context about the overall purpose and the lower date limit behavior, but does not significantly elaborate on individual parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a list of scheduled annual paid leave grants for a specified number of years from hire date, including handling of dates before the verified lower limit. This is distinct from sibling tools like check_attendance_rate or calculate_entitlement.
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 does not provide any explicit guidance on when to use this tool versus alternatives. There are no when-to-use, when-not-to-use, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it calculates based on legal minimum, handles uniform method with chain of early grants, and validates a lower bound date. It does not explicitly state it is read-only, but as a calculation tool, that is implied.
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 a single paragraph of four sentences, front-loading the main purpose. It is concise without waste, though a slightly more structured format (e.g., bullet points for return values) could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core calculation and two methods, and mentions return values (grant date, days, shortened period for uniform). However, without an output schema, it lacks details on the exact format of the response, which is needed for a 7-parameter tool.
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 coverage is 100%, so the description adds minimal extra meaning beyond the schema. The description provides some behavioral context for parameters (e.g., the lower bound check) but does not enhance individual parameter understanding significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates annual paid leave entitlement (grant date and days) based on hire date and reference date method, distinguishing between individual and uniform methods. It is distinct from sibling tools like check_attendance_rate or list_grant_schedule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its purpose but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives or context for choosing this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'calculates', implying a read-only operation, but does not explicitly confirm non-destructive behavior or disclose any side effects, prerequisites, or error conditions. For a calculation tool, this is adequate but could be more explicit.
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?
The description is a single, tightly phrased sentence in Japanese that directly conveys the tool's purpose. Every word is meaningful, and the structure is front-loaded with the core action ('calculates proportional entitlement days'). No redundancies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema), the description is brief. It does not explain the output (presumably days) or the relationships between parameters (e.g., mutual exclusion of weekly/annual days). Although the schema covers these details, the description could improve completeness by summarizing key inputs and output behavior.
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 coverage is 100%, so the baseline is 3. The description adds value by framing the calculation within Japanese labor law ('statutory minimum standards') and hinting at the primary parameters (weekly or annual scheduled days). This context helps an AI agent understand the legal significance, extending beyond the schema's technical descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: it calculates proportional entitlement days for annual paid leave for part-time workers based on statutory minimum standards. It uses specific verbs ('calculates') and resources ('proportional entitlement days'), and distinguishes itself from siblings like 'calculate_entitlement' by specifying 'proportional' and 'statutory minimum'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for calculating proportional leave for part-time employees, but it does not explicitly state when to use this tool versus siblings like 'calculate_entitlement' or 'check_attendance_rate'. No alternatives or exclusions are mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the FIFO consumption assumption and the computation of expiration and remaining days, though it does not mention side effects or permissions (likely read-only).
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?
The description is two sentences, front-loading the purpose then providing one key behavioral detail. No redundant information.
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?
Given the complexity (multiple grants, usage records, FIFO, statute) and no output schema, the description covers inputs, outputs, and calculation logic adequately. Lacks edge case handling but sufficient for typical use.
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 the schema already documents each parameter. The description adds no additional per-parameter detail beyond overall context, setting a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates expiration days under the 2-year statute and remaining days as of a reference date using multiple grant and usage records. It is distinct from sibling tools like check_attendance_rate or calculate_entitlement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the calculation method (FIFO consumption) and inputs, but does not explicitly state when to use this tool over alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description carries full burden. It discloses that classification is done internally based on legal standards, that a sum constraint must hold, and that output includes a breakdown with legal basis. This provides substantial behavioral context beyond the input schema.
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?
Description is long but front-loaded with purpose, then instructions, then constraints. Each sentence serves a purpose. No redundancy. Given complexity (legal rules, 12 parameters), this is appropriately concise.
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 complex tool with 12 required parameters and legal logic, description covers purpose, usage constraints, parameter relationships, and output inclusion (breakdown). No output schema exists, so description's promise of breakdown is sufficient. Minor gap: no explicit return format, but not needed.
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 coverage is 100%, baseline 3. Description adds value by explaining that caller should not classify, that all days are required, and the critical relationship between scheduledWorkingDays and other fields. This compensates for the high parameter count (12) and clarifies usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it determines whether attendance rate meets 80% threshold for annual paid leave, using a specific verb ('判定する') and resource ('出勤率8割の判定'). It distinguishes from siblings like check_mandatory_five_days by focusing on attendance rate rather than mandatory five days or carryover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides clear constraints: caller must pass raw days, all days required, sum constraint. However, it does not explicitly state when to use this tool versus siblings (e.g., check_mandatory_five_days vs calculate_entitlement). No 'when not to use' or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-jp-paid-leave MCP server](https://glama.ai/mcp/servers/skypier-jp-works/mcp-jp-paid-leave/badges/card.svg)](https://glama.ai/mcp/servers/skypier-jp-works/mcp-jp-paid-leave)

Score Badge

Copy to your README.md:

[![mcp-jp-paid-leave MCP server](https://glama.ai/mcp/servers/skypier-jp-works/mcp-jp-paid-leave/badges/score.svg)](https://glama.ai/mcp/servers/skypier-jp-works/mcp-jp-paid-leave)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/skypier-jp-works/mcp-jp-paid-leave'

If you have feedback or need assistance with the MCP directory API, please join our Discord server