Burs-IA Utils

Verificar CUFE de factura DIAN

co-cufe-verify

Read-onlyIdempotent

Recalcula el CUFE de una factura electrónica de venta colombiana (SHA-384 de los 15 campos definidos por la DIAN: número, fecha, hora, valores, impuestos 01/04/03, total, NIT, clave técnica, ambiente) y lo compara con un CUFE dado; o solo revisa el formato de un CUFE/CUDE. Cuándo: hay que recalcular el CUFE de una factura electrónica DIAN a partir de sus campos para comprobar que coincide. No para: calcular el resumen SHA-384 (hash-sha384). 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: Recomputes the CUFE of a Colombian electronic sales invoice (SHA-384 of the 15 fields defined by DIAN: number, date, time, amounts, tax codes 01/04/03, total, NITs, technical key, environment) and compares it with a given CUFE; or checks a CUFE/CUDE format only. [EN completo / full EN: inputSchema.description]

Input Schema

Name	Required	Description
`cufe`	No	CUFE/CUDE to check (96 hex chars) (string; optional; up to 200 chars).
`fec_fac`	No	Issue date YYYY-MM-DD (FecFac) (string; optional; pattern ^\d{4}-\d{2}-\d{2}$).
`hor_fac`	No	Issue time with offset, e.g. 10:30:45-05:00 (HorFac) (string; optional; pattern ^\d{2}:\d{2}:\d{2}[-+]\d{2}:\d{2}$).
`nit_ofe`	No	Issuer NIT without DV (NitOFE) (string; optional; pattern ^\d{1,15}$).
`num_adq`	No	Buyer ID number (NumAdq) (string; optional; up to 30 chars).
`num_fac`	No	Invoice number with prefix (NumFac) (string; optional; up to 40 chars).
`val_fac`	No	Amount (number or decimal string, max 2 decimals) (one of several shapes; optional).
`val_tot`	No	Amount (number or decimal string, max 2 decimals) (one of several shapes; optional).
`val_imp1`	No	Amount (number or decimal string, max 2 decimals) (one of several shapes; optional).
`val_imp2`	No	Amount (number or decimal string, max 2 decimals) (one of several shapes; optional).
`val_imp3`	No	Amount (number or decimal string, max 2 decimals) (one of several shapes; optional).
`clave_tecnica`	No	Technical key from the numbering resolution (ClTec) (string; optional; up to 200 chars).
`tipo_ambiente`	No	Environment: 1 production, 2 testing (optional; one of: 1, 2).

Output Schema

Name	Required	Description	Default
`cufe`	No
`chain`	No
`reason`	No
`matches`	No
`format_valid`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 1, 2026

addedInput schema / description

Added value: +"EN: Recomputes the CUFE of a Colombian electronic sales invoice (SHA-384 of the 15 fields defined by DIAN: number, date, time, amounts, tax codes 01/04/03, total, NITs, technical key, environment) and compares it with a given CUFE; or checks a CUFE/CUDE format only. When: the CUFE of a DIAN e-invoice has to be recomputed from the invoice fields to check that it matches. Not for: computing the SHA-384 digest (hash-sha384). 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.7/5.0

Behavior5/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 still adds real information beyond them: no network access, no stored state, determinism guarantee, and concrete limits (64 KB JSON input, 1 s per call, 1 MB result). That is exactly the operational context annotations cannot express.

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?

Front-loaded with the core definition, then when/not-for, side effects, determinism and limits in scannable labeled blocks; every clause carries information. It loses a point for shipping the same content twice (full Spanish block plus an English block that is then truncated and deferred to inputSchema.description, where it is duplicated again).

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?

For a 13-parameter, zero-required, read-only computation with an output schema and rich annotations, the description covers algorithm, modes, exclusions, determinism and resource limits — almost everything an agent needs. The remaining gap is mode-selection guidance: nothing says which fields must accompany cufe to trigger the recompute path versus the format-only path.

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% and output schema exists, so the baseline is 3; the description earns one step above by giving domain meaning the schema flattens — it identifies val_imp1/2/3 as tax codes 01/04/03, and típico fields like the technical key and environment, and distinguishes the recompute mode from the format-only mode. It stops short of 5 because it never states which parameter combinations select which mode (all 13 params are optional, so a zero-arg call's behavior is unstated).

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 and resource ('recomputes the CUFE of a Colombian electronic sales invoice') and pins down the exact algorithm (SHA-384 over the 15 DIAN fields), plus a second documented mode (format-only validation of a CUFE/CUDE). An agent can distinguish it from hash-sha384 and from generic validators without opening the 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?

Explicit 'Cuándo' section names the trigger (recompute the CUFE from invoice fields to check it matches) and an explicit 'No para' section routes the agent to hash-sha384 when a plain SHA-384 digest is wanted. Both the use case and the nearest alternative are spelled out.

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?