Descubra feriados nacionais, estaduais e municipais do Brasil em tempo real. Permite buscar por data, estado, município e verificar se uma data específica é feriado.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 9 of 9 tools scored. Lowest: 3.6/5.
Each tool has a clearly distinct purpose with no ambiguity. For example, 'buscar_feriados' is for general searches with multiple filters, while 'feriados_nacionais' and 'feriados_por_estado' target specific scopes, and 'verificar_data' checks a single date. The descriptions explicitly guide when to use each tool, preventing misselection.
Tool names follow a consistent verb_noun pattern in Portuguese, such as 'buscar_feriados', 'listar_estados', and 'verificar_data'. All names use snake_case and descriptive verbs like 'buscar', 'listar', and 'verificar', making the set predictable and readable.
With 9 tools, the count is well-scoped for the domain of Brazilian holidays. Each tool serves a specific function, from general searches to specialized checks and utility functions like listing states or municipalities, ensuring no tool feels redundant or missing for the server's purpose.
The tool set provides complete coverage for querying Brazilian holidays, including general searches, filters by type, location, and date, as well as utility tools for municipalities and states. It supports full workflows, such as finding IBGE codes before checking city holidays, and includes specialized checks for banking days, leaving no obvious gaps.
buscar_feriadosBuscar FeriadosAInspectBusca 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 |
|---|---|---|---|
| uf | No | Sigla do estado em maiúsculas (ex: SP, RJ, MG) | |
| ano | No | Ano com 4 dígitos (ex: 2026) | |
| date | No | Data no formato YYYY-MM-DD (ex: 2026-12-25) | |
| ibge | No | Código IBGE do município (ex: 3550308 para São Paulo) | |
| type | No | Tipo do feriado | |
| 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context by stating the return format: 'Retorna lista paginada de feriados com nome, data (DD/MM/YYYY), tipo, descrição e indicador bancário (FEBRABAN)' (returns paginated list of holidays with name, date, type, description, and FEBRABAN bank indicator). However, it does not disclose potential error behavior, auth requirements, or the mechanics of pagination (e.g., page parameters). Still, it goes beyond the schema by revealing the output structure.
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 compact and front-loaded, leading with the core purpose in the first sentence. It avoids restating the schema in full, instead providing a high-level overview and then directing users to specialized tools. Every sentence earns its place, and the length is ideal for a query tool with multiple filters.
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 has 7 parameters, no required fields, and no output schema, the description provides a solid overview of both input and output. It explains the return fields (name, date, type, description, FEBRABAN indicator), pagination, and where it fits relative to sibling tools. It lacks explicit mention of pagination controls or common error conditions, but for a general-purpose search tool, it covers the essential context needed for an AI agent to select and invoke it correctly.
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 schema description coverage is 100%, so the baseline is 3. The description adds a small amount of value by summarizing filterable attributes ('Pode filtrar por data, tipo, estado (UF), cidade (código IBGE), ano e mês'), which helps users parse which parameters are relevant. However, it does not add meaning beyond the schema's already-detailed property descriptions, such as the relationship between month and ano (which is already in the schema). Therefore, a 3 is appropriate.
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's purpose: 'Busca feriados brasileiros com filtros flexíveis' (searches Brazilian holidays with flexible filters). It also explicitly distinguishes itself from specialized siblings by noting that for more specific searches, specialized tools like feriados_nacionais and feriados_por_estado should be preferred. This prevents ambiguity.
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 states when to use this tool: 'Use esta tool para consultas gerais quando precisar filtrar por múltiplos critérios ao mesmo tempo' (use for general queries when filtering by multiple criteria at once). It also provides clear alternatives: 'Para buscas mais específicas, prefira usar as tools especializadas' (for more specific searches, prefer the specialized tools). This contrasts with sibling tools and offers actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
buscar_municipiosBuscar MunicípiosAInspectBusca 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?
Não há annotations, então a descrição assume o papel de transparência. Ela detalha o que é retornado, a possibilidade de filtro por UF e o alerta sobre mais de 5.500 municípios. Não menciona paginação explicitamente, mas o schema cobre esse aspecto.
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?
Quatro frases objetivas, com a informação principal no início e sem redundâncias. Cada frase contribui com um aspecto relevante: o que faz, o que retorna, quando usar e como usar eficientemente.
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?
Não há output schema, mas a descrição informa os campos retornados e o caso de uso. A paginação e limites estão cobertos pelo input schema, o que torna a ferramenta suficientemente completa para uma listagem simples.
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?
O schema cobre 100% dos parâmetros, então a baseline é 3. A descrição adiciona valor além do schema ao contextualizar o filtro por UF como forma de obter resultados mais precisos e ao conectar a ferramenta ao fluxo de feriados municipais.
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 usa verbo específico ('Busca') e recurso claro ('municípios brasileiros por estado'), informando o retorno (nome, UF, código IBGE). Isso a diferencia dos tools irmãos focados em feriados e estados.
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?
Orienta explicitamente quando usar: para descobrir o código IBGE antes de consultar 'feriados_por_cidade'. Também recomenda filtrar por UF devido ao grande volume de municípios, indicando uma alternativa prática e melhorando a precisão.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
feriados_bancariosFeriados Bancários (FEBRABAN)AInspectLista 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 |
|---|---|---|---|
| uf | No | Sigla do estado para incluir feriados estaduais bancários (ex: SP) | |
| ano | No | Ano com 4 dígitos (ex: 2026) | |
| 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 carries the full transparency burden. It discloses the source (Resolução 4.880/2020 do CMN), the included categories (national + facultative), and explicitly lists which facultative dates are covered (Carnaval, Quarta-feira de Cinzas, etc.). It also explains the effect of filtering by UF/IBGE. However, it does not mention default behavior when no filters or year are provided, or output 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?
The description is four sentences, each serving a clear purpose: core function, included dates, use case, and filtering capability. It is front-loaded and contains no filler, making it easy to scan.
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 listing tool with 4 optional parameters and no output schema, the description provides a good overview: it explains the data source, coverage, and filtering options. It could be more complete by clarifying whether 'ano' is required or defaults to the current year, but the overall picture is solid.
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 each parameter already has a description. The tool description adds value by explaining the purpose of the UF/IBGE filters ('para incluir feriados bancários estaduais/municipais') and defining what 'facultativos' means in the context of the FEBRABAN calendar. This goes beyond the schema's basic field 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 the tool's function with a specific verb ('Lista') and resource ('todos os feriados bancários do calendário oficial FEBRABAN'). It distinguishes from sibling tools by specifying 'bancários' and citing the official FEBRABAN resolution, making it clear this is the banking-specific holiday list, not generic 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?
The description provides explicit usage context: 'Ideal para cálculos de vencimentos, compensações e prazos bancários.' It also explains when to use the filtering options ('Pode filtrar por estado...'). However, it does not explicitly name alternatives or state when not to use this tool, leaving some room for ambiguity among the sibling holiday tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
feriados_nacionaisFeriados NacionaisAInspectLista 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. | |
| bancarios | No | Se true, retorna apenas feriados bancários (calendário FEBRABAN) | |
| facultativos | No | Se true, inclui feriados facultativos nacionais (ex: Carnaval, Corpus Christi) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It goes beyond a simple statement by listing included holidays (Carnaval, Sexta-feira Santa, etc.) and notes that facultativos can be optionally included. It also clarifies the default year behavior. However, it does not describe output format or mention the 'bancarios' parameter's effect (only banking holidays), which is a notable behavioral trait.
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 (three sentences) and front-loaded with the main action. It efficiently packs the scope, examples, optional behavior, and default handling without unnecessary filler. Every sentence contributes useful 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 tool has 3 optional parameters, no required parameters, no output schema, and no annotations. The description covers the main purpose, default behavior, and optional facultativos. However, it omits any mention of the 'bancarios' parameter, which is an important behavior (restricting to banking holidays) and could confuse users given the sibling tool 'feriados_bancarios'. This gap prevents a perfect completeness score, but overall the description is adequate.
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%, with well-described parameters for 'ano', 'bancarios', and 'facultativos'. The description adds minimal extra meaning beyond the schema, such as explicit examples of facultativos (Ponto Facultativo) and the default with omitted year. Since the schema already handles parameter semantics, the baseline 3 applies with only slight additions.
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 verb 'Lista' and the specific resource 'todos os feriados nacionais do Brasil para um ano específico', with a scope for year and optional filtering. It distinguishes from sibling tools by explicitly focusing on national holidays, which is unique among tools like feriados_por_cidade, feriados_por_estado, and feriados_bancarios.
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 clear context on when to use the tool: for listing national holidays of Brazil, with an optional inclusion of facultativos. It explains default behavior (if no year is provided, returns all available years) and mentions the optional 'facultativos' parameter. However, it does not explicitly mention alternatives or when not to use this tool, such as for state/city holidays, which are covered by siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
feriados_por_cidadeFeriados por CidadeAInspectLista 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 |
|---|---|---|---|
| ano | No | Ano com 4 dígitos (ex: 2026) | |
| ibge | Yes | Código IBGE do município (ex: 3550308 para São Paulo). Use 'buscar_municipios' se não souber o código. | |
| bancarios | No | Se true, retorna apenas feriados bancários (calendário FEBRABAN) | |
| facultativos | No | Se true, inclui feriados facultativos |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the operation (lists holidays) and requires the IBGE code, but does not disclose return format, error handling, default behavior for optional parameters, or any limitations (e.g., valid years). It adds some context with examples but lacks richer behavioral details for a tool with no structured annotations.
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 and well-structured: a clear first sentence stating purpose, a usage trigger, a requirement note with an alternative tool, and concrete examples. Every sentence earns its place, with no fluff or repetition.
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 tool is a simple list operation with 4 parameters and no output schema. The description adequately covers the main purpose, usage context, and prerequisite (IBGE code). However, it does not describe the output structure or default behavior (e.g., year default), which would be helpful given the absence of an output schema, but this is a minor gap for a straightforward list 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 the baseline is 3. The description adds value beyond the schema by providing concrete IBGE code examples for major cities and reiterating the need to use 'buscar_municipios' when the code is unknown. This reinforces the 'ibge' parameter semantics, though it does not add much for 'ano', 'bancarios', or 'facultativos'.
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 a specific verb and resource: 'Lista todos os feriados de uma cidade brasileira' (lists all holidays of a Brazilian city). It distinguishes this tool from siblings by specifying the scope (city-level, including national, state, and municipal holidays) and by providing usage context for city-specific 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?
It explicitly says when to use this tool: 'Use quando o usuário perguntar sobre feriados em uma cidade específica.' It also gives a clear alternative workflow: if the IBGE code is unknown, use 'buscar_municipios' first. However, it does not explicitly contrast with sibling tools like 'feriados_nacionais' or 'feriados_por_estado', so it lacks a full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
feriados_por_estadoFeriados por EstadoAInspectLista 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) | |
| bancarios | No | Se true, retorna apenas feriados bancários (calendário FEBRABAN) | |
| facultativos | No | Se true, inclui feriados facultativos do estado |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds the behavioral detail that the result includes national plus state holidays for the given UF, which is useful. However, it does not disclose any side effects, prerequisites, default behavior (e.g., if ano is omitted), or output format, leaving some gaps for a listing 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 three sentences: the action, the usage instruction, and the acronym list. It is front-loaded with the core purpose, contains no redundant information, and every sentence earns its place. The UF list, while long, is necessary for correct parameter use and is compactly formatted.
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 essential purpose and usage context, while the schema provides comprehensive parameter details (100% coverage). However, without an output schema, the description does not describe the return structure, and it doesn't mention parameter interactions beyond what the schema provides, which would be helpful for a 4-parameter tool. Overall, it is sufficient for a straightforward 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 description coverage is 100%, so the baseline is 3. The description adds a complete enumeration of valid UF acronyms ('AC, AL, AP, AM, BA...'), which goes beyond the schema's example-based description and directly aids the agent in selecting valid values for the required 'uf' 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's action and resource: 'Lista todos os feriados de um estado brasileiro (feriados nacionais + estaduais daquele UF)'. This specifies a specific verb ('Lista'), a resource ('feriados de um estado'), and scope ('nacionais + estaduais'), clearly distinguishing it from sibling tools like feriados_nacionais and feriados_por_cidade.
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 instructs when to use the tool: 'Use quando o usuário perguntar sobre feriados em um estado específico', with concrete examples like 'feriados em São Paulo'. It does not mention exclusions or alternative tools, but the clear context is sufficient to avoid confusion with national or city-specific holiday tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
listar_estadosListar Estados do BrasilAInspectLista 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?
With no annotations provided, the description carries the full burden. It conveys that the tool is a read-only listing operation (via 'Lista') and discloses exactly what it returns (sigla UF and full name). While it doesn't discuss rate limits or side effects, for a simple constant-data tool, this is sufficient context.
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 short sentences, front-loaded with the core action in the first sentence, followed by usage guidance and output details. Every sentence contributes value, with no redundancy 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?
For a tool with no parameters and no output schema, the description is fully complete: it states the exact scope (27 states), the output fields (UF and name), and usage criteria. No additional context is needed.
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 tool has zero parameters, so the baseline is 4 per the rubric. The description doesn't need to elaborate on parameters, and it doesn't.
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 all 27 Brazilian states with their UF abbreviations, using a specific verb ('Lista') and resource ('estados brasileiros'). This fully distinguishes it from the sibling tools, which are all holiday- or municipality-related.
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 clearly says when to use the tool ('Use quando precisar consultar as siglas dos estados ou quando o usuário perguntar quais são os estados do Brasil'), which is explicit guidance. However, it does not mention when not to use it or alternatives, though the sibling tools make this obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verificar_dataVerificar se Data é FeriadoAInspectVerifica 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully explains that the tool returns all holidays on the specified date, may return multiple entries (e.g., national + municipal), and that an empty list means the date is not a holiday. This goes beyond the schema.
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 and well-structured, consisting of three sentences that are front-loaded with the tool's purpose. Every sentence adds value without redundancy.
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 simple one-parameter tool with no output schema, the description covers core behavior, return semantics, and gives usage examples. It could mention error handling for invalid dates, but it is otherwise sufficiently complete for an AI agent to use correctly.
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 schema already fully documents the 'data' parameter with format and example (100% coverage). The description adds no additional parameter-specific meaning, so the baseline score of 3 applies.
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 specific verb 'Verifica' and identifies the resource as holidays in Brazil. It clearly states the tool checks a specific date and distinguishes itself from sibling tools that list holidays by category or region.
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 clear usage context with example user queries, such as 'amanhã é feriado?' and '25 de dezembro é feriado?'. It doesn't explicitly contrast with alternative tools or state when not to use, but the context strongly implies it's for single-date verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verificar_dia_util_bancarioVerificar Dia Útil BancárioAInspectVerifica 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?
With no annotations provided, the description carries the full burden. It discloses that non-business days return a reason (feriado bancário or fim de semana) and the next business day. It also specifies the FEBRABAN calendar and mentions specific holidays considered, adding valuable behavioral context beyond the schema.
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 four sentences, with the primary purpose in the first sentence. Each sentence adds value: usage examples, return behavior, and calendar details. There is no wasted wording, and it is well-structured for quick comprehension.
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?
Considering the simple single-parameter tool with no output schema, the description provides enough context for an agent to select and invoke it correctly. It explains the input semantics, the business context, expected output behavior, and the calendar source. Minor gaps like exact return format do not hinder use.
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 description coverage is 100% because the only parameter 'data' has its format and example described. The tool description adds context for when to use the date but does not add new parameter-level semantics, which is fine given the high schema coverage. Baseline 3 is appropriate.
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 specific verb ('Verifica') and a clear resource ('se uma data é dia útil bancário'), specifying that agencies open normally. It clearly distinguishes itself from sibling tools like feriados_bancarios and verificar_data by focusing on banking business days and providing the next business day if not.
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 gives example user queries ('o banco abre amanhã?', 'quando vence o boleto?') and states 'Use quando...'. While it doesn't name alternative tools to avoid, the usage context is unambiguous. Exclusions are not mentioned but are not necessary given the specificity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
