Un servidor MCP le entrega números a algo que luego va a razonar sobre ellos en voz alta, con confianza, ante alguien que no puede comprobarlos. Ese es un problema de diseño distinto del de una API para un programa, y la mayor parte de él no va del protocolo.

Estas son seis decisiones del servidor MCP de Skomi y de qué se defiende cada una. Ninguna es ingeniosa; varias son la segunda versión, después de que la obvia resultara ser una trampa.

1. El token es una cabecera, nunca un parámetro de herramienta

El diseño obvio es un parámetro token en cada herramienta. Se documenta solo, funciona, y mete el secreto del cliente en la conversación, donde llega a los registros del cliente, a cualquier transcripción que se exporte, y a lo que el modelo decida repetir mientras explica lo que acaba de hacer.

Una cabecera es invisible para el modelo. No se puede citar porque no está en el contexto.

El mismo razonamiento dice que el servidor no debería tener ningún token propio. El de Skomi reenvía lo que manda quien llama y no guarda nada, así que no puede hacer nada que no pudieras hacer ya con curl. No hay ningún modo en el que tenga acceso permanente a los datos de nadie, que es la única versión comprobable de «nos tomamos la seguridad en serio».

2. Nada escribe

Todas las herramientas están anotadas con readOnlyHint, y la API que hay detrás es de solo lectura de todas formas, así que la anotación es una descripción y no una promesa.

Vale la pena decirlo claramente porque la tentación va en el otro sentido: un asistente que pudiera cambiar un ajuste hace una demostración preciosa. También significa que una instrucción mal leída tiene consecuencias que sobreviven a la conversación. Leer es reversible; escribir no lo es, y una herramienta de analítica no tiene nada que escribir que valga eso.

3. Una caída devuelve un error, no ceros

Cuando el almacén no está disponible, las herramientas fallan. Deliberadamente no devuelven una página de ceros.

Los ceros serían la respuesta más amable y la más peligrosa, porque un modelo no puede distinguir una semana rota de una semana tranquila. «El tráfico cayó a nada el martes» es una frase que un asistente va a producir, de buena fe, a partir de unos datos de apariencia plausible, y quien la lee no tiene forma de saber que fue una caída de la analítica y no una caída de su sitio.

Un error es una peor experiencia y una experiencia verdadera. La regla general: no devuelvas nunca un valor indistinguible de una medición real cuando no tienes una medición.

4. «Sin comparación» en vez de un número inventado

Cada métrica viene con su variación respecto al periodo anterior. Cuando el periodo anterior era cero, la variación vale null: no infinito, no 100 %, no un número grande que resulte dibujarse.

La variación porcentual desde cero no está definida, y cualquier valor concreto que sustituyas es un número que el modelo va a repetir como un hecho. Las herramientas dicen «sin comparación». Es menos satisfactorio y es lo único honesto que hay disponible.

5. Las filas no suman 100, y la herramienta lo dice

Un desglose cuenta visitantes distintos por fila. Una persona en un teléfono y en un portátil está en dos filas, así que las filas suman más que el total y los porcentajes no llegan a 100.

Sin decirlo, eso es una trampa con un fallo muy concreto: un modelo al que se le pide la «parte de tráfico por país» va a normalizar amablemente las filas al 100 %, algo perfectamente razonable de hacer con una lista de números, y erróneo aquí de una forma que nadie va a pillar aguas abajo.

Así que la propia descripción de la herramienta lo dice: divide por el total de visitantes del periodo que da la herramienta de resumen, nunca por la suma de las filas. La corrección tiene que vivir donde el modelo está mirando, que es la descripción de la herramienta, no la documentación que leyó otra persona.

6. Los filtros son dimensiones, y hay un solo analizador

Cada nombre de dimensión funciona también como filtro, con el mismo significado en los dos sitios:

breakdown  dimension=path  filters={"country":"EE","device":"mobile"}

Un solo analizador significa que los dos no pueden estar en desacuerdo: un filtro que construye el modelo es exactamente un filtro que el panel podría aplicar, y una dimensión que descubrió preguntando es una por la que puede filtrar de inmediato. Hay además una herramienta que no devuelve más que las dimensiones, los periodos y las reglas de filtro aceptadas, para que un modelo pueda preguntar qué es lícito en vez de adivinar y reintentar.

El rincón incómodo: para filtrar por un valor que no se registró nunca (las visitas sin campaña, por ejemplo), le pasas __none__. Una cadena vacía es indistinguible de un parámetro ausente una vez analizada la petición, así que el valor vacío tiene que viajar de alguna forma. Toda API acaba teniendo una de estas; el gesto honesto es documentarla en vez de fingir que la forma es uniforme.

A qué se reduce todo esto

La mayor parte es un solo principio aplicado repetidamente: una respuesta ambigua es peor que una negativa, porque lo que consume tu API va a resolver la ambigüedad con confianza y en voz alta.

Eso no es propio de MCP. Es solo que el consumidor habitual (un programa con un programador detrás) habría lanzado una excepción, y este escribe un párrafo.

El servidor de Skomi está en mcp.skomi.com y no hay nada que instalar; la API de consulta que lee es la misma que puede usar cualquier otra cosa.

Los números que lee son los mismos que te enseña Analytics, a través de la misma API de consulta; no hay una segunda cadena sobre la que el modelo pueda equivocarse. Servidor MCP define el término si es nuevo para ti.