This server allows you to query Brazilian holidays (national, state, and municipal) in your AI agent using the Model Context Protocol (MCP).
Search holidays with flexible filters (buscar_feriados): Query by date, type (national/state/municipal/facultative), state (UF), city (IBGE code), year, and/or month.
List national holidays (feriados_nacionais): Retrieve all Brazilian national holidays for a specific year or all years, with optional facultative holidays.
List holidays by state (feriados_por_estado): Get all national + state-level holidays for a specific Brazilian state using its 2-letter UF code.
List holidays by city (feriados_por_cidade): Get all national + state + municipal holidays for a specific city using its IBGE code.
Check if a date is a holiday (verificar_data): Verify whether a specific date (YYYY-MM-DD) is a holiday in Brazil.
List all Brazilian states (listar_estados): Retrieve all 27 Brazilian states (26 states + Federal District) with their UF codes and full names.
Search municipalities (buscar_municipios): Find Brazilian municipalities by state (UF), returning their names and IBGE codes — useful before querying city-specific holidays.
Consulte feriados brasileiros (nacionais, estaduais e municipais) direto no seu agente de IA favorito usando o Model Context Protocol.
Adicione ao seu cliente de IA:
https://mcp.feriadosapi.com/api/mcpCom sua própria API key (BYOK):
https://mcp.feriadosapi.com/api/mcp?apiKey=fapi_sua_chave_aqui💡 Crie uma conta gratuita em feriadosapi.com para obter sua API key — acesso ilimitado a feriados nacionais, estaduais e capitais (60 req/min).
Obtenha uma API key gratuita em feriadosapi.com e configure:
{
"mcpServers": {
"feriadosapi": {
"command": "npx",
"args": ["-y", "@feriados-api/mcp-server"],
"env": {
"FERIADOS_API_KEY": "fapi_sua_chave_aqui"
}
}
}
}Related MCP server: PH Holidays MCP
Ferramenta | Descrição |
| Busca com filtros flexíveis (data, tipo, UF, IBGE, ano, mês) |
| Feriados nacionais do Brasil |
| Feriados por estado (UF) |
| Feriados por cidade (código IBGE) |
| Verifica se uma data é feriado |
| Feriados bancários do calendário FEBRABAN |
| Verifica se uma data é dia útil bancário |
| Lista estados brasileiros |
| Busca municípios por UF |
{
"mcpServers": {
"feriadosapi": {
"command": "npx",
"args": ["-y", "@feriados-api/mcp-server"],
"env": {
"FERIADOS_API_KEY": "fapi_sua_chave_aqui"
}
}
}
}// .cursor/mcp.json
{
"mcpServers": {
"feriadosapi": {
"command": "npx",
"args": ["-y", "@feriados-api/mcp-server"],
"env": {
"FERIADOS_API_KEY": "fapi_sua_chave_aqui"
}
}
}
}// Configuração do GitHub Copilot MCP
{
"github.copilot.mcp.servers": {
"feriadosapi": {
"command": "npx",
"args": ["-y", "@feriados-api/mcp-server"],
"env": {
"FERIADOS_API_KEY": "fapi_sua_chave_aqui"
}
}
}
}// ~/.codeium/windsurf/mcp_config.json
{
"mcpServers": {
"feriadosapi": {
"command": "npx",
"args": ["-y", "@feriados-api/mcp-server"],
"env": {
"FERIADOS_API_KEY": "fapi_sua_chave_aqui"
}
}
}
}// .gemini/settings.json
{
"mcpServers": {
"feriadosapi": {
"command": "npx",
"args": ["-y", "@feriados-api/mcp-server"],
"env": {
"FERIADOS_API_KEY": "fapi_sua_chave_aqui"
}
}
}
}// ~/.gemini/settings.json
{
"mcpServers": {
"feriadosapi": {
"command": "npx",
"args": ["-y", "@feriados-api/mcp-server"],
"env": {
"FERIADOS_API_KEY": "fapi_sua_chave_aqui"
}
}
}
}// ~/.codex/config.json
{
"mcpServers": {
"feriadosapi": {
"command": "npx",
"args": ["-y", "@feriados-api/mcp-server"],
"env": {
"FERIADOS_API_KEY": "fapi_sua_chave_aqui"
}
}
}
}URL: https://mcp.feriadosapi.com/api/mcp?apiKey=SUA_API_KEYApós configurar, pergunte ao seu agente:
"Quais são os feriados de São Paulo em 2026?"
"Amanhã é feriado?"
"Quando é o Carnaval?"
"Quais feriados caem na sexta-feira em 2026?"
"Qual o código IBGE de Curitiba?"
Uma API key é obrigatória. Crie uma conta gratuita em feriadosapi.com (acesso ilimitado, 60 req/min) e passe sua chave:
Via URL remota: ?apiKey=fapi_xxx na URL do MCP
Via stdio (local): env var FERIADOS_API_KEY
⚠️ Sem uma API key válida, todas as chamadas retornarão erro de autenticação.
# Clonar o repositório
git clone https://github.com/feriadosapi/feriadosapi-mcp.git
cd feriadosapi-mcp
# Instalar dependências
npm install
# Configurar variáveis de ambiente
cp .env.example .env.local
# Editar .env.local com sua FERIADOS_API_KEY
# Rodar em desenvolvimento
npm run dev
# Build do stdio (para publicação npm)
npm run build:stdioMIT
Busca feriados brasileiros com filtros flexíveis. Use esta tool para consultas gerais quando precisar filtrar por múltiplos critérios ao mesmo tempo. Pode filtrar por data, tipo (NACIONAL/ESTADUAL/MUNICIPAL/FACULTATIVO), estado (UF), cidade (código IBGE), ano e mês. Para buscas mais específicas, prefira usar as tools especializadas (feriados_nacionais, feriados_por_estado, etc.). Retorna lista paginada de feriados com nome, data (DD/MM/YYYY), tipo, descrição e indicador bancário (FEBRABAN).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Data no formato YYYY-MM-DD (ex: 2026-12-25) | |
| type | No | Tipo do feriado | |
| uf | No | Sigla do estado em maiúsculas (ex: SP, RJ, MG) | |
| ibge | No | Código IBGE do município (ex: 3550308 para São Paulo) | |
| ano | No | Ano com 4 dígitos (ex: 2026) | |
| month | No | Mês de 1 a 12 (requer que 'ano' também seja informado) | |
| bancarios | No | Se true, retorna apenas feriados bancários (calendário FEBRABAN) |
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.
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.
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.
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.
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.
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.
Busca municípios brasileiros por estado. Retorna nome, UF e código IBGE de cada município. Use esta tool para descobrir o código IBGE de uma cidade antes de consultar feriados municipais com 'feriados_por_cidade'. Pode filtrar por UF para listar apenas municípios de um estado. O Brasil possui mais de 5.500 municípios; use o filtro de UF para resultados mais precisos.
| Name | Required | Description | Default |
|---|---|---|---|
| uf | No | Sigla do estado para filtrar (ex: SP, RJ). Se omitido, retorna todos os municípios paginados. | |
| page | No | Número da página (default: 1) | |
| limit | No | Itens por página (default: 50, max: 100) |
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.
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.
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.
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.
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.
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.
Lista todos os feriados bancários do calendário oficial FEBRABAN (Resolução 4.880/2020 do CMN). Inclui feriados nacionais + datas facultativas em que agências bancárias não funcionam: Carnaval (seg/ter), Quarta-feira de Cinzas, Corpus Christi e Véspera de Ano Novo (31/dez). Ideal para cálculos de vencimentos, compensações e prazos bancários. Pode filtrar por estado (UF) ou município (IBGE) para incluir feriados bancários estaduais/municipais.
| Name | Required | Description | Default |
|---|---|---|---|
| ano | No | Ano com 4 dígitos (ex: 2026) | |
| uf | No | Sigla do estado para incluir feriados estaduais bancários (ex: SP) | |
| ibge | No | Código IBGE do município para incluir feriados municipais bancários | |
| facultativos | No | Se true, inclui feriados facultativos bancários |
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.
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.
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.
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.
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.
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.
Lista todos os feriados nacionais do Brasil para um ano específico. Inclui feriados como Carnaval, Sexta-feira Santa, Tiradentes, Dia do Trabalho, Independência, Nossa Senhora Aparecida, Finados, Proclamação da República e Natal. Opcionalmente pode incluir feriados facultativos nacionais (Ponto Facultativo). Se nenhum ano for informado, retorna feriados de todos os anos disponíveis.
| Name | Required | Description | Default |
|---|---|---|---|
| ano | No | Ano com 4 dígitos (ex: 2026). Se omitido, retorna todos os anos. | |
| facultativos | No | Se true, inclui feriados facultativos nacionais (ex: Carnaval, Corpus Christi) | |
| bancarios | No | Se true, retorna apenas feriados bancários (calendário FEBRABAN) |
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.
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.
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.
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.
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.
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.
Lista todos os feriados de uma cidade brasileira (feriados nacionais + estaduais + municipais). Use quando o usuário perguntar sobre feriados em uma cidade específica. Requer o código IBGE do município. Se não souber o código IBGE, use primeiro a tool 'buscar_municipios' para encontrá-lo. Exemplos de códigos IBGE: São Paulo = 3550308, Rio de Janeiro = 3304557, Belo Horizonte = 3106200, Brasília = 5300108.
| Name | Required | Description | Default |
|---|---|---|---|
| ibge | Yes | Código IBGE do município (ex: 3550308 para São Paulo). Use 'buscar_municipios' se não souber o código. | |
| ano | No | Ano com 4 dígitos (ex: 2026) | |
| facultativos | No | Se true, inclui feriados facultativos | |
| bancarios | No | Se true, retorna apenas feriados bancários (calendário FEBRABAN) |
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.
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.
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.
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.
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.
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.
Lista todos os feriados de um estado brasileiro (feriados nacionais + estaduais daquele UF). Use quando o usuário perguntar sobre feriados em um estado específico, como "feriados em São Paulo" ou "feriados do RJ". As siglas dos estados (UF) são: AC, AL, AP, AM, BA, CE, DF, ES, GO, MA, MT, MS, MG, PA, PB, PR, PE, PI, RJ, RN, RS, RO, RR, SC, SP, SE, TO.
| Name | Required | Description | Default |
|---|---|---|---|
| uf | Yes | Sigla do estado em maiúsculas (ex: SP, RJ, MG, BA) | |
| ano | No | Ano com 4 dígitos (ex: 2026) | |
| facultativos | No | Se true, inclui feriados facultativos do estado | |
| bancarios | No | Se true, retorna apenas feriados bancários (calendário FEBRABAN) |
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.
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.
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.
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.
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.
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.
Lista todos os 27 estados brasileiros (26 estados + Distrito Federal) com suas siglas UF. Use quando precisar consultar as siglas dos estados ou quando o usuário perguntar "quais são os estados do Brasil". Retorna sigla (UF) e nome completo de cada estado.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Verifica se uma data específica é feriado no Brasil. Use quando o usuário perguntar algo como "amanhã é feriado?", "25 de dezembro é feriado?", ou "segunda-feira vai ser feriado?". Retorna todos os feriados que caem naquela data (pode ter mais de um: nacional + municipal, por exemplo). Se retornar lista vazia, a data NÃO é feriado.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Data no formato YYYY-MM-DD (ex: 2026-12-25) |
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.
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.
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.
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.
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.
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.
Verifica se uma data é dia útil bancário (agências abrem normalmente). Use quando o usuário perguntar "o banco abre amanhã?", "quando vence o boleto?", "qual o próximo dia útil bancário?". Se não for dia útil, retorna o motivo (feriado bancário ou fim de semana) e o próximo dia útil bancário. Considera o calendário oficial FEBRABAN incluindo Carnaval, Quarta de Cinzas, Corpus Christi e 31/dez.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Data no formato YYYY-MM-DD (ex: 2026-02-16) |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.17buscar_feriados1 field changedInput schema / properties / bancariosAdded value: +{
+ "description": "Se true, retorna apenas feriados bancários (calendário FEBRABAN)",
+ "type": "boolean"
+}feriados_bancariosferiados_nacionais1 field changedInput schema / properties / bancariosAdded value: +{
+ "description": "Se true, retorna apenas feriados bancários (calendário FEBRABAN)",
+ "type": "boolean"
+}feriados_por_cidade1 field changedInput schema / properties / bancariosAdded value: +{
+ "description": "Se true, retorna apenas feriados bancários (calendário FEBRABAN)",
+ "type": "boolean"
+}feriados_por_estado1 field changedInput schema / properties / bancariosAdded value: +{
+ "description": "Se true, retorna apenas feriados bancários (calendário FEBRABAN)",
+ "type": "boolean"
+}verificar_dia_util_bancariobuscar_feriadosbuscar_municipiosferiados_nacionaisferiados_por_cidadeferiados_por_estadolistar_estadosverificar_dataScored across 9 tools
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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Free, keyless public holidays lookup for any country and year, plus single-date holiday checks.
Public holiday data for 30+ countries. Check holidays, working days and calendars via AI assistants.
Public holidays for 100+ countries — by year, or the next ones coming up. Via Nager.Date.
Real public holiday lookup for 206 countries via a rule-based calendar engine. Paid via x402.
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
