Uso de tokens MCP: Medir cuatro cubos por resultado

El uso de tokens MCP debe medirse por Resultado verificado , no por servidor, llamada de herramienta o chat. El total útil es la entrada consumida en cada llamada de modelo requerida para producir el resultado solicitado, dividida en cuatro cubos: instrucciones de línea de base, esquemas de herramientas expuestos, historial de descubrimiento y cargas útiles de resultados de herramientas. Comparar candidatos de optimización sólo después de cada uno produce el mismo resultado de recibo. Esa regla evita dos errores comunes. Un total de sesiones del proveedor no puede decir si los esquemas o resultados causaron el crecimiento. Un pequeño recuento de tokens puede parecer eficiente incluso cuando el agente eligió la herramienta equivocada o omitió el producto entregado. Cuenta primero, preserva el contrato de resultado, y luego cambia una superficie a la vez. Construir un libro mayor de cuatro cubos antes de optimizar El Especificación de las herramientas de MCP define tools/list para el descubrimiento y da a cada herramienta un nombre, descripción y esquema de entrada. Un cliente puede transformar esa respuesta antes de presentar herramientas a un modelo, por lo que MCP no carga tokens. La solicitud de modelo creada por el cliente es lo que importa. Para una tarea, registra: Cubo Lo que le pertenece Por qué crece Línea de base instrucciones del sistema, tarea de usuario, envase de solicitud repetido en cada convocatoria de muestreo Regímenes Nombres de herramientas, descripciones, esquemas de entrada, anotaciones que expone el cliente más herramientas, descripciones verbales, exposición repetida El descubrimiento las coincidencias de búsqueda, las descripciones de las herramientas seleccionadas, los turnos de descubrimiento previos la divulgación progresiva añade viajes de ida y vuelta Resultados las salidas de herramientas retenidas en el historial de mensajes cargas útiles de palabra y reincorporación repetida Sumar cada cubo a lo largo del camino completo a un resultado: Mantenga las lecturas de caché del proveedor, las escrituras de caché, los tokens de salida, la latencia y el precio en las columnas adyacentes. No los mezcle en silencio en los cuatro cubos de entrada. Responden a preguntas diferentes. Un esquema almacenado en caché puede costar menos a un proveedor mientras todavía ocupa el contexto y aún necesita controles de frescura. Definir el recibo de resultados antes de la medición. Para el experimento siguiente, la tarea fue: devolver la tasa de error de API de pago actual, el tiempo de observación y la fuente de evidencia. Una carrera sólo pasó cuando los tres campos existían: Esto es deliberadamente más estricto que la herramienta devuelta con éxito. Un éxito a nivel de transporte sin tiempo de observación podría quedar obsoleto. Un porcentaje sin fuente de evidencia no puede ser investigado. La salida compacta es útil sólo cuando retiene los campos necesarios para la próxima decisión. Cuente la solicitud exacta, no una proporción de texto adivinada Utilice el contador del proveedor objetivo con el mismo modelo, aviso del sistema, mensajes y herramientas que desea enviar. Anthropics Documentación de contabilidad de tokens establece que el punto final acepta las mismas entradas estructuradas que una solicitud de mensaje, incluidas las herramientas. También etiqueta el resultado como una estimación y aconseja contar con el modelo previsto. Una solicitud de prevuelo puede verse así: Nunca pongas la llave en el accesorio JSON o en un informe. Guarde el recuento de entrada devuelto con el identificador de modelo, el tiempo de contador, el hash de solicitud, el recuento de herramientas expuestas, el número de llamada e ID de resultado. Ejecutar el contador una vez para la solicitud de línea de base, luego otra vez después de cada giro de modelo/herramienta porque el historial de descubrimiento y resultados cambia la entrada siguiente. Si su proveedor no tiene contador, use un tokenizer local fijado como un proxy de comparación, no como un hecho de facturación. Mantenga la versión de serie y tokenizer fija. El dispositivo para este artículo utiliza js tiktoken 1.0.21 con cl100k base ; que es reproducible en sus tres escenarios, pero no es un tokenizer Claude. Los porcentajes a continuación son evidencia de la forma relativa de la fijación, no de un ahorro universal de MCP. Lo que el dispositivo de 40 herramientas realmente midió El artefacto inspectable crea 40 herramientas operativas sintéticas. Una de las herramientas devuelve la evidencia de la tasa de error de pago solicitada; las otras 39 tienen nombres, descripciones y esquemas realistas de JSON, pero son irrelevantes para esta tarea. Compara tres caminos: 1. exponer los 40 esquemas y conservar un resultado verbal; 2. exponer únicamente la herramienta conocida y conservar un resultado compacto; 3. exponer search tools , describe tools y execute tool , luego descubrir un esquema y conservar el resultado compacto. Cada camino pasó por el mismo recibo de tres campos. Las entradas de proxy medidas fueron: Escenario Las llamadas Línea de base Regímenes El descubrimiento Resultados El total El ahorro : : : : : : : Las herramientas estáticas 40, resultado verbal 2 110 8,768 0 625 9,503 línea de base Herramienta seleccionada, resultado compacto 2 110 188 0 55 353 96.3% Descubrimiento dinámico, resultado compacto 4 220 572 309 55 1,156 87.8% La observación dominante es la atribución, no el porcentaje principal: los esquemas repetidos contribuyeron a 8.768 de los 9.503 tokens proxy en el camino estático. La reducción del resultado por sí sola no repararía esa carga de trabajo. Por el contrario, cuando ya se conocía la herramienta correcta, el camino de una herramienta superó al descubrimiento dinámico porque el descubrimiento duplicó el número de llamadas de modelo y agregó 309 tokens de historia. El accesorio y el contador son lo suficientemente pequeños como para inspeccionar: Reproduce la estructura con sus definiciones reales de herramientas, pero reemplace el proxy con el contador de su proveedor antes de establecer un umbral de costo o ventana de contexto. También reemplazar el recibo de éxito sintético con una verificación determinista de su efectividad de entrega o efecto externo. Estos resultados coinciden con la dirección de un Indicador de referencia del conjunto de herramientas dinámicas Speakeasy más grande: la exposición progresiva a las herramientas puede reducir en gran medida la entrada de esquemas estáticos, pero requiere más llamadas a las herramientas y puede aumentar la latencia. Sus porcentajes provenían de sus conjuntos de herramientas, tareas y modelos. No son una promesa para ti. Elige el control del cubo más grande Utilice el libro mayor para elegir una intervención: Si los esquemas dominan y la herramienta requerida es conocida desde el contexto de enrutamiento, exponer un subconjunto autorizado. Si los esquemas dominan pero la herramienta no se conoce, prueba la búsqueda dinámica y la descripción en relación con los casos de falta de recuperación. Si los resultados dominan, proyecta sólo los campos relevantes para la decisión y mantenga la frescura, la cobertura, los errores y las referencias de la evidencia. Si la línea de base domina, acortar las instrucciones repetidas o separar la política estable del contexto específico de la tarea. Si el descubrimiento domina, mejore el enrutamiento, reutilice una selección de alcance seguro o acepte un subconjunto estático más grande. No comience con instalar un optimizador de tokens. Comience con el cubo y la tarea. Una superficie de CRM de cuarenta herramientas puede justificar el descubrimiento progresivo. Una comprobación de salud programada que siempre llama a una herramienta métrica conocida de sólo lectura probablemente no lo haga. Para el descubrimiento dinámico, el fracaso de las pruebas es tan agresivo como el ahorro. Incluye términos de usuario ambiguos, nombres de herramientas casi duplicados, herramientas no disponibles, pérdida de permisos, listas de herramientas obsoletas y una consulta que no debe seleccionar ninguna herramienta. Medir la precisión de la selección y el tiempo P95 hasta el resultado verificado. El paso adicional de búsqueda sólo vale la pena cuando la reducción del esquema supere su costo de recuperación y latencia. La compactación del resultado necesita su propio límite. Mantenga identificadores, unidades, tiempo de observación, cobertura, estado de error y una referencia de evidencia cada vez que afecten a la próxima acción. Evite registros completos, prosa duplicada, metadatos no utilizados y registros crudos. Si un resultado compacto elimina la razón por la que un operador puede confiar o reproducir un veredicto, es la pérdida de datos. Utilice una simple puerta de promoción: Establezca los objetivos de su carga de trabajo en lugar de copiar el dispositivo. Retroceder si la calidad del resultado, la selección de herramientas, la frescura o la verificación se desvanecen. Menos tokens no es una señal de recuperación, y una llamada de MCP completada no es prueba de que el trabajo previsto haya ocurrido. Mantenga el límite de salud explícito El crecimiento de los tokens puede indicar esquemas repetidos, resultados de herramientas de gran tamaño, retemplazos o acumulación de contexto. También puede ser legítimo: una nueva herramienta se hace necesaria, una investigación necesita pruebas, o el agente está esperando en lugar de hacer bucle. Interpretar el libro mayor junto con el progreso útil y el resultado esperado. Sidewisp se encuentra actualmente en versión preliminar privada. Su dirección de producto incluye la eficiencia del tiempo y el presupuesto como una señal de salud para el agente, pero se planean la recopilación y optimización del uso de tokens en vivo; esa capacidad no se envía hoy. El paso práctico ahora es mantener su propio libro mayor por resultado, preservar la evidencia, y probar un cambio de exposición de MCP a la vez. La decisión es entonces concreta: utilizar la exposición seleccionada para una ruta estable de herramientas conocidas, el descubrimiento dinámico para una gran superficie incierta que pasa las pruebas de recuperación y la proyección de resultados cuando el historial de carga útil es el costo real. Publicar el cambio sólo después de que el mismo recibo de resultados aún pasa.