Skip to main content
Glama

Días hábiles en Colombia entre fechas

co-business-days-between
Read-onlyIdempotent

Cuenta días hábiles entre dos fechas en Colombia, excluyendo domingos, sábados (opcional) y festivos nacionales. Cuándo: hay que aplicar con exactitud una regla colombiana (DIAN, festivos de la Ley Emiliani, montos en COP, IVA, GMF, UVT), p. ej. al facturar o cobrar. No para: contar días hábiles entre dos fechas, excluyendo fines de semana configurables y festivos (business-days-between). Efectos secundarios: ninguno (solo lectura, sin red, sin estado guardado). Determinista: la misma entrada da la misma salida. Límites: entrada JSON de hasta 64 KB, 1 s por llamada, resultado de hasta 1 MB.

EN: Counts business days (días hábiles) between two dates in Colombia, excluding Sundays, Saturdays (unless saturday_is_business) and national holidays; lists holidays skipped. When: a Colombian rule (DIAN, Ley Emiliani holidays, COP amounts, IVA, GMF, UVT) has to be applied exactly, e.g. in invoicing or payment flows. [EN completo / full EN: inputSchema.description]

Input Schema

NameRequiredDescriptionDefault
endYesEnd YYYY-MM-DD (string; required; up to 10 chars; format date).
startYesStart YYYY-MM-DD (string; required; up to 10 chars; format date).
inclusiveNoCount the start date too (boolean; optional; default false).
saturday_is_businessNoSaturday counts as business day (boolean; optional; default false).

Output Schema

NameRequiredDescriptionDefault
business_daysNo
holidays_skippedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / end / examples
      Added value: +[
      +  "2026-11-30"
      +]
    • addedInput schema / properties / start / examples
      Added value: +[
      +  "2026-11-01"
      +]
  2. Changed1 schema field changed
    • addedInput schema / description
      Added value: +"EN: Counts business days (días hábiles) between two dates in Colombia, excluding Sundays, Saturdays (unless saturday_is_business) and national holidays; lists holidays skipped. When: a Colombian rule (DIAN, Ley Emiliani holidays, COP amounts, IVA, GMF, UVT) has to be applied exactly, e.g. in invoicing or payment flows. Not for: counting working days between two dates, excluding configurable weekend days and a list of holidays (business-days-between). Side effects: none (read-only, no network access, no stored state). Deterministic: the same input gives the same output. Limits: JSON input up to 64 KB, 1 s per call, result up to 1 MB."
  3. First observed

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds context annotations do not cover: 'Efectos secundarios: ninguno (solo lectura, sin red, sin estado guardado)', determinism guarantee, and concrete operational limits (64 KB input, 1 s per call, 1 MB result). Some of the read-only/no-network wording restates readOnlyHint/openWorldHint, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose well, but the body is duplicated bilingually with the ESS/m inverted order and ends with a dangling artifact '\[EN completo / full EN: inputSchema.description]' that is meta-text, not content. The 'Cuándo' list also drags in IVA/GMF/UVT, which are unrelated to counting days and dilute the signal.

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?

With an output schema present, the description needn't explain return values, and it still notes that skipped holidays are listed. Purpose, routing, side effects, determinism and hard limits are all covered; only the trailing truncated-reference artifact and the off-topic 'Cuándo' examples keep it from full marks.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema documents start/end formats, defaults and even examples, so the baseline is 3. The prose reinforces saturday_is_business semantics ('sábados (opcional)') but adds little about `inclusive` beyond what the schema already states.

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?

States a specific verb+resource+locale: counting business days between two dates in Colombia, with the exclusion rules spelled out (Sundays, optional Saturdays, national holidays). The negative clause explicitly names the generic sibling business-days-between, so an agent can discriminate between the two without opening either schema.

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?

Provides explicit 'Cuándo' (applying an exact Colombian rule such as DIAN invoicing/payment flows) and an explicit 'No para' that routes to business-days-between for configurable-weekend counting. When-to-use, when-not, and the alternative are all named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources