Chame o MyTools diretamente com WebMCP

O WebMCP é um padrão web emergente que permite a uma página entregar a um agente de IA uma lista de funções chamáveis em vez de uma tela para interpretar. A página registra ferramentas em document.modelContext — cada uma com nome, descrição e um schema JSON — e um agente rodando naquele navegador consegue listá-las e chamá-las.

O MyTools registra três ferramentas globais em todas as páginas e mais três em cada uma das suas 55 páginas de ferramenta: ler o estado, executar a operação, salvar o resultado. O trabalho continua acontecendo no navegador, na máquina do próprio usuário. O WebMCP muda quem aperta o botão, não para onde vai o arquivo.

Onde isso funciona e quão consolidado está

O navegador do ChatGPT já chama essas ferramentas hoje. A OpenAI adicionou suporte a WebMCP ao navegador embutido no aplicativo de desktop do ChatGPT, então as ferramentas abaixo já podem ser chamadas ali sem flag, sem token de trial e sem nenhuma configuração do seu lado. O MyTools já foi conduzido assim no mundo real: uma falha específica desse navegador foi relatada por alguém cujo agente já estava usando essas ferramentas, e corrigida em agosto de 2026.

No Chrome, é um origin trial. O trial vai do Chrome 149 ao Chrome 156, mais ou menos até o fim de 2026. O MyTools carrega um token para a sua origem de produção, então, num Chrome compatível, as ferramentas aparecem sem precisar ativar nenhuma flag. Se o trial terminar sem que a API seja lançada de vez, document.modelContext some do Chrome e essas ferramentas vão junto — e é por isso que o ponto de entrada por URL descrito abaixo não vai a lugar nenhum.

A especificação é um rascunho, não um padrão ratificado. O WebMCP é um Draft Community Group Report do W3C Web Machine Learning Community Group, editado por engenheiros da Google e da Microsoft, e explicitamente fora do processo de padronização do W3C. O formato já mudou uma vez: as ferramentas eram registradas em navigator.modelContext antes de a API migrar para document.modelContext. Se você estiver trabalhando com material mais antigo, confira isso primeiro.

Detecte o recurso, não presuma. Ou document.modelContext está lá, ou não está — e, com mais de uma implementação chegando no seu próprio ritmo, esse é o único teste que vale a pena fazer. Nunca inspecione o user agent para descobrir isso. Onde ele falta, nada neste site quebra: as ferramentas simplesmente não existem e todas as páginas continuam funcionando como páginas.

Existe uma alternativa que funciona em todo lugar. Onde o WebMCP não está disponível, conduza o site pelo ponto de entrada por URL: 50 das 55 ferramentas abrem com o arquivo já carregado a partir de uma URL que você mesmo monta. Os dois mecanismos cobrem as mesmas operações; o que muda é só a ergonomia.

Para testar localmente, num Chrome sem o token do trial, ative chrome://flags/#enable-webmcp-testing.

Leitura complementar — O rascunho da especificação · A documentação do WebMCP no Chrome

Três ferramentas em todas as páginas

Elas são registradas em todo o site, inclusive em páginas que não são ferramentas — a página inicial, um artigo, esta página. É por elas que um agente encontra o caminho até a ferramenta certa.

find_mytools_tools — Busca no catálogo. Aceita query, category, inputType e limit, todos opcionais, e devolve as ferramentas correspondentes com o seu slug, o caminho da página e se aceitam a URL de um arquivo. Somente leitura. A saída tem um teto de tamanho, então refine a busca em vez de pedir tudo.

open_mytools_tool — Abre uma ferramenta, pronta para usar. Aceita slug — obrigatório, como devolvido por find_mytools_tools — mais urls, opcional, para carregar arquivos remotos direto, e carryResult, que entrega à ferramenta aberta os arquivos que a ferramenta atual acabou de produzir, em vez de cair numa tela de upload vazia.

suggest_mytools_pipeline — A partir do slug de uma ferramenta e dos nomes dos arquivos que ela produziu, lista as ferramentas para onde esses arquivos podem ir em seguida. Só voltam destinos compatíveis: um lote nunca é oferecido a uma ferramenta de arquivo único, e nenhuma ferramenta recebe um formato que não consegue abrir.

Mais três em cada página de ferramenta

Todas as 55 ferramentas trazem o mesmo trio, nomeado a partir do slug da ferramenta com os hifens trocados por sublinhados. Em /pdf/rotate-pdf, são get_rotate_pdf_state, run_rotate_pdf e download_rotate_pdf.

get_<tool>_state — O que está carregado, como estão as configurações e uma dica indicando qual chamada fazer em seguida. Leia antes de executar qualquer coisa: é daí que vêm a contagem de páginas, as durações e as dimensões em pixels — são elas que dão sentido aos argumentos.

run_<tool> — Faz o trabalho. Os argumentos variam de ferramenta para ferramenta e estão descritos no schema de cada uma; o que você omitir mantém o que já está definido na tela. A chamada só retorna quando a operação termina, então não há nada para ficar consultando — numa codificação de vídeo longa, ela simplesmente demora o tempo da codificação.

download_<tool> — Salva o resultado no dispositivo do usuário. Só é registrada quando já existe um resultado, então a presença dela na lista de ferramentas é o sinal de que o trabalho terminou. As ferramentas que produzem vários arquivos aceitam index para salvar um deles, ou zip para salvar todos num único arquivo compactado.

Três ferramentas terminam numa URL publicada em vez de um arquivo — as duas de publicação no Facebook e a de upload para o YouTube — e por isso não registram nenhuma ferramenta download. Elas também se recusam a agir quando ninguém está autenticado: o login abre um popup que só um clique real consegue abrir.

Um exemplo completo

Girar um PDF que está numa URL, do início ao fim. Todas as respostas abaixo são a saída real dessas ferramentas, não um esboço.

find_mytools_tools({ query: "rotate pdf", inputType: "application/pdf", limit: 3 })

→ { "total": 55, "matched": 1, "tools": [
      { "slug": "rotate-pdf", "title": "Rotate PDF",
        "description": "Rotate PDF pages in one click",
        "multiple": true, "byUrl": true } ] }

open_mytools_tool({ slug: "rotate-pdf",
                    urls: ["https://example.com/rental-application.pdf"] })

→ "Opened Rotate PDF with 1 file(s) loading from URL. Everything is processed
   locally in the browser. The page-specific tools available to you have changed."

get_rotate_pdf_state({})

→ { "phase": "configure",
    "pdfs": [ { "name": "rental-application.pdf", "pages": 2, "rotations": [0, 0] } ],
    "saving": false, "result": null,
    "hint": "Call run_rotate_pdf with a rotation, optionally narrowed with pages,
             to turn the loaded PDFs." }

run_rotate_pdf({ rotation: 90 })

→ "Rotated 1 PDF(s) by 90°. Call download_rotate_pdf to save it."

download_rotate_pdf({})

→ "Saving rental-application-rotated.pdf to the user's device."

Devolver a decisão ao usuário

Nem todo argumento deveria ser escolhido por você. Qual parte de uma foto manter, quais páginas de uma digitalização interessam, qual volume já é alto o suficiente — isso exige olhar o arquivo. Essas ferramentas foram desenhadas justamente para que você possa parar, deixar o usuário decidir e seguir em frente. get_<tool>_state relata o que está na tela naquele momento, inclusive uma mudança que o usuário acabou de fazer com o mouse, e todo argumento que você omitir em run_<tool> mantém o valor que está na tela. Omita todos e a execução usa exatamente o que ele definiu.

A ferramenta de recorte de imagem, com um arraste de verdade no meio do caminho:

get_crop_image_state({})

→ … "source": { "width": 6240, "height": 4160 },
    "selection": { "x": 1459, "y": 420, "width": 3330, "height": 3328 }

    ← the user drags the box over what they want to keep

get_crop_image_state({})

→ … "selection": { "x": 2910, "y": 831, "width": 3330, "height": 3329 }

run_crop_image({})

→ "Cropped to 3330×3329 pixels out of 6240×4160 (5507 KB, image/jpeg).
   Call download_crop_image to save it."

Diga o que você precisa no mesmo turno em que abre a ferramenta — "arraste a caixa sobre a parte que você quer manter e depois me avise para seguir" — e leia o estado de novo quando ele responder. Nada na página fica travado enquanto você espera; o usuário está trabalhando numa aba comum do navegador.

É aqui que passa a linha entre uma página de ferramenta e uma API. O trabalho que ninguém precisa olhar pertence a uma chamada de API, e colocar um navegador na frente dele seria puro overhead. Uma página se justifica quando alguém precisa ver o arquivo para decidir alguma coisa — e o WebMCP é o que mantém o agente útil nesse momento, cuidando de carregar, medir, converter e salvar dos dois lados de um julgamento que não cabe a ele fazer.

Quatro coisas que moldam o comportamento delas

A saída tem um teto de cerca de 1500 caracteres. Ou seja, uma resposta de estado é um resumo, não um despejo de dados. Listas longas são cortadas no fim e marcadas como cortadas, e o conteúdo dos arquivos nunca aparece nelas. Se você precisa do catálogo inteiro em vez de um resultado de busca, busque o capabilities.json.

Nenhum byte atravessa a fronteira. Você não tem como entregar um arquivo a uma ferramenta e nunca recebe nenhum. Os arquivos entram por uma URL que o navegador busca e saem por download_<tool>, que dispara um download comum do navegador para a máquina do usuário. Tudo o que você troca com essas ferramentas é texto.

As chamadas podem ser canceladas. Cada execução recebe um AbortSignal. Cancelar uma execução interrompe o trabalho em vez de deixá-lo órfão — uma codificação de vídeo é encerrada, não fica rodando num worker — e o retorno é um cancelamento, não uma falha.

A lista de ferramentas muda conforme você navega. Só as ferramentas da página atual ficam registradas. Abrir outra ferramenta cancela o registro do trio da página anterior e registra o novo, então releia a lista de ferramentas depois de cada open_mytools_tool em vez de supor que o que você viu antes continua lá.

Perguntas que vale a pena ter respondidas

Voltar para MyTools para agentes de IA