bizdays

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose: adding/subtracting days, counting between dates, checking holiday rules, verifying a single date, and finding next/previous business days. No overlap exists.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., add_business_days, is_business_day, next_business_day). 'country_rule' is the only slight deviation but still fits the overall style.
Tool Count5/5
With 6 tools, the server covers all essential business day operations without unnecessary tools. The count is well-scoped for its purpose.
Completeness5/5
The tool set provides complete CRUD-like operations for business days: addition, subtraction, counting, checking, and finding adjacent days. The inclusion of country_rule adds transparency. No obvious gaps.
Average 4.3/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 17 commits in the last 12 weeks
- Last stable release on June 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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.
This repository includes a glama.json configuration file.
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.
View related servers

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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses that the result is the first business day strictly after the given date, taking into account the country and optional extra holidays. It does not mention error cases or performance, but provides sufficient behavioral context.
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 consists of two concise sentences. The first sentence is an imperative directive, and the second explains the output. Every sentence adds value with no wasted words.
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 no output schema, the description adequately explains the return value (first business day strictly after). It covers the parameters indirectly. It could mention error handling or edge cases, but for a simple tool, the completeness is satisfactory.
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 baseline is 3. The description reinforces the purpose but adds no new semantic detail beyond the schema, such as clarifying the 'extraHolidays' parameter or specifying date format beyond what is already in the schema.
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 what the tool does: find the next working day after a date, using a specific verb and resource. It distinguishes from siblings by emphasizing 'strictly after' and providing an example scenario, differentiating it from previous_business_day and add_business_days.
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 includes an implicit usage guideline ('USE THIS... instead of guessing') and an example scenario, but it does not explicitly exclude alternatives or contrast with sibling tools. More explicit guidance would be beneficial.
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 fully bears the burden of disclosing behavior. It states that both endpoints are included by default (hinting at the inclusive parameter), that weekends and public holidays of the specified country are excluded, and that the output includes a count plus a breakdown of weekend days and named holidays. This is sufficient for a counting tool, though it doesn't specify error handling or rate limits.
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 concise, consisting of two sentences with no wasted words. It front-loads the key instruction 'USE THIS', making it immediately clear. Every sentence adds value: the first explains why the tool is needed, and the second explains what it does and returns.
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?
The tool has 5 parameters, all described in the schema. There is no output schema, but the description mentions the return value (count plus breakdown). Given the complexity of a date-counting tool, the description provides enough context for an agent to understand input, behavior, and output. It could be more complete by noting edge cases like invalid dates, but it's adequate.
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 is already described in the schema. The description adds minimal additional meaning: it mentions the default inclusive behavior of both endpoints, which aligns with the inclusive parameter. This slight addition justifies a score slightly above baseline (3), as the schema does the heavy lifting.
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?
Clearly states the tool counts working days between two dates, accounting for holidays and weekends of a specific country. The description uses a specific verb 'count' and resource 'business days', and the name itself distinguishes it from sibling tools like add_business_days, is_business_day, etc.
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?
The description explicitly instructs to use this tool for counting working days instead of estimating, noting that LLMs commonly miscount due to holidays or weekend rules. It implies the tool is accurate but does not explicitly mention when not to use it or contrast with siblings beyond the name. Still, it provides clear context for its primary use case.
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 provided, so description carries full burden. It states it returns whether it's a business day and the precise reason if not (weekend, public holiday, custom holiday). It mentions 'Country-correct weekends and public-holidays-only' which explains logic. No destructive or extra behaviors need disclosure.
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 are concise and front-loaded with 'USE THIS'. Every sentence adds value without redundancy.
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?
No output schema exists, but description hints at return value (business day status and reason). Also explains country-specific weekends and holidays. It is complete for a simple check tool with 100% parameter coverage.
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 schema already describes all parameters with types, descriptions, and requirements. The description adds no additional meaning beyond schema.
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 checks if a date is a working day before scheduling, and specifies it returns business day status with reasons. This distinguishes it from siblings like add_business_days or next_business_day which manipulate dates.
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?
The description explicitly says 'USE THIS to check whether a specific date is a working day before scheduling on it — do not assume any weekday is open.' This gives clear when-to-use guidance. Alternatives are implied by sibling names but not explicitly listed.
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 clearly states the return value ('first business day strictly before the given date for that country') and notes the effect of extraHolidays. However, it does not disclose any read-only nature or potential rate limits, which is acceptable for a simple lookup.
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, front-loaded with 'USE THIS', zero waste. Every word is necessary and contributes to understanding.
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?
Given no output schema, the description sufficiently explains what the tool returns. All parameters are described in schema, and the description covers the core behavior. For a simple utility tool, it is complete.
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 baseline is 3. The description adds meaning to 'extraHolidays' by providing an example ('e.g. a company shutdown day'). It does not add much to 'date' or 'country' beyond the schema, but the overall desc adds value.
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 uses a specific verb-resource pair ('find the most recent working day') and distinguishes from siblings like 'next_business_day' by focusing on the 'previous' direction. The phrase 'USE THIS to find... instead of guessing' clarifies its unique role.
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 when to use (before a date/holiday) and provides an alternative ('instead of guessing'), but it does not explicitly exclude other tools like 'next_business_day' or 'is_business_day'. For a straightforward tool, this is adequate but not explicit.
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 shoulders the burden. It discloses all key outputs (weekend day sources, calendar application, confidence, caveats) and implies read-only behavior. Missing are potential errors or auth requirements, but for a simple lookup, this is sufficient.
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: first lists what it returns, second gives usage advice. Front-loaded with 'USE THIS', no redundant words. Highly efficient and well-structured.
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?
Given the tool's simplicity (1 param, no output schema), the description is comprehensive. It covers what the tool does, what it returns, and when to use it. No gaps for an agent to make a correct decision.
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% with a clear description for the 'country' parameter (ISO 3166-1 alpha-2, examples). The description adds no additional parameter semantics beyond usage examples, so baseline 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 that the tool inspects how bizdays treats a country, listing specific outputs (weekend days, sources, public holiday calendar, confidence flag, caveats). This distinguishes it from sibling tools that modify or calculate business days, so an agent can easily differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use this tool 'before relying on a result' and when a country is unusual (Gulf states, Israel, Nepal) or results are surprising. This provides clear when-to-use and implies when not to use, making it highly actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully reveals behavior: it handles negative values, adjusts weekends per country (e.g., Friday/Saturday in Saudi Arabia), skips only real public holidays not observances, and returns result date, weekday, and skipped weekends/holidays.
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 'USE THIS', and contains no redundant information. Every clause adds meaningful context.
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?
With no output schema and four parameters, the description covers all essential aspects: purpose, input parameters, behavior (weekends, holidays, negative days), and output. It is fully adequate for an agent to select and invoke the tool correctly.
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 baseline is 3. The description adds value by explaining country-specific weekend behavior and the distinction between public holidays and observances, which goes beyond the schema's parameter 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 explicitly states the tool computes deadlines or settlement dates by adding/subtracting business days, using a clear verb and resource. It distinguishes itself from siblings like count_business_days and is_business_day by focusing on date calculation rather than counting or checking.
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?
The description begins with 'USE THIS' to strongly indicate when to use, and provides context about computing deadlines instead of manual counting. However, it does not explicitly state when not to use or mention alternatives.
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:

[![bizdays MCP server](https://glama.ai/mcp/servers/qinisolabs/bizdays/badges/card.svg)](https://glama.ai/mcp/servers/qinisolabs/bizdays)

Score Badge

Copy to your README.md:

[![bizdays MCP server](https://glama.ai/mcp/servers/qinisolabs/bizdays/badges/score.svg)](https://glama.ai/mcp/servers/qinisolabs/bizdays)

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/qinisolabs/bizdays'

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