Analizar una hoja de cálculo con 50.000 filas mediante un modelo de inteligencia artificial puede consumir millones de tokens, elevar el coste de cada consulta y aumentar el riesgo de errores en los cálculos. El ingeniero de datos Andrei Kushniarou ha desarrollado gsheets-mcp, un servidor local que conecta Claude con Google Sheets y procesa los datos cerca de su origen. En una prueba con un informe ficticio de liquidaciones de Amazon, el sistema redujo de 1,83 millones a 787 los tokens utilizados para resolver una consulta sobre el destino del dinero, una reducción de aproximadamente el 99,96 %.
Las claves de gsheets-mcp en 30 segundos
- El proyecto analiza una hoja de 50.009 filas y 24 columnas con datos sintéticos de liquidaciones de Amazon.
- La versión inicial necesitaba 1,83 millones de tokens para responder a la consulta planteada.
- La agregación de datos en el servidor redujo el resultado a 154 tokens para una operación concreta y a 787 tokens en el flujo completo medido.
- El servidor utiliza la API de Google Sheets y evita enviar todas las filas al modelo cuando no son necesarias.
- El objetivo es reducir costes, mejorar la fiabilidad de los cálculos y mantener los datos fuera de servicios intermediarios adicionales.
El proyecto aborda un problema cada vez más habitual en los sistemas de inteligencia artificial conectados a herramientas empresariales: los modelos pueden razonar sobre datos estructurados, pero eso no significa que deban recibir una copia completa de cada tabla. Cuando una pregunta exige sumar importes, agrupar transacciones o localizar diferencias entre registros, enviar miles de filas al modelo puede ser mucho más costoso que realizar la operación directamente sobre los datos.
Kushniarou trabaja como ingeniero de datos en comercio electrónico y explica que desarrolló la herramienta para consultar, modificar y calcular información almacenada en grandes hojas de Google Sheets mediante Claude. La privacidad también influyó en su decisión: quería evitar que los datos pasaran por servidores MCP de terceros. Por eso, gsheets-mcp se ejecuta localmente y accede directamente a Google Sheets mediante su API.
De millones de tokens a una consulta que devuelve nueve resultados
La prueba utiliza una hoja de cálculo sintética con 50.009 filas y 24 columnas, diseñada para reproducir la estructura de un informe de liquidaciones de Amazon. Los productos y los identificadores son ficticios, por lo que el conjunto permite repetir el experimento sin exponer información comercial real.
La pregunta que debe resolver el modelo es habitual en comercio electrónico: averiguar dónde ha ido el dinero entre las ventas y el pago recibido, desglosando los importes por tipo de movimiento.
El primer problema aparece al intentar introducir la tabla directamente en el contexto del modelo. Según las mediciones del autor, la información ocupa unos 5,8 millones de tokens en formato TSV y cerca de 19 millones en un JSON con formato legible e indentación. El modelo utilizado en las pruebas, Claude Opus 5.5, dispone de una ventana de contexto de un millón de tokens, por lo que no puede recibir toda la tabla de una sola vez en esas representaciones.
Incluso cuando se trabaja por fragmentos, aparecen otras limitaciones. Las respuestas pueden superar los límites de salida de las herramientas, el modelo necesita repetir consultas para recorrer los datos y el coste aumenta con cada nueva lectura. Además, confiar en un modelo de lenguaje para sumar decenas de miles de importes no ofrece las mismas garantías que realizar las operaciones con un sistema de cálculo diseñado para ello.
La versión inicial de gsheets-mcp, publicada el 10 de agosto según el artículo, devolvía la información como JSON indentado. Con el enfoque más cuidadoso descrito por el autor, resolver la consulta requería 11 llamadas y alrededor de 1,83 millones de tokens.
Si el modelo intentaba leer directamente la hoja, solo recibía las primeras 5.000 filas de las 50.009 disponibles. En otras palabras, trabajaba con aproximadamente el 10 % de los registros y podía generar una respuesta incompleta.
La primera optimización consistió en reducir el volumen de datos devuelto y eliminar el formato innecesario. El JSON con nombres de columnas repetidos e indentación consumía muchos más tokens que una representación compacta. Con esos cambios, el coste pasó de 199 a 116 tokens por fila y el consumo total descendió de 1,83 millones a 1,03 millones.
El resultado demuestra que el formato importa, aunque no resuelve el problema principal. Comprimir una tabla reduce el consumo, pero sigue obligando al modelo a recibir una cantidad enorme de información que quizá no necesita para contestar.
El modelo no necesita todas las filas para calcular el resultado
La siguiente mejora de gsheets-mcp consiste en ofrecer una vista previa de la estructura de la hoja antes de consultar sus datos. Desde la versión 0.4.0, el servidor puede describir las pestañas, las letras y los nombres de las columnas, sus tipos estimados, varias filas de ejemplo y el número aproximado de registros.
En el caso de prueba, esa descripción ocupa 633 tokens, o 340 si se excluyen las filas de muestra. El modelo obtiene así un mapa de la hoja sin tener que leer cientos de miles de tokens para averiguar qué información contiene.
La detección de tipos tiene límites: el autor explica que se basa en las primeras diez filas, por lo que algunas columnas pueden aparecer vacías si los primeros registros no contienen todavía sus valores habituales. Es una limitación relevante cuando se trabaja con hojas que mezclan pedidos, devoluciones, ajustes y otros movimientos.
Una vez identificadas las columnas necesarias, el servidor puede leer solo las que interesan. Para la consulta del informe de Amazon, esas columnas son el tipo de importe y el propio importe. Esta selección reduce el coste por fila de 116 a 11,6 tokens y baja el consumo total de 1,03 millones a unos 580.000 tokens.
La mejora sigue siendo insuficiente para la consulta completa. Aunque se envía menos información, el modelo continúa recibiendo miles de importes y tiene que razonar sobre ellos. La solución definitiva llega cuando el cálculo se traslada al servidor.
Agregación local: enviar el resultado en lugar de la tabla
La función gsheets_aggregate permite agrupar datos y calcular métricas como recuentos, sumas, mínimos, máximos y promedios. También admite filtros y límites para controlar el resultado.
En lugar de entregar las 50.009 filas al modelo, la herramienta recibe una instrucción para agrupar por el tipo de importe y sumar los valores correspondientes. El servidor consulta Google Sheets, procesa los registros y devuelve únicamente los grupos obtenidos.
En la prueba, la operación examina las 50.009 filas y devuelve nueve categorías. La respuesta ocupa 154 tokens, frente a los aproximadamente 580.000 que requería el enfoque anterior. Según el autor, eso supone utilizar unas 3.760 veces menos tokens para esa parte del trabajo.
La diferencia se aprecia también en el flujo completo. El consumo pasa de 1,83 millones de tokens en la primera versión a 787 en la versión optimizada. El resultado corresponde a la prueba concreta publicada por Kushniarou, no a una reducción garantizada para cualquier hoja, pregunta o modelo.
La ventaja no se limita al precio. El servidor realiza las operaciones aritméticas de forma determinista y evita depender de que el modelo interprete correctamente decenas de miles de cifras. El autor indica que el resultado de la prueba coincide con el total del informe hasta el último céntimo.
Menos tokens, pero también más atención a la calidad de los datos
El proyecto pone de manifiesto otro riesgo de los análisis financieros automatizados: una cifra puede parecer razonable y estar equivocada porque ciertos valores no se han interpretado correctamente.
Kushniarou describe un error detectado durante el desarrollo de la versión 0.4.4. Un importe negativo escrito como -$87 se interpretaba como texto y quedaba fuera de la suma. El total seguía pareciendo plausible, por lo que el problema podía pasar desapercibido si no se comprobaban los resultados.
El servidor incorpora lógica para interpretar importes con distintos formatos, incluidos símbolos monetarios, paréntesis para representar valores negativos, separadores decimales y porcentajes. También puede advertir cuando una misma agrupación mezcla porcentajes representados de formas diferentes, como 12 % y 0,12.
El autor decidió limitar deliberadamente las capacidades de la herramienta. La función de agregación no admite consultas complejas con condiciones OR, agrupaciones anidadas o cláusulas HAVING. El objetivo es ofrecer un conjunto reducido de operaciones que el modelo pueda invocar con precisión.
También descartó ejecutar código arbitrario sobre los datos de la hoja. Además de añadir dependencias como pandas, esa opción abriría la puerta a riesgos de inyección de instrucciones (prompt injection) si el modelo pudiera ejecutar código junto a datos controlados por terceros. Para análisis más complejos, propone exportar los datos y utilizar herramientas como pandas o DuckDB en un entorno apropiado.
El coste de las herramientas también cuenta
Las descripciones de las funciones disponibles se incluyen en el contexto de las conversaciones con el modelo. Según las mediciones del autor, la versión 0.1 de gsheets-mcp ocupaba 3.708 tokens en descripciones de herramientas, mientras que la versión 0.4.4 alcanzaba 6.473. En modo de solo lectura, el consumo se situaba en 3.310 tokens.
Ese gasto adicional es pequeño frente a los millones de tokens que puede ahorrar una agregación, pero recuerda que un servidor MCP también tiene un coste de contexto. Diseñar herramientas demasiado amplias o con descripciones innecesariamente largas puede reducir parte de las ventajas obtenidas al optimizar los datos.
El proyecto ya incluye una función para generar gráficos directamente en la hoja de cálculo. Entre los siguientes pasos previstos por el autor figuran buscar registros mediante filtros, comparar dos pestañas a partir de una clave, paginar por número de tokens en lugar de por filas y calcular estadísticas como medianas y percentiles.
También contempla reducir la información repetida y sustituir datos que no sean necesarios para el análisis, como direcciones o números de teléfono, por etiquetas estables. Esa técnica puede disminuir el consumo y limitar la exposición de datos personales, aunque su eficacia depende de cómo se aplique y de que las etiquetas no permitan reconstruir la identidad de los usuarios.
Preguntas frecuentes
¿Qué es gsheets-mcp?
Es un servidor MCP local desarrollado por Andrei Kushniarou para conectar modelos como Claude con Google Sheets. Permite consultar datos, realizar agregaciones y trabajar con hojas grandes sin enviar todas las filas al modelo.
¿Cuántos tokens ahorra gsheets-mcp?
En la prueba publicada, el consumo total pasó de 1,83 millones a 787 tokens. La reducción depende de la consulta, de la estructura de los datos y de las operaciones que se ejecuten.
¿Por qué es mejor calcular los datos en el servidor?
Porque operaciones como sumar, agrupar o contar registros pueden realizarse directamente sobre la tabla. El modelo recibe el resultado y puede dedicar sus tokens a interpretarlo, en lugar de procesar miles de valores numéricos.
¿Los datos salen de Google Sheets al utilizar gsheets-mcp?
El autor afirma que el servidor se ejecuta localmente, utiliza la API de Google Sheets y no envía los datos a otros destinos mediante su propia implementación. Sin embargo, la privacidad del flujo completo también depende de la configuración de Google, del modelo conectado y de las credenciales utilizadas.
