MCP-Persona: Avaliação Personalizada de Uso de Ferramentas

MCP-Persona é um aviso útil para equipes que estão construindo assistentes pessoais, copilotos empresariais e agentes de fluxo de trabalho conectados ao MCP: um modelo pode saber como chamar ferramentas e ainda assim falhar quando a tarefa depende do contexto local bagunçado de um usuário.

O artigo MCP-Persona, lançado no arXiv em 1º de junho de 2026, enquadra o problema como uso de ferramentas personalizadas em vez de chamadas de API genéricas. Os autores introduzem um benchmark para aplicações pessoais do mundo real usando simulação de ambiente. O projeto README diz que o benchmark abrange redes sociais, plataformas de colaboração, e-mail e gerenciamento de conteúdo através das etapas Tool-Traverse, Context-Tree e Persona-Gen. O mesmo README descreve 173 tarefas de cadeia de ferramentas abrangendo 139 ferramentas únicas em 18 servidores MCP.

Este artigo não reproduz o benchmark completo. O Effloow Lab executou uma verificação menor da API OpenAI com dados falsos de calendário e tarefas para transformar a ideia do artigo em um padrão de avaliação leve que um fornecedor de ferramentas para desenvolvedores ou equipe de agentes pode inspecionar. A execução usou apenas dados sintéticos, produziu um artefato salvo e deve ser tratada como um teste de sanidade de prompt-harness, não como um resultado de benchmark.

Nota do laboratório público: /lab-runs/mcp-persona-personalized-tool-eval-poc-2026

O Que Você Vai Construir

Você vai construir um pequeno harness de avaliação para uma tarefa de uso de ferramenta personalizada:

• Um estado de usuário sintético com eventos de calendário, tarefas e preferências.
• Uma pequena lista de ferramentas que se assemelha à exposição de ferramentas no estilo MCP.
• Um prompt de modelo que pede chamadas de ferramentas prováveis, fatos de personalização ocultos, ações inseguras, uma resposta final e verificações de notas de aprovação/reprovação.
• Um rubrica que julga se o agente notou o contexto, respeitou as preferências e evitou fingir mutar o estado.

O ponto não é copiar o pipeline de pesquisa do MCP-Persona. O ponto é extrair um padrão prático:

1. Dar ao agente um contexto específico do usuário e com estado.
2. Exigir planejamento de ferramentas, não apenas geração de respostas.
3. Avaliar fatos de personalização ocultos separadamente da correção genérica.
4. Penalizar ações excessivamente confiantes, poderes de ferramentas inventados e contornos de consentimento.
5. Manter todos os dados pessoais sintéticos até que o processo de avaliação seja seguro.

Para compradores, essa é a diferença entre "nosso agente se integra com suas ferramentas" e "nosso agente pode provar que entende os limites das ferramentas, preferências do usuário, informações ausentes e limites de aprovação."

Por Que o MCP-Persona É Importante

A atual especificação de ferramentas do Modelo de Contexto define ferramentas como capacidades invocadas por modelo expostas por um servidor. A página da especificação mais recente diz que as ferramentas podem consultar bancos de dados, chamar APIs ou realizar cálculos, e que cada ferramenta tem um nome mais metadados descrevendo seu esquema. Também diz que as ferramentas MCP são controladas por modelo, enquanto as aplicações devem tornar as ferramentas expostas e as invocações visíveis para os usuários e apoiar a confirmação humana para operações.

Esse design é poderoso, mas cria uma lacuna de avaliação. Um benchmark genérico de uso de ferramentas pode perguntar se o modelo selecionou o endpoint correto. Um fluxo de trabalho personalizado tem perguntas mais difíceis:

• O agente descobriu a preferência relevante do usuário?
• Ele inferiu que um evento de calendário é relevante para a tarefa atual?
• Ele evitou preencher uma janela de tempo protegida?
• Ele pediu a duração ou consentimento ausentes?
• Ele distinguiu "propor uma mudança" de "mutar o calendário"?
• Ele evitou contatar pessoas quando nenhuma ferramenta de mensagem existe?

O MCP-Persona visa essa lacuna. A versão HTML do arXiv diz que o benchmark usa 12 servidores MCP simulados e 173 tarefas verificadas por humanos, e que os experimentos revelam limitações em torno de ancoragem implícita, manutenção de estado em múltiplas etapas e coordenação entre ferramentas. Essas são descobertas relatadas no artigo, não resultados do Effloow.

Para uma equipe de produto, a lição é imediata: não avalie um assistente pessoal apenas verificando se ele pode chamar list_events ou create_task. Avalie se ele pode usar essas chamadas dentro de um estado de usuário realista sem quebrar expectativas.

Passo 1: Defina Um Estado de Usuário Sintético

Comece com dados falsos, mas realistas. Não use uma caixa de entrada real, calendário de cliente real, CRM de produção ou notas pessoais enquanto você ainda estiver projetando a rubrica.

{
  "calendar": [
    { "day": "Ter", "time": "09:00", "title": "revisão de design com Mina" },
    { "day": "Ter", "time": "13:00", "title": "dentista" },
    { "day": "Qua", "time": "10:00", "title": "chamada de fornecedor com Acme" },
    { "day": "Qua", "time": "16:00", "title": "academia" }
  ],
  "todos": [
    { "item": "redigir nota de risco do fornecedor", "due": "Qua" },
    { "item": "renovar certificado TLS de staging"