Utilização de tokens MCP: Medir quatro baldes por resultado

O uso de tokens MCP deve ser medido por Resultado verificado , não por servidor, chamada de ferramenta ou chat. O total útil é a entrada consumida em cada chamada de modelo necessária para produzir o resultado solicitado, dividida em quatro baldes: instruções de linha de base, esquemas de ferramentas expostas, histórico de descoberta e cargas úteis de resultados de ferramentas. Compare os candidatos à otimização apenas depois de cada um produzir o mesmo recibo de resultado. Essa regra evita dois erros comuns. Um total de sessões do fornecedor não pode dizer se esquemas ou resultados causaram o crescimento. Uma pequena contagem de tokens pode parecer eficiente mesmo quando o agente escolheu a ferramenta errada ou omitiu o produto. Conte primeiro, preserve o contrato de resultado, e depois mude uma superfície de cada vez. Construir um livro razão de quatro baldes antes de otimizar O Especificação das ferramentas MCP define o tools/list para descoberta e dá a cada ferramenta um nome, descrição e esquema de entrada. Um cliente pode transformar essa resposta antes de apresentar ferramentas a um modelo, de modo que o próprio MCP não carga tokens. O pedido de modelo criado pelo cliente é o que importa. Para uma tarefa, grava: Balde O que pertence a ele. Por que cresce? Linha de base instruções do sistema, tarefa do utilizador, embalagem de pedido Repetido em cada chamada de amostragem Esquemas Nomes de ferramentas, descrições, esquemas de entrada, anotações expostas pelo cliente mais ferramentas, descrições verbais, exposição repetida Descoberta correspondências de pesquisa, descrições de ferramentas selecionadas, viradas de descoberta prévias A divulgação progressiva adiciona viagens de ida e volta Resultados Saídas de ferramentas conservadas no histórico de mensagens Cargas úteis verbais e religação repetida Somar cada balde ao longo do caminho completo para um resultado: Mantenha as leituras no cache do provedor, as gravações no cache, os tokens de saída, a latência e o preço nas colunas adjacentes. Não os misture silenciosamente nos quatro baldes de entrada. Respondem a perguntas diferentes. Um esquema armazenado em cache pode custar menos a um fornecedor enquanto ainda ocupa o contexto e ainda precisa de verificações de frescura. Defina o recibo do resultado antes da medição. Para o experimento abaixo, a tarefa foi: devolver a taxa de erro da API de pagamento atual, o tempo de observação e a fonte de evidências. Uma corrida passou apenas quando os três campos existiam: Isto é deliberadamente mais rigoroso do que a ferramenta devolvida com êxito. Uma percentagem sem fonte de evidências não pode ser investigada. A saída compacta só é útil quando mantém os campos necessários para a próxima decisão. Conte a solicitação exata, não uma proporção de texto adivinhada Use o contador do fornecedor alvo com o mesmo modelo, prompt do sistema, mensagens e ferramentas que pretende enviar. Anthropics Documentação de contagem de tokens afirma que o endpoint aceita as mesmas entradas estruturadas de um pedido de mensagem, incluindo ferramentas. Também marca o resultado como uma estimativa e recomenda a contagem com o modelo previsto. Um pedido de pré voio pode parecer assim: Nunca coloque a chave no dispositivo JSON ou num relatório. Salve a contagem de entrada devolvida com o identificador de modelo, o tempo de contador, o hash de solicitação, a contagem de ferramentas expostas, o número de chamada e o ID de resultado. Execute o contador uma vez para a solicitação de linha de base, e depois novamente após cada virada do modelo/ferramenta porque a história de descoberta e resultado alteram a entrada seguinte. Se o seu provedor não tiver contador, use um tokenizer local afixado como um proxy de comparação, não como um fato de faturamento. Mantenha a versão do serializador e do tokenizer fixa. A fixação para este artigo usa js tiktoken 1.0.21 com cl100k base ; que é reprodutível em seus três cenários, mas não é um tokenizer Claude. As percentagens a seguir indicadas são evidências da forma relativa da fixação, e não uma economia universal de MCP. O que o dispositivo de 40 ferramentas realmente medido O artefato inspecionável cria 40 ferramentas operacionais sintéticas. Uma ferramenta retorna a prova da taxa de erro de pagamento solicitada; as outras 39 têm nomes, descrições e esquemas realistas JSON, mas são irrelevantes para esta tarefa. Compare três caminhos: 1. Expor todos os 40 esquemas e manter um resultado verbal; 2. Expor apenas a ferramenta conhecida e manter um resultado compacto; 3. Expor search tools , describe tools e execute tool , em seguida, descobrir um esquema e manter o resultado compacto. Todos os caminhos passaram pelo mesmo recibo de três campos. As entradas de proxy medidas foram: Escenário Ligações . Linha de base Esquemas Descoberta Resultados Total Salvamento : : : : : : : Ferramentas estáticas 40, resultado verbal 2 110 8,768 0 625 9,503 linha de base Ferramenta selecionada, resultado compacto 2 110 188 0 55 353 96.3% Descoberta dinâmica, resultado compacto 4 220 572 309 55 1,156 87.8% A observação dominante é a atribuição, não a porcentagem de cabeçalho: esquemas repetidos contribuíram com 8.768 dos 9.503 tokens proxy no caminho estático. Trimming o resultado sozinho não iria reparar essa carga de trabalho. Por outro lado, quando a ferramenta correta já era conhecida, o caminho de uma ferramenta venceu a descoberta dinâmica porque a descoberta dobrou o número de chamadas de modelo e adicionou 309 tokens de história. O aparelho e o contador são pequenos o suficiente para inspecionar: Reproduzir a estrutura com as suas definições reais de ferramentas, mas substituir o proxy com o contador do seu provedor antes de definir um limiar de custo ou janela de contexto. Também substituir o recibo de sucesso sintético com uma verificação determinista do seu efeito real ou externo. Estes resultados concordam com a direção de um Indicador de referência Speakeasy toolset dinâmico maior: a exposição progressiva à ferramenta pode reduzir significativamente a entrada de esquema estático, mas requer mais chamadas de ferramentas e pode aumentar a latência. Suas percentagens vieram de seus conjuntos de ferramentas, tarefas e modelo. Não são uma promessa para ti. Escolha o controle do balde maior Usar o livro de conta para escolher uma intervenção: Se os esquemas dominarem e a ferramenta necessária for conhecida a partir do contexto de roteamento, expor um subconjunto autorizado. Se os esquemas forem dominantes, mas a ferramenta não for conhecida, teste a pesquisa dinâmica e a descrição em relação aos casos de falta de recuperação. Se os resultados dominarem, projetar apenas os campos relevantes para a decisão e manter a frescura, a cobertura, os erros e as referências de evidências. Se a linha de base dominar, reduzir as instruções repetidas ou separar a política estável do contexto específico da tarefa. Se a descoberta dominar, melhorar o roteamento, reutilizar uma seleção com escopo seguro ou aceitar um subconjunto estático maior. Não comece com instalar um optimizador de tokens. Comece com o balde e a tarefa. Uma superfície de CRM de quarenta ferramentas pode justificar a descoberta progressiva. Um exame de saúde programado que sempre chama uma ferramenta métrica conhecida apenas para leitura provavelmente não o faz. Para a descoberta dinâmica, falha de teste tão agressivamente quanto a poupança. Incluir termos ambiguos de usuário, nomes de ferramentas quase duplicados, ferramentas não disponíveis, perda de permissão, listas de ferramentas obsoletas e uma consulta que não deve selecionar nenhuma ferramenta. Medir a precisão da selecção e o tempo P95 até ao resultado verificado. A etapa de pesquisa extra só vale a pena quando a redução do esquema exceder o seu custo de recuperação e latência. A compactação resultante precisa de seu próprio limite. Mantenha identificadores, unidades, tempo de observação, cobertura, estado de erro e referência de evidências sempre que afetarem a próxima ação. Evite registros completos, prosa duplicada, metadados não utilizados e registros crus. Se um resultado compacto remover a razão pela qual um operador pode confiar ou reproduzir um veredicto, é perda de dados. Use um portal de promoção simples: Defina os objetivos da sua carga de trabalho em vez de copiar o dispositivo. Revertir se a qualidade do resultado, a seleção de ferramentas, a frescura ou a verificação regressarem. Menos tokens não é um sinal de recuperação, e uma chamada de MCP concluída não é prova de que o trabalho previsto aconteceu. Mantenha os limites de saúde explícitos O crescimento dos tokens pode indicar esquemas repetidos, resultados de ferramentas de grande dimensão, retries ou acumulação de contexto. Pode também ser legítimo: uma nova ferramenta torna se necessária, uma investigação precisa de provas, ou o agente está à espera em vez de fazer um loop. Interpretar o livro razão ao lado do progresso útil e do resultado esperado. A Sidewisp está atualmente em prévia privada. Sua direção de produto inclui eficiência de tempo e orçamento como um sinal de saúde do agente, mas a coleta e otimização de uso de tokens ao vivo estão planejadas; essa capacidade não é enviada hoje. O passo prático agora é manter o seu próprio livro de contabilidade por resultado, preservar evidências e testar uma mudança de exposição ao MCP de cada vez. A decisão é então concreta: utilizar a exposição selecionada para uma rota de ferramenta conhecida estável, a descoberta dinâmica para uma grande superfície incerta que passa nos testes de recuperação e a projeção de resultados quando o histórico de carga útil é o custo real. Publicar a alteração somente após o mesmo recebimento final ainda passar.