business-day-mcp

by fbdo

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: checking a date, moving forward/backward, counting between, listing holidays, etc. There is no functional overlap, so an agent can easily select the correct tool.
Naming Consistency5/5
All tool names use snake_case and follow a consistent verb_noun or noun_phrase pattern (e.g., get_current_date, is_business_day, list_holidays). The naming is predictable and intuitive.
Tool Count5/5
With 9 tools, the set is well-scoped for a business day calculator. It covers essential operations without being excessive, and includes discovery tools for supported countries/subdivisions.
Completeness4/5
The tool set covers core business day calculations well, including counting, moving, and listing holidays. A notable gap is the lack of an 'add business days' function, but most workflows are supported.
Average 4.7/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 27, 2026
- 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses that it does not consult holiday calendars, the output format (date, timezone, day_of_week, iso_week), and that it raises a ValueError for invalid timezones.
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 well-structured with 'Args', 'Returns', 'Raises' sections and is concise, providing all necessary information without unnecessary words.
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 simplicity of the tool and the presence of an output schema, the description is complete, explaining return values and error conditions. Context signals show 1 parameter and no complexity, so the description fully addresses them.
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 0%, but the description compensates by explaining the timezone parameter with examples, default value, and valid format (IANA timezone name). It adds meaning beyond 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 states exactly what the tool does: return the current date in a given IANA timezone. It is distinct from sibling tools like business days or holiday calculators.
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 suggests using this tool when a stable, server-computed 'today' is needed before calling other tools. It does not explicitly state when not to use it or list alternatives, but sibling names provide 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, but the description fully discloses behavior: it skips weekends and public holidays, has an inclusive option, raises ValueError for invalid inputs, and limits search to ~10 years. It does not mention idempotency, but that is implied for a read-only 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 well-structured with Args, Returns, Raises sections. It is front-loaded with the main purpose. Though lengthy, each sentence adds value and no 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?
Given the complexity (4 params, no annotations, but output schema exists), the description is very complete. It covers input, output, errors, and edge cases (inclusive, subdiv optional, 10-year limit).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides detailed semantics for all 4 parameters: date format, country code, inclusive boolean, subdiv with reference to get_supported_countries. This adds significant value beyond 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 states it returns the previous business day on/before or strictly before a given date. It specifies skipping weekends and public holidays, distinguishing it from siblings like next_business_day and business_days_between.
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 move backward to the most recent working day' and contrasts with other tools implicitly. It does not explicitly state when not to use it, but the context is clear.
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?
With no annotations, the description fully explains behavior: walking backward, skipping weekends and holidays, handling errors, and subdiv case-sensitivity. This leaves minimal ambiguity for the agent.
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 well-structured with paragraphs for overview, then standard Args/Returns/Raises sections. 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?
Given the tool's complexity (4 parameters, output schema, error handling), the description covers all necessary aspects: use case, algorithm, parameter details, return format, and error conditions. It is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by detailing each parameter: year (4-digit), month (1-12), country (ISO code, case-insensitive), subdiv (optional, case-sensitive, reference to get_supported_countries). This adds value beyond the schema.
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?
The description clearly states the tool returns the last business day of a given month, with specific use cases. However, it does not explicitly differentiate from sibling tools like previous_business_day or next_business_day, which could cause confusion.
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 provides explicit use cases (end-of-month billing, reporting, settlement) and mentions the algorithm (walks backward). It lacks when-not-to-use or alternative tools, but the guidance is clear enough.
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 covers behavioral aspects: sorted output, inclusion of weekend holidays, case-insensitive country normalization, case-sensitive subdiv, unsupported category filtering, and error conditions (ValueError). This exceeds minimal 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?
The description is well-structured with clear sections for arguments, return value, and errors. Every sentence adds meaningful information without redundancy. It is appropriately sized for the tool's complexity.
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?
The description covers all aspects: input constraints, output structure, error handling, and behavioral notes. Given the output schema exists, the description still explains the return format, ensuring completeness. No gaps remain for this 3-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains each parameter in detail: year format, country code case-insensitivity and normalization, subdiv optionality with examples and limitations, and provides concrete example ('country=DE, subdiv=BY'). This adds significant value beyond the raw 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's purpose: listing all holidays for a given year and country, sorted by date. It uses a specific verb ('list') and resource ('holidays'), and distinguishes from sibling tools like 'business_days_between' and 'is_business_day' by focusing on full holiday enumeration.
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 provides explicit usage scenarios ('for display, planning, or cross-referencing') and mentions that holidays on weekends are included. It does not explicitly state when not to use or name alternatives, but the context is clear enough for an agent to decide.
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?
No annotations provided, so the description carries full burden. It details behavior: only weekday holidays listed, inclusive/exclusive effect, 100-year span limit, and error conditions (ValueError for invalid input). This is comprehensive.
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?
Well-structured with paragraphs and bullet points (Args, Returns, Raises). Every sentence adds value, though slightly verbose. Could be tightened but overall effective.
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 5 parameters, output schema existence, and sibling tools, the description is complete. Explains return dict structure, error types, and distinguishes from siblings like get_supported_countries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates. It explains each parameter: date format, country case-insensitivity, inclusive default, subdiv case-sensitivity and relation to get_supported_countries. No ambiguity remains.
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: 'Count business days and list weekday holidays between two dates.' It distinguishes itself from sibling tools like is_business_day and list_holidays by combining counting and listing.
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?
Provides explicit use cases: 'measure working-day spans for SLAs, delivery windows, or payroll periods.' It explains what holidays are included/excluded but does not mention when to avoid this tool or suggest alternatives like is_business_day for single date checks.
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 carries full burden for behavioral disclosure. It notes case-sensitivity, return value structure, and raises ValueError for unknown countries. It does not mention performance or rate limits, but for a simple lookup tool, this is largely 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?
The description is well-structured with sections: main purpose, usage guidance, important note, example, formal Args/Returns/Raises. It is concise yet comprehensive, with no redundant sentences.
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 (single parameter, straightforward lookup), the description fully covers purpose, usage, parameter semantics, return format, and error handling. The inline output schema compensates for the missing structured output schema.
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 0%, so description must add meaning. It specifies that `country` is an ISO 3166-1 alpha-2 code, case-insensitive, and normalized to uppercase. This is valuable context beyond the bare schema type.
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 lists subdivision codes and aliases for a country's holiday calendar. It specifies the action (list), resource (subdivision codes/aliases), and scope (per country). It distinguishes from siblings by mentioning its role in discovering valid `subdiv` values for other country-aware holiday tools.
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?
The description explicitly advises using this tool before calling other country-aware tools like `is_business_day`, `list_holidays`, and `next_business_day`. It provides guidance on case sensitivity and normalization of subdivision codes, and includes an example for clarity.
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?
No annotations are provided, so the description fully handles behavioral disclosure. It explains what constitutes a business day (not weekend, not holiday), notes case-sensitivity of subdiv, states that omitting subdiv only considers nation-wide holidays, and mentions that category filtering is not supported. It also lists raised ValueError conditions.
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 front-loaded with the main purpose and structured with Args/Returns/Raises sections. It is reasonably concise, though the subdiv description includes an example that could be slightly shortened. Overall, every sentence earns its place.
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 moderate complexity and missing annotations, the description is complete. It explains all parameters, the return value (dict with specific keys), and error conditions. The output schema exists (implied by the description's Returns section), so no further detail is needed on return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully. It explains the ISO 8601 date format, case-insensitivity of country code, case-sensitivity of subdiv with an example, and the effect of omitting subdiv. This adds meaning far beyond the bare schema types.
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 'Check whether a date is a business day for a given country (optionally a subdivision)' with a specific verb and resource. It distinguishes from sibling tools like 'business_days_between' and 'list_holidays' by focusing on a single date check.
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 when an agent needs to know if a specific calendar date is a working day'. While it doesn't explicitly list alternatives, the context from sibling tool names implies when not to use it (e.g., for date ranges use 'business_days_between').
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?
No annotations are provided, so the description fully carries the burden. It discloses that weekends and public holidays are skipped, that inclusive flag affects whether the start date qualifies, that subdiv filters by region, that ValueError is raised on invalid inputs, and that there's a ~10-year search limit. This is thorough behavioral 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?
The description is well-organized with a clear first sentence, bullet-pointed args, and sections for returns and raises. It is concise without being terse—every sentence adds value. No redundant or extraneous text.
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?
Despite having 4 parameters, 0% schema coverage, and no annotations, the description is complete. It covers input details, behavior, output keys, and error conditions. The output schema exists (not shown but referenced in description), so description doesn't need to detail return values further. It references get_supported_countries for subdiv values, showing awareness of related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so by specifying format for 'date' (ISO 8601), case-insensitive normalization for 'country', behavior of 'inclusive' (True/False default), and 'subdiv' with an example (case-sensitive, optional, region-specific). This adds significant meaning beyond the raw 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 'Return the next business day on/after (inclusive) or strictly after date' and explains it skips weekends and public holidays. It is specific about the resource (business day) and action (return next), and implicitly distinguishes from siblings like is_business_day or previous_business_day.
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 says 'Use this to move forward to the soonest working day', which is a clear usage context. However, it does not explicitly mention when not to use or point to alternatives like is_business_day for checking a specific date. The context signals list sibling tools, but the description itself lacks explicit exclusions.
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?
No annotations provided, so the description carries full burden. It discloses critical behaviors: subdivision codes are case-sensitive and must be used verbatim, country codes are case-insensitive, and subdivisions may be empty for some countries or due to library errors—all beyond basic functionality.
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?
Description is well-structured: first sentence for purpose, then usage guidance, then important behavioral notes, then return format. 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?
Despite no parameters and no annotations, the description is thorough. It explains the return structure (countries list with code, name, subdivisions, total) and addresses edge cases (empty subdivisions, library errors), making it complete for agent interaction.
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?
Tool has zero parameters, so baseline is 4. Description does not need to add parameter info, but it does mention how subdivision codes (from other tools) are used, which is helpful context.
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 'List all countries supported by the holidays library, with subdivisions' with a specific verb and resource. It differentiates from sibling tools (which focus on business days, dates, holidays) by positioning itself as a discovery tool.
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 advises using this tool 'before calling any country-aware tool', and explains that it provides valid ISO codes and subdivision codes for other tools, effectively guiding when and why to use it.
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:

[![business-day-mcp MCP server](https://glama.ai/mcp/servers/fbdo/business-day-mcp/badges/card.svg)](https://glama.ai/mcp/servers/fbdo/business-day-mcp)

Score Badge

Copy to your README.md:

[![business-day-mcp MCP server](https://glama.ai/mcp/servers/fbdo/business-day-mcp/badges/score.svg)](https://glama.ai/mcp/servers/fbdo/business-day-mcp)

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/fbdo/business-day-mcp'

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