feriadosapi

Server Quality Checklist

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

Latest release: v1.0.17
Disambiguation3/5
The tools have significant overlap, especially between 'buscar_feriados' and the specialized holiday tools (e.g., 'feriados_nacionais', 'feriados_por_estado'). While descriptions advise using specialized tools for specific queries, naming alone does not clearly distinguish purposes, potentially causing misselection.
Naming Consistency4/5
All tool names use snake_case, but they mix verb-initial patterns (e.g., 'buscar_feriados', 'listar_estados') with noun-initial patterns (e.g., 'feriados_nacionais', 'feriados_bancarios'). This slight inconsistency is noticeable but not chaotic.
Tool Count5/5
With 9 tools, the server covers the core operations for Brazilian holiday data: general search, specific location/type queries, and date/business day checks. This is a well-scoped count for a focused domain.
Completeness4/5
The tool surface covers most common holiday queries (national, state, city, bank holidays, date checking). A minor gap is the lack of a direct 'next holiday' tool, but 'verificar_dia_util_bancario' partially addresses this for banking days.
Average 4.3/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 1, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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?
No annotations provided, so description carries full burden. It mentions included holidays and optional facultative inclusion, but does not disclose data source, year availability, ordering, error behavior, or return format.
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 compact and front-loaded with the main purpose, comprising three clear sentences with no unnecessary 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?
Covers main functional aspects (scope, filters, default year behavior). Lacks explanation of output format or structure, which is acceptable given no output schema, but could mention if results are sorted or paged.
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?
Input schema has 100% coverage, so baseline is 3. Description rephrases schema information but does not add significant new meaning beyond listing example holidays and clarifying contextual use.
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 lists all Brazilian national holidays for a specific year, lists example holidays, and distinguishes from sibling tools by specifying 'nacionais' and optional parameters.
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 clear context for using the tool (specific year, optional facultativos and bancarios parameters, default behavior when no year is given). However, does not explicitly compare with sibling tools like feriados_por_cidade or feriados_por_estado.
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 exist, so the description must provide behavioral context. It describes the tool as listing (read operation), but does not disclose behavior for invalid inputs, return format, or performance implications. This is adequate but minimal.
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?
Three sentences, front-loaded with the main purpose, no redundant words. Every sentence adds value: purpose, usage guidance, and list of UFs.
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 description covers the tool's scope and all input parameters. There is no output schema, but the return type (list of holidays) is evident from the purpose. It is complete for a simple listing 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 baseline is 3. The description provides the full list of UFs and explains 'ano' as a 4-digit year, but the schema already specifies minLength/maxLength. It does not add significant semantics 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 lists all holidays (national + state) for a Brazilian state, which is specific and clear. It distinguishes itself from sibling tools that focus on national, city, or bank holidays.
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?
It explicitly says to use when the user asks about holidays in a specific state and gives examples. It also lists all state abbreviations, providing clear context. It does not explicitly mention when not to use, but sibling names imply alternatives.
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 adequately describes what the tool returns (list of bank holidays, including facultative ones) and filtering capabilities. However, it does not disclose all behavioral traits such as default behavior when no parameters are provided, or response format, which are missing.
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 informative paragraph that covers key aspects without redundancy. It could be slightly more structured (e.g., bullet points) but effectively communicates the tool's purpose and options in a compact form.
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 parameter count, full schema coverage, and no output schema, the description provides sufficient context for understanding the tool. It explains the special holidays, filtering, and intended use, though some details like default year or response format are absent.
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 the context of each parameter (e.g., UF for state holidays, facultativos for voluntary days) and linking to the FEBRABAN standard, which enriches understanding beyond schema metadata.
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 lists bank holidays from the official FEBRABAN calendar, including specific facultative dates. It clearly distinguishes from siblings like 'feriados_nacionais' by focusing on banking holidays, making the purpose unmistakable.
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 context on ideal use cases (e.g., calculations for due dates, compensations) and mentions filtering options. While it does not explicitly state when not to use or list alternatives, the context and sibling names imply the distinction from general holiday tools.
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?
Sem anotações, a descrição informa que retorna dados paginados (via page e limit) e descreve o conteúdo do retorno (nome, UF, código IBGE). Menciona a natureza de busca, sem efeitos colaterais. Cumpre bem o papel de descrever o comportamento.
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?
A descrição tem apenas algumas frases, diretas e sem informações redundantes. O propósito principal é apresentado no início, e cada frase agrega valor (uso, filtro, paginação). Muito concisa e bem estruturada.
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?
Para uma ferramenta simples de busca, a descrição cobre o que retorna, como usar, e menciona paginação e conexão com ferramenta irmã. Não possui schema de saída, mas a descrição do retorno é suficiente. Ligeiramente incompleta por não especificar ordenação, mas aceitável.
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?
A cobertura do esquema é de 100% (todos os parâmetros têm descrição no schema). A descrição apenas reforça o uso do parâmetro 'uf' ('Pode filtrar por UF...') e não adiciona significado substancial além do schema. Baseline 3 é adequado.
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?
A descrição afirma claramente que a ferramenta busca municípios brasileiros por estado, retornando nome, UF e código IBGE. Isso é específico e distingue-se de ferramentas irmãs como 'feriados_por_cidade', mencionando seu uso para obter o código IBGE antes de consultar feriados municipais.
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?
Instrui quando usar a ferramenta (para descobrir código IBGE antes de 'feriados_por_cidade') e dá orientações sobre filtrar por UF para resultados mais precisos, especialmente mencionando que o Brasil tem mais de 5.500 municípios. Não compara explicitamente com outras ferramentas irmãs, mas o contexto é claro.
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 must disclose behavior. It states that the tool returns sigla (UF) and nome completo for each state, which is sufficient for a simple read-only operation. No hidden side effects.
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 short, focused sentences with no redundant information. Immediately states what the tool does and when to use it.
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?
For a parameterless tool with no output schema, the description fully covers purpose, usage, and return content. No gaps for an agent to misunderstand.
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?
No parameters exist, schema coverage is 100%. Description adds no parameter-specific info, which is acceptable given the absence of parameters.
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 uses a clear verb 'listar' and resource 'estados', specifies scope (all 27 including Distrito Federal), and naturally distinguishes from sibling tools which focus on holidays and municipalities.
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?
Explicitly states when to use it: for state UF lookup or when a user asks 'which are the states of Brazil'. Does not explicitly exclude alternatives, but context with siblings makes it clear.
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?
The description implies a read-only search operation ('Busca'), but without annotations, it does not explicitly state non-destructive behavior, authentication needs, or other side effects. However, the nature of search and pagination return is disclosed, which is adequate for a query tool.
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 (4 sentences), front-loads the main purpose, and efficiently lists filters and return fields without redundant or irrelevant 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?
The description covers the tool's flexibility, return fields (name, date, type, description, Febraban indicator), and pagination. It lacks details on pagination mechanics and error handling, but given the lack of output schema, it provides sufficient context for an agent to use the tool effectively.
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 input schema has 100% description coverage, so the description adds no new meaning beyond listing parameters and their types. It repeats information already in the schema, consistent with the baseline for high coverage.
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 searches Brazilian holidays with flexible filters. It distinguishes itself from sibling tools by mentioning specialized alternatives, making the purpose unambiguous.
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 to use this tool for general queries with multiple criteria and to prefer specialized tools (e.g., feriados_nacionais) for specific searches, providing clear when-to-use and when-not-to-use guidance.
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 discloses that the tool combines national, state, and municipal holidays, requires IBGE code, and gives example codes. However, it does not mention error handling for invalid codes or missing data.
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?
Three efficient sentences: purpose, usage guidance, and requirement with examples. No extraneous 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?
No output schema exists, so description should indicate return format. It states 'Lista todos os feriados' but does not describe structure. Still, the purpose is clear and the required parameter is well-documented.
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 adds context with IBGE code examples and overall purpose but does not significantly enhance parameter understanding beyond the schema 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 it lists all holidays (national, state, municipal) for a Brazilian city, using a specific verb and resource. It distinguishes from siblings like 'feriados_nacionais' and 'feriados_por_estado'.
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 says 'Use quando o usuário perguntar sobre feriados em uma cidade específica' and provides fallback instruction to use 'buscar_municipios' if the IBGE code is unknown.
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 full behavioral disclosure. It explains that multiple holidays may be returned (national + municipal) and that an empty list means the date is not a holiday. It does not cover error handling or authentication, but for a simple read-only check, this is adequate.
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 three sentences with a clear, front-loaded structure: first sentence states purpose, second gives usage examples, third explains return behavior. No redundant words, every sentence adds value.
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, no output schema, no nested objects), the description fully covers its purpose, input format, and output interpretation. It explains edge cases like multiple holidays and empty result meaning. No gaps.
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?
The input schema has 100% coverage with a clear description for the single parameter. The tool description adds Brazilian holiday context and examples of expected input formats, reinforcing the schema and making the parameter's purpose more concrete.
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 specific date is a holiday in Brazil, with examples of natural language queries. It distinguishes itself from sibling tools by focusing on a single date verification, not bulk listing or region-based queries.
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 examples like 'amanhã é feriado?' and '25 de dezembro é feriado?', but does not contrast with sibling tools or specify when to avoid using it. The context is clear enough, but missing explicit 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, the description discloses return behavior (reason and next business day) and the calendar source (FEBRABAN with specific holidays). It could mention side effects or idempotency, but the core behavior is clear.
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 three sentences, front-loaded with purpose, then usage examples, then behavioral details. No redundant language.
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?
For a single-parameter tool with no output schema and no annotations, the description covers purpose, usage, behavioral details, and calendar specifics. It is complete for an agent to decide when and how to use it.
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 does not add extra semantics beyond the schema's format and example for the 'data' parameter.
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 bank business day, with a specific verb 'verifica' and resource 'dia útil bancário'. It distinguishes from siblings like 'verificar_data' (generic) and 'feriados_bancarios' (holiday list) by focusing on business day status.
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 provides explicit example queries ('o banco abre amanhã?') and implies when to use. It also indicates what the tool does if the date is not a business day, offering guidance on behavior and 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:

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

Score Badge

Copy to your README.md:

[![feriadosapi-mcp MCP server](https://glama.ai/mcp/servers/feriadosapi/feriadosapi-mcp/badges/score.svg)](https://glama.ai/mcp/servers/feriadosapi/feriadosapi-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/feriadosapi/feriadosapi-mcp'

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