Burs-IA Utils

Sumar duración a una fecha

date-add

Read-onlyIdempotent

Suma o resta años, meses, semanas, días, horas, minutos y segundos a una fecha; ajusta fines de mes. Cuándo: un resultado de fechas, zonas horarias o calendario tiene que ser exacto (desfases, horario de verano, fines de mes, bisiestos). No para: sumar o restar días hábiles, saltando fines de semana y festivos dados (business-days-add). 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: Adds (or subtracts, with negatives) years, months, weeks, days, hours, minutes and seconds to a date-time. Calendar parts use local wall time in the zone and clamp month ends (Jan 31 + 1 month = Feb 28/29). When: a date, time-zone or calendar result has to be exact (offsets, daylight saving, month ends, leap years). Not for: adding or subtracting business days, skipping weekends and given holidays (business-days-add). [EN completo / full EN: inputSchema.description]

Input Schema

Name	Required	Description	Default
`days`	No	Days (integer; optional; default 0; min -3650000; max 3650000).
`hours`	No	Hours (number; optional; default 0; min -87600000; max 87600000).
`weeks`	No	Weeks (integer; optional; default 0; min -520000; max 520000).
`years`	No	Years (integer; optional; default 0; min -10000; max 10000).
`months`	No	Months (integer; optional; default 0; min -120000; max 120000).
`minutes`	No	Minutes (number; optional; default 0; min -5256000000; max 5256000000).
`seconds`	No	Seconds (number; optional; default 0; min -320000000000; max 320000000000).
`datetime`	Yes	ISO 8601 date-time (with Z/offset, or naive local time in `timezone`) or YYYY-MM-DD (string; required; up to 40 chars).
`timezone`	No	IANA time zone, e.g. America/Bogota (default UTC) (string; optional; default "UTC"; up to 64 chars).	UTC

Output Schema

Name	Required	Description	Default
`utc`	No
`result`	No	any JSON value

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026
- addedInput schema / properties / datetime / examples
```
Added value: +[
+  "2026-01-31"
+]
```

Changed1 schema field changedNov 1, 2026

addedInput schema / description

Added value: +"EN: Adds (or subtracts, with negatives) years, months, weeks, days, hours, minutes and seconds to a date-time. Calendar parts use local wall time in the zone and clamp month ends (Jan 31 + 1 month = Feb 28/29). When: a date, time-zone or calendar result has to be exact (offsets, daylight saving, month ends, leap years). Not for: adding or subtracting business days, skipping weekends and given holidays (business-days-add). 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."

First observedNov 1, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, and the description reinforces with 'sin red, sin estado guardado' plus determinism and concrete limits (64 KB input, 1 s per call, 1 MB result). The semantic disclosure that calendar parts use local wall time in the zone and clamp month ends is genuinely additive. It stops short of output-shape detail, but an output schema exists.

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?

The 'When / Not for / Side effects / Deterministic / Limits' labeling is well front-loaded and scannable, but the payload is duplicated in Spanish and English and ends with a dangling pointer ('[EN completo / full EN: inputSchema.description]') that adds no information. Roughly half the text is redundant.

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?

With 9 parameters, a fully described schema, an output schema, and rich annotations, the description covers all that remains: exactness guarantees, month-end semantics, exclusions, and execution limits. Nothing an agent needs to invoke it correctly is missing.

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 the baseline is 3, but the description earns more by explaining that negative values subtract, that calendar units operate on local wall time in `timezone`, and the Jan 31 + 1 month = Feb 28/29 clamping rule — behavior the schema's numeric bounds cannot convey.

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 set (adds/subtracts) and resource (date-time) plus the exact unit families supported and the month-end clamping rule. It explicitly distinguishes itself from the sibling business-days-add, so an agent can differentiate 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?

Uses explicit 'When:' (offsets, DST, month ends, leap years) and 'Not for:' clauses that name the alternative tool (business-days-add) with the condition that selects it. No inference required.

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

All Burs-IA Utils tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?