DEV Community: Pablo Nieto

Dotando a IAs con: V1 Finance Sepa-Xml (ETL-D API)

Pablo Nieto — Sat, 04 Apr 2026 10:00:18 +0000

CONTENT:

El Problema de la Alucinación

Las Modelos de Lenguaje Grande (LLM) tienden a "alucinar" cuando les falta información precisa y específica, especialmente en tareas técnicas y financieras. Al integrar el endpoint /v1/finance/sepa-xml de ETL-D, logramos proporcionar una herramienta determinística que evita conjeturas, asegurando que el agente siempre dispone de datos precisos para generar los ficheros XML de adeudo directo SEPA.
Arquitectura de la Herramienta del Agente

Este endpoint funciona como middleware determinístico dentro de la arquitectura del agente. Los agentes de LLM, como LangChain o AutoGPT, necesitan herramientas que les proporcionen respuestas predecibles y concretas. Al integrar este endpoint, el agente puede transformar entradas JSON en un XML SEPA Direct Debit sin depender de las predicciones, haciendo del proceso un paso confiable en el flujo de trabajo del agente.
Implementación

from etld_sdk import FinanceTool
from etld_sdk.exceptions import ServiceException
from langchain import Agent

class SEPAToolModule:
    def __init__(self, api_key):
        self.client = FinanceTool(api_key=api_key)

    def generate_sepa_xml(self, sepa_input_json):
        try:
            response = self.client.generate_sepa_endpoint_v1_finance_sepa_xml_post(sepa_input_json)
            return response
        except ServiceException as e:
            if e.status_code == 402:
                return "Error: 402. No hay créditos suficientes. Se necesita recarga."
            elif e.status_code == 422:
                return "Error: 422. Error de validación en la solicitud."
            else:
                return f"Error: {str(e)}"

# Envolviendo el módulo como una herramienta LangChain
class SepaXMLTool(Agent):
    def __init__(self, api_key):
        super().__init__()
        self.sepa_tool = SEPAToolModule(api_key)

    @tool
    def generate_sepa_tool(self, sepa_input_json):
        return self.sepa_tool.generate_sepa_xml(sepa_input_json)

Especificaciones del Output Determinístico El LLM recibe una respuesta clara y estructurada al solicitar la generación de un archivo SEPA Direct Debit XML. El XML resultante, que cumple con el estándar PAIN.008.001.02, asegura que los datos sean transmitidos de manera precisa y conforme a las exigencias normativas. Si ocurren errores (como falta de créditos o errores de validación), el agente obtiene mensajes de error específicos para un manejo adecuado. Esto permite al agente gestionar las respuestas sin incertidumbres ni conjeturas.

🔗 Get the Agent Tool Code: GitHub Gist

Dotando a IAs con: V1 System Usage (ETL-D API)

Pablo Nieto — Fri, 03 Apr 2026 10:00:19 +0000

CONTENT:

El Problema de la Alucinación:
Los Modelos de Lenguaje de Gran Escala (LLM) como LangChain o AutoGPT se enfrentan a menudo al problema de la alucinación, donde el modelo puede generar respuestas incorrectas o no precisas debido a la falta de contexto o información incorrecta. Estas "alucinaciones" pueden ser mitigadas al integrar la API /v1/system/usage, que proporciona datos precisos sobre el uso y balance de créditos del API. Este endpoint actúa como una fuente de verdad, permitiendo al agente tomar decisiones basadas en datos deterministas y reales, evitando así conjeturas.
Arquitectura de la Herramienta del Agente:
El endpoint /v1/system/usage es implementado como un middleware determinista dentro de la arquitectura del agente. Funciona como un punto de acceso confiable para obtener información clave sobre el uso del API, lo cual es esencial para la planificación y toma de decisiones. Al integrar esta capacidad dentro de la funcionalidad de un LLM, se garantiza que las acciones del agente estén alineadas con la realidad financiera y operacional del sistema, evitando así cualquier acción que pueda resultar en un error debido a falta de créditos.
Implementación:

from etld_sdk import UsageApi
from langchain_tools import register_tool

class UsageChecker:
    def __init__(self, api_key):
        self.api_client = UsageApi(api_key=api_key)

    def get_usage(self):
        try:
            usage_data = self.api_client.get_usage_v1_system_usage_get()
            return usage_data
        except Exception as e:
            return {"error": str(e)}

@register_tool("Get Usage", requires_api_key=True)
def fetch_api_usage(api_key):
    checker = UsageChecker(api_key)
    response = checker.get_usage()
    if "error" in response:
        raise ValueError('API Usage Retrieval Failed: ' + response["error"])
    return response

# Mostrar cómo se utilizaría en un agente
agent_response = fetch_api_usage(api_key="tu_api_key_here")
print(agent_response)

Especificaciones de Salida Determinística: El LLM recibe de vuelta una respuesta JSON estructurada que incluye detalles precisos sobre el balance de créditos disponible y el estatus actual del API, permitiendo al agente ajustar su estrategia o acciones de acuerdo a los recursos disponibles. Esto incluye un campo de "error" en caso de que falle la llamada al endpoint, lo que permite al agente gestionar excepciones adecuadamente y mantener robustez en operaciones posteriores.

🔗 Get the Agent Tool Code: GitHub Gist

Empowering AI Agents: V1 Enrich Split-Contact (ETL-D API)

Pablo Nieto — Thu, 02 Apr 2026 10:00:14 +0000

CONTENT:

The Hallucination Problem: Large Language Models (LLMs) are inherently probabilistic and often generate plausible but incorrect responses, known as "hallucinations," when they lack specific information. This can be problematic in scenarios where precise and accurate data extraction is required, such as parsing a string of messy contact information into structured components. Integrating the '/v1/enrich/split-contact' endpoint ensures that the LLM does not have to guess, providing deterministic and reliable results instead.
Agent Tool Architecture: The '/v1/enrich/split-contact' endpoint acts as a deterministic middleware for LLM Agents. By leveraging the reliable ETL-D service, the endpoint takes in unstructured contact information and consistently outputs structured data, thereby enhancing the agent's ability to process contact information accurately. This integration minimizes errors and enriches the LLM’s capabilities by providing precise and structured data when needed.
Implementation:

from etld_sdk import EtldClient, models
from langchain.agents import Tool

# Configuration for ETL-D Client
class ContactSplitter:
    def __init__(self, api_key):
        self.client = EtldClient(api_key=api_key)

    def split_contact(self, contact_string: str):
        try:
            # Construct the input model as per the ETL-D SDK
            input_data = models.SplitContactInput(contact_string=contact_string)
            # Use the endpoint to process the input
            response = self.client.split_contact_v1_enrich_split_contact_post(input_data)
            return response.dict()  # Ensuring a dict format for agent compatibility
        except models.EtldException as e:
            # Handling exceptions related to payment or validation
            if e.status_code == 402:
                return {"error": "Payment Required - Insufficient credits."}
            elif e.status_code == 422:
                return {"error": f"Validation Error: {e.detail}"}
            else:
                return {"error": "An unexpected error occurred."}

# Integration with LangChain
contact_splitter_tool = Tool(
    name="ContactSplitter",
    func=ContactSplitter(api_key="your_api_key").split_contact,
    description="A tool to split a contact string into name, title, phone, and email."
)

Deterministic Output Specs: When the LLM agent invokes this tool, it receives a structured JSON object with components such as Name, Title, Phone, and Email, extracted accurately from the provided messy contact string. This structured data format ensures the agent's responses are not only accurate but also reliable, facilitating further automation processes and reducing the risk of incorrect data generation.

🔗 Get the Agent Tool Code: GitHub Gist

Empowering AI Agents: V1 Finance Forex-Historical (ETL-D API)

Pablo Nieto — Wed, 01 Apr 2026 10:00:22 +0000

CONTENT:

The Hallucination Problem:

Large Language Models (LLMs) like GPT-3.5 and beyond are incredibly powerful at generating human-like text based on input prompts. However, they often suffer from a phenomenon known as "hallucination," where they generate information that is plausible but incorrect or not grounded in any factual basis. In financial applications, especially when dealing with historical currency conversion, accuracy and determinism are paramount. By integrating the '/v1/finance/forex-historical' endpoint, LLMs can rely on verified data, ensuring that responses around historical currency conversion are accurate and grounded in truth, thus avoiding the pitfalls of guessing or fabricating exchange rates.

Agent Tool Architecture:

The '/v1/finance/forex-historical' endpoint acts as a deterministic middleware in the architecture of autonomous agents. By embedding this endpoint as a tool within an agent framework like LangChain or AutoGPT, it provides a reliable interface to query historical forex data. This deterministic tool ensures that every time an agent requires currency conversion with historical context, it can pull real data rather than rely on possibly flawed language model-generated data. This not only enhances the accuracy of the agent's outputs but also instills trust in its reliability for financial tasks.

Implementation:

Below is a Python implementation using the ETL-D SDK to wrap the '/v1/finance/forex-historical' endpoint as a LangChain tool. This function handles potential errors such as insufficient credits or validation errors.

from etld import ETLDClient
from langchain_tools import tool

API_KEY = 'your_api_key_here'
client = ETLDClient(api_key=API_KEY)

@tool
def forex_historical_tool(amount, date, currency, target_currency):
    """
    A tool to convert currency using historical exchange rates.

    :param amount: float, the amount of currency to convert
    :param date: string, the historical date for the conversion (e.g., '2023-01-15')
    :param currency: string, the original currency code (e.g., 'USD')
    :param target_currency: string, the target currency code (e.g., 'EUR')
    :returns: The converted amount
    """
    try:
        response = client.post('/v1/finance/forex-historical', json={
            'amount': amount,
            'date': date,
            'currency': currency,
            'target_currency': target_currency
        })

        if response.status_code == 200:
            return response.json()['converted_amount']
        elif response.status_code == 402:
            raise Exception("Payment Required: Insufficient credits for request")
        elif response.status_code == 422:
            raise Exception("Validation Error: Check input parameters")
    except Exception as e:
        print(f"Error during currency conversion: {str(e)}")

# Example usage:
# converted_amount = forex_historical_tool(100.0, '2023-01-15', 'USD', 'EUR')

Deterministic Output Specs:

The LLM receives back a structured response containing the converted_amount, ensuring the output is precise and factual. As the endpoint guarantees the use of historical rates, the output is immune to the variances typically seen in model-generated responses. This deterministic specification allows developers and users to have confidence in the data's integrity, especially important for applications involving compliance such as international tax declarations and financial reporting.

🔗 Get the Agent Tool Code: GitHub Gist

Empowering AI Agents: V1 Enrich Address (ETL-D API)

Pablo Nieto — Tue, 31 Mar 2026 10:00:14 +0000

CONTENT:

The Hallucination Problem:

Large Language Models (LLMs) are known for their generative capabilities, yet they often struggle with accuracy when dealing with unstructured data such as global address formats. One challenge is the "hallucination problem," where an LLM might fabricate or incorrectly structure address details due to ambiguous input. This endpoint, /v1/enrich/address, mitigates this by offering a deterministic approach to address parsing, transforming messy strings into precise, standardized JSON components, irrespective of the format or locale.
Agent Tool Architecture:

In the context of LLM agents using frameworks like LangChain or AutoGPT, this endpoint functions as a deterministic middleware. By leveraging the ETL-D's address enrichment tool, the LLM agent ensures higher accuracy and reliability in geolocation tasks, effectively bypassing the common pitfalls of inference-based structure when encountering complex address formats. This structured intermediary layer is crucial for scenarios where precision is non-negotiable.
Implementation:

Below is a robust Python implementation that employs the ETL-D Python SDK to integrate the /v1/enrich/address endpoint with a LangChain agent:

  from etld_sdk_v3_2_0 import ETLDClient  # Assume etld_sdk_v3_2_0 is the available imported SDK
  from langchain.agents import tool

  # Initialize the ETLD Client
  client = ETLDClient(api_key='YOUR_API_KEY')

  @tool("enrich_address")
  def enrich_address_tool(address_line: str, locale: str = None, transliterate: bool = True):
      try:
          # Prepare request payload
          payload = {
              "address_line": address_line,
              "context": {"locale": locale, "transliterate": transliterate}
          }

          # Make the API request using ETL-D client
          response = client.post('/v1/enrich/address', json=payload)

          # Handle successful response
          if response.status_code == 200:
              return response.json()
          elif response.status_code == 402:
              raise Exception("Payment Required - Insufficient credits.")
          elif response.status_code == 422:
              raise ValueError("Validation Error", response.json())
          else:
              response.raise_for_status()

      except Exception as e:
          return {"error": str(e)}

  # Example usage
  result = enrich_address_tool("1600 Pennsylvania Avenue NW, Washington, DC 20500")
  print(result)

Deterministic Output Specs: Upon invoking the enrich_address_tool, the agent receives a JSON response representing the parsed and structured format of the given address. The output includes standardized components such as street, city, state, postal code, country, and additional context-specific elements depending on the complexity of the input address. This ensures that the LLM has unambiguous and structured data for downstream tasks, enhancing operational reliability in automation scenarios.

🔗 Get the Agent Tool Code: GitHub Gist

Dotando a IAs con: V1 Enrich Amount (ETL-D API)

Pablo Nieto — Mon, 30 Mar 2026 10:00:26 +0000

CONTENT:

The Hallucination Problem

En los modelos de lenguaje grande (LLM), uno de los desafíos críticos es la tendencia a "alucinar", es decir, generar respuestas poco precisas o inventadas basadas en datos dados incorrectamente. Este problema es especialmente notorio cuando se trata de interpretar valores monetarios a partir de descripciones textuales inconsistentes. Sin la capacidad de procesar datos financieros con precisión, los LLMs pueden proporcionar resultados engañosos que no cumplen con los requisitos de precisión en aplicaciones comerciales. Para resolver esto, se utiliza el endpoint '/v1/enrich/amount' del entorno ETL-D, que se especializa en extraer y limpiar valores monetarios, garantizando así que el LLM recibe datos monetarios exactos y verificados.
Agent Tool Architecture

Integrando el endpoint '/v1/enrich/amount' como una herramienta determinista dentro de un agente automatizado basado en LLM (como los de LangChain o AutoGPT), actúa como un middleware que proporciona validación y enriquecimiento contextualmente conscientes de los datos financieros. Al utilizarse como una capa determinista, se garantiza que las decisiones basadas en valores monetarios se realicen con precisión, sin depende de conjeturas que pueden degradar la funcionalidad del agente.
Implementation

A continuación se muestra un bloque de código en Python que demuestra cómo envolver el uso del SDK de ETL-D como una herramienta en LangChain o una función invocable para un agente. Este bloque maneja los errores comunes, como problemas de crédito insuficiente y errores de validación.

  from etld_sdk import ETLD_Client, ETLD_Exception
  from langchain import Tool

  # Configuración del cliente ETL-D
  client = ETLD_Client(api_key='YOUR_API_KEY')

  def enrich_amount_tool(amount_string, context=None):
      try:
          # Preparando el cuerpo de la petición
          request_data = {'amount_string': amount_string}
          if context:
              request_data['context'] = context

          # Llamada al endpoint de enriquecimiento
          response = client.enrich_amount_v1_enrich_amount_post(request_data)
          return response.json()  # Retorna el resultado procesado

      except ETLD_Exception as e:
          # Manejo de excepciones específicas del SDK de ETL-D
          if e.status_code == 402:
              return "Error: Créditos insuficientes. Por favor, recarga tu cuenta."
          elif e.status_code == 422:
              return f"Error de Validación: {e.message}"
          else:
              return f"Error inesperado: {e.message}"

  @Tool(name="EnrichAmount", description="Utiliza ETL-D para procesar y limpiar valores monetarios.")
  def enrich_amount(amount_text: str):
      return enrich_amount_tool(amount_string=amount_text)

Deterministic Output Specs La salida que recibe el LLM de este proceso es una estructura de datos JSON precisa y limpiada contenida en el MoneyOutput. El esquema asegura que los valores monetarios se proporcionen con exactitud, incluyendo el valor numérico y el código de moneda ISO correspondiente. Esto permite que el LLM utilice estos datos con confianza en sus procesos de toma de decisiones, asegurando un alto nivel de precisión y reduciendo errores potenciales en los flujos de trabajo automatizados.

🔗 Get the Agent Tool Code: GitHub Gist

Empowering AI Agents: V1 Parse Bank-Statement (ETL-D API)

Pablo Nieto — Wed, 25 Mar 2026 10:42:24 +0000

CONTENT:

The Hallucination Problem: Large language models (LLMs), while powerful, can exhibit unpredictable behavior, often referred to as hallucination, where the AI generates incorrect or misleading results. This is particularly critical in financial contexts like parsing bank statements, where accuracy is paramount. The /v1/parse/bank-statement endpoint from the ETL-D provides a deterministic, precise, and structured transformation of Spanish Norma 43 (N43) bank statement files into JSON. By integrating this endpoint, we ensure that our LLM agent can reliably parse bank statement data without making erroneous assumptions or guesses.
Agent Tool Architecture: In the context of an LLM agent like LangChain or AutoGPT, acting as a deterministic middleware, the /v1/parse/bank-statement endpoint plays a crucial role. It serves as a tool that takes raw N43 bank statements as input and processes them into structured data that the LLM can leverage for further analysis or decision-making, eliminating ambiguity and errors in data interpretation.
Implementation: Below is a Python block that demonstrates how to wrap the ETL-D SDK endpoint as a LangChain @tool, incorporating robust error handling.

  from etld_sdk import ETLDClient, BankStatementInput
  from langchain.tools import tool

  # Initialize the ETL-D client
  client = ETLDClient(api_key="your_api_key_here")

  @tool
  def parse_bank_statement(raw_text: str) -> dict:
      """Tool for parsing N43 bank statements using ETL-D endpoint."""
      try:
          # Prepare the input data
          input_data = BankStatementInput(raw_text=raw_text)

          # Call the ETL-D endpoint
          response = client.parse_bank_statement_v1_parse_bank_statement_post(input_data)

          # Handle response
          if response.status_code == 200:
              return response.json()
          elif response.status_code == 402:
              raise Exception("Payment Required: Insufficient credits.")
          elif response.status_code == 422:
              raise ValueError("Validation Error: The input was invalid.")
          else:
              raise Exception("Unexpected error occurred.")

      except Exception as e:
          # Log the error
          print(f"An error occurred: {str(e)}")
          return {}

  # Example usage as a callable function
  def agent_parsing_bank_statements(raw_n43_text):
      return parse_bank_statement(raw_n43_text)

Deterministic Output Specs: When the LLM agent uses this tool to parse a bank statement, it receives back a structured JSON output. This JSON includes detailed account information, balances, and transaction details such as multi-line concepts, providing the LLM a reliable basis for structured data analysis. This process ensures clarity, accuracy, and consistency, critical factors when handling financial data within AI systems.

🔗 Get the Agent Tool Code: GitHub Gist

Why we stopped using LLMs to parse CSVs: Building a Waterfall Architecture for AI Agents

Pablo Nieto — Tue, 24 Mar 2026 18:49:03 +0000

Why we stopped using LLMs to parse CSVs: Building a Waterfall Architecture for AI Agents

Let's be honest: asking an LLM to parse a 10,000-row CSV or a complex financial PDF is a recipe for disaster.

If you've built AI agents recently, you know the "Data Tax" is real:

Token Exhaustion: Sending raw text to a context window is like burning dollar bills to keep your house warm.
Hallucinations: One misplaced comma in a financial trade history, and your $10,000 gain becomes a $100,000 error.
Spatial Blindness: Standard libraries lose the visual structure of tables, leaving the AI guessing which value belongs to which header.

We decided to solve this by building ETL-D, a deterministic data middleware for the AI era.

The Waterfall Architecture (The "Secret Sauce")

We moved away from "LLM-first" parsing. Instead, we implemented a 3-Layer Waterfall that our MCP Server exposes to Claude (and any other agent):

Layer 1: Heuristic (0-shot Python)

We use strict Python logic (dateutil, regex, csv.Sniffer). If the pattern is known (like a standard bank statement or a CSV), we parse it instantly.
Hallucination Risk: 0%.

Layer 2: Semantic Routing

If headers are obfuscated or slightly non-standard, we use a lightweight semantic router to map columns to our strict Pydantic schemas.
Hallucination Risk: <1%.

Layer 3: LLM Fallback (The Last Resort)

Only when the data is pure unstructured "free-text" noise, we trigger an LLM-powered extraction.

Moving to the Model Context Protocol (MCP)

To make this accessible to the world, we've just published the ETL-D MCP Server. By connecting this to Claude Desktop, you stop sending "noise" to the context window.

Instead of:

"Claude, here is 50 pages of raw text from a bank export. Please find the trades."

The flow is now:

Claude identifies the file type.
Claude routes the raw data to the etld-mcp-server tool.
ETL-D "crushes" the data into a flattened, deterministic JSON array.
Claude receives only the perfectly structured facts, ready for reasoning.

The Result

We've seen an 85% reduction in token usage and 99.9% accuracy on legacy formats like Spanish Norma 43, SEC XBRL, and complex Broker Trade Histories.

🚀 Get Started (v3.2.x)

You can find ETL-D in the official Anthropic Registry or install it via NPM:

Official Registry: ETL-D on MCP Registry
NPM Package: npm install etld-mcp-server
Python Core: pip install etld
GitHub (Public Mirror): pablixnieto2/etld-mcp-server

How are you handling messy data in your AI pipelines? Let's discuss in the comments!

Dotando a IAs con: V1 Documents Invoice (ETL-D API)

Pablo Nieto — Tue, 24 Mar 2026 10:44:41 +0000

CONTENT:

The Hallucination Problem:

Los modelos de lenguaje grandes (LLMs) como LangChain o AutoGPT tienen una tendencia a "alucinar" o inventar información que no está presente en los datos de entrada. Esto se debe a que generan texto basado en patrones aprendidos sin un acceso directo a fuentes externas de veracidad en tiempo real. Es crucial integrar servicios de procesamiento específico, como el endpoint '/v1/documents/invoice' del servicio ETL-D, que permite obtener datos estructurados de forma determinista a partir de fuentes como facturas. Al utilizar este endpoint, garantizamos que el LLM no adivine, sino que reciba información precisa extraída de documentos reales.
Agent Tool Architecture:

Para proporcionar certeza y evitar conjeturas, la arquitectura de agentes debe incluir un middleware determinista que se encargue de tareas específicas. El endpoint '/v1/documents/invoice' opera como una capa intermedia fiable que procesa documentos PDF y devuelve datos JSON estructurados. Este enfoque no solo aumenta la precisión del agente, sino que también optimiza el flujo de interacción al delegar la extracción de información a un proceso automatizado y verificado por el SDK de ETL-D.
Implementation:

A continuación, un bloque de código en Python que muestra cómo envolver el SDK de ETL-D en un @tool de LangChain o en una función invocable por un agente, incluyendo manejo de errores:

  from etld_sdk import ETLDClient, ETLDError
  from langchain import tool

  # Configurar cliente ETL-D
  client = ETLDClient(api_key='TU_API_KEY')

  @tool
  def procesar_factura(documento_pdf):
      try:
          respuesta = client.post('/v1/documents/invoice', json={'document': documento_pdf})
          return respuesta.json()  # Retorna un JSON estructurado de la factura
      except ETLDError as e:
          if e.status_code == 402:
              raise ValueError("Créditos insuficientes. Por favor, realiza una recarga.")
          elif e.status_code == 422:
              raise ValueError("Error de validación. Asegúrate de que el PDF sea válido.")
          else:
              raise ValueError("Error desconocido al procesar la factura.")

Deterministic Output Specs: El LLM recibe de vuelta un JSON estructurado conforme al 'InvoiceSchema'. Este contiene datos precisos como el nombre del proveedor, fecha, total, impuestos y elementos de la factura. Al contar con estos detalles específicos, el LLM puede realizar razonamientos y operaciones posteriores con un fundamento sólido en datos reales extraídos y procesados automáticamente.

🔗 Get the Agent Tool Code: GitHub Gist

Dotando a IAs con: V1 Enrich Legal (ETL-D API)

Pablo Nieto — Mon, 23 Mar 2026 10:47:38 +0000

CONTENT:

The Hallucination Problem:
Large Language Models (LLMs) often face the challenge of 'hallucination,' where they generate plausible-sounding but incorrect or nonsensical answers. This is mainly due to their probabilistic nature, which can lead to guessing when precise data validation is needed. The given ETL-D endpoint /v1/enrich/legal serves as a crucial tool for LLMs in domains requiring exact validation, such as legal or financial data processing. By integrating this endpoint, the LLM can deterministically validate Tax Identification Numbers and IBANs, preventing the generation of incorrect information and ensuring compliance with financial regulations.
Agent Tool Architecture:
In an LLM Agent setup, the endpoint acts as a deterministic middleware, allowing the agent to offload specific validation tasks to a robust external service. This separation ensures the agent uses verified data for decision-making processes. The architecture involves the LLM acting as an orchestrator that invokes deterministic tools, like the /v1/enrich/legal endpoint, whenever accurate legal or financial validation is needed. This enhances the reliability of decision-making in complex workflows.
Implementation:
Below is a Python code block illustrating how to integrate the ETL-D SDK as a tool for LangChain. This setup allows an LLM agent to invoke the validation endpoint when required, effectively using it as a callable function:

  from langchain.agents import AgentExecutor, Tool
  from etld import Client

  class LegalValidationTool:
      def __init__(self, api_key):
          self.client = Client(api_key=api_key)

      def validate_legal_data(self, tax_id, country, iban):
          try:
              response = self.client.enrich_legal_v1_enrich_legal_post(
                  {
                      "tax_id": tax_id,
                      "country": country,
                      "iban": iban
                  }
              )
              return response
          except Exception as e:
              if '402' in str(e):
                  raise ValueError("Payment Required - Ensure sufficient credits.")
              elif '422' in str(e):
                  raise ValueError("Validation Error - Check input values.")
              else:
                  raise

  def create_legal_validation_tool(api_key):
      legal_tool = LegalValidationTool(api_key=api_key)

      return Tool(
          name="LegalValidation",
          func=legal_tool.validate_legal_data,
          description="Tool to validate Tax IDs and IBANs."
      )

  # Example usage with LangChain
  api_key = "your_api_key_here"
  legal_tool = create_legal_validation_tool(api_key)
  agent = AgentExecutor(tools=[legal_tool])

  # User request, invoking the tool
  result = agent.run_tool(
      tool_name="LegalValidation",
      tool_input={"tax_id": "B12345678", "country": "ES", "iban": "ES9821000000000000000000"}
  )
  print(result)

Deterministic Output Specs: The output from the /v1/enrich/legal endpoint to the LLM contains the results of the validation process. Upon successful execution, the LLM receives a structured JSON response confirming the validation status and details of the Tax ID and IBAN checked. It can also indicate errors such as payment depletion or input validation issues, which are handled gracefully within the agent's architecture to maintain the system's robustness. This consistent output ensures that the LLM only processes and generates outputs grounded in validated data.

🔗 Get the Agent Tool Code: GitHub Gist

Dotando a IAs con: V1 Logistics Edi-Parse (ETL-D API)

Pablo Nieto — Sat, 21 Mar 2026 10:20:37 +0000

CONTENT:

El Problema de la Alucinación (Por qué un LLM necesita este endpoint ETL-D específico para evitar conjeturas):

Los modelos de lenguaje (LLMs) tienden a alucinar cuando carecen de datos confiables para generar respuestas precisas, lo que significa que pueden ofrecer información incorrecta o fabricada. En el contexto de procesos logísticos y B2B, donde la precisión de los datos es crucial, confiar únicamente en un LLM puede llevar a interpretaciones erróneas de los documentos EDI (Electronic Data Interchange). El endpoint '/v1/logistics/edi-parse' actúa como una herramienta determinista que transforma las cadenas de texto raw ANSI X12 EDI, particularmente los documentos de órdenes de compra 850, en JSON estructurado. Esto proporciona al LLM datos coherentes y exactos, minimizando las conjeturas y garantizando la integridad de la información procesada.
Arquitectura de Herramientas de Agente (Cómo este endpoint actúa como middleware determinista):

Este endpoint es un componente clave en la arquitectura de agentes automatizados donde se requiere procesamiento de datos estructurado. Actúa como un middleware determinista, asegurando que la transformación de datos desde EDI a JSON se realice de manera consistente y predecible, habilitando a los agentes impulsados por LLMs para interactuar con estos datos de forma precisa. Su integración con un agente como los de LangChain permite una separación clara entre la capa de comprensión del lenguaje y la capa de procesamiento de datos, garantizando que los modelos no tengan que inferir o improvisar estructuras de datos complejas.
Implementación (UN bloque de código Python robusto mostrando el SDK de ETL-D envuelto como una herramienta de LangChain o una función invocable para un Agente, con manejo de errores):

  from etld import EDIParser
  from langchain import tool
  import logging

  # Inicializa el cliente del SDK de ETL-D
  parser = EDIParser(api_key="YOUR_API_KEY")

  @tool
  def parse_edi_tool(edi_string):
      try:
          # Request parsing del EDI string al endpoint /v1/logistics/edi-parse
          response = parser.parse_edi(edi_string)
          return response
      except parser.InsufficientCreditsError as e:
          logging.error("Error: Créditos insuficientes. Por favor, recargue su cuenta.")
          return {"error": "Créditos insuficientes, recargue su cuenta."}
      except parser.ValidationError as ve:
          logging.error(f"Error de validación: {ve}")
          return {"error": "Error de validación, EDI string no válido."}
      except Exception as e:
          logging.error(f"Un error inesperado ocurrió: {e}")
          return {"error": "Error inesperado, por favor intente nuevamente más tarde."}

  # Uso del tool
  edi_string = "YOUR_RAW_EDI_STRING"
  result = parse_edi_tool(edi_string)
  print(result)

Especificaciones de Salida Determinista (Lo que el LLM recibe): El resultado de la función parse_edi_tool es un JSON estructurado que representa los datos del documento EDI de manera clara y concreta. En caso de éxito, el JSON estará compuesto conforme al esquema definido en los componentes que el sistema ETL-D espera, proporcionando detalles como identificadores de transacciones, fechas, cantidades y elementos clave de las órdenes de compra. En caso de error, el LLM recibe mensajes específicos sobre la falta de créditos, errores de validación o errores técnicos inesperados, permitiendo al agente manejar adecuadamente la respuesta y proporcionar acciones correctivas o mensajes informativos al usuario final.

🔗 Get the Agent Tool Code: GitHub Gist

Empowering AI Agents: V1 Enrich Sentiment (ETL-D API)

Pablo Nieto — Fri, 20 Mar 2026 10:32:12 +0000

CONTENT:

The Hallucination Problem

Large Language Models (LLMs), though powerful, can sometimes "hallucinate" or produce information that is inaccurate or fabricated. This issue is particularly apparent in situations where the LLM is tasked with interpreting nuanced data such as sentiment. To mitigate this, associating an LLM with deterministic endpoints like the '/v1/enrich/sentiment' offers concrete and verifiable data interpretation. This endpoint acts as an anchor, ensuring that the interpretation of sentiment in text is based on well-defined rules rather than probabilistic guesses. It evaluates the emotional tone of a text string, providing clear polarity, subjectivity, and an overall sentiment label, thus significantly reducing the potential for hallucination.
Agent Tool Architecture

In the context of building autonomous agents using frameworks like LangChain or AutoGPT, this sentiment analysis endpoint functions as a deterministic middleware. By integrating this endpoint, agents can leverage its analytical capabilities to enhance their text interpretation accuracy. The endpoint acts as a specialized function that the agent calls to obtain consistent sentiment analysis results. This ensures that any decision or action the agent undertakes based on sentiment data is founded on precise and objective analytics, enhancing the overall reliability and trustworthiness of the agent's operations.
Implementation

Below is a Python code block demonstrating how to wrap the '/v1/enrich/sentiment' endpoint via the ETL-D Python SDK. The implementation shows its integration into a LangChain-based agent tool, ensuring proper error handling and secure access using an API key.

  from etld_sdk import SentimentAnalysisClient
  from langchain.tools import Tool

  # Instantiate the sentiment analysis client
  sentiment_client = SentimentAnalysisClient(api_key='YOUR_API_KEY_HERE')

  # Define the sentiment analysis tool for LangChain
  class SentimentTool(Tool):
      def __init__(self):
          super().__init__('sentiment-analysis', self.analyze_sentiment)

      def analyze_sentiment(self, text: str) -> dict:
          try:
              response = sentiment_client.evaluate_sentiment({'text': text})
              return response
          except sentiment_client.InsufficientCreditsError:
              return {"error": "Payment Required", "hint": "Please recharge your credits."}
          except sentiment_client.ValidationError as e:
              return {"error": "Validation Error", "details": str(e)}
          except Exception as e:
              return {"error": "An unexpected error occurred.", "details": str(e)}

  # Instantiate the sentiment tool
  sentiment_tool = SentimentTool()

Deterministic Output Specs Upon invoking the '/v1/enrich/sentiment' endpoint, the LLM receives a structured response which includes:
- Polarity: Indicates the positivity or negativity of the text (e.g., positive, negative, neutral).
- Subjectivity: Represents how subjective or objective the text is, on a scale.
- Overall Sentiment Label: A descriptive label summarizing the emotional tone (e.g., "positive", "neutral", "negative").

These outputs are deterministic, meaning they are generated by consistent rules and algorithms, rather than by probabilistic LLM guesswork. This structure enables the LLM agent to incorporate sentiment analysis results confidently into its decision-making processes.

🔗 Get the Agent Tool Code: GitHub Gist