Skip to main content
Glama

computador

Operate desktop applications by inspecting the screen and using a real mouse and keyboard, including programs a browser cannot reach. Click, type, drag, and verify each action.

Instructions

Vê a tela e usa o mouse e o teclado de verdade. Use para programas do computador e para o que o browser não alcança; tarefa num site vai melhor pelo browser.

Oriente-se com ver e marcar: true: o print vem com um número em cada elemento. Para conferir um passo pequeno, elementos lista os mesmos itens em texto, sem imagem. Mire pelo número (elemento: n); sem número, pela coordenada do print, nunca por palpite. ler traz o texto da janela da frente; com procurar, só as linhas com o termo.

Depois de cada gesto vem um veredito: confirmado (não repita), mudou (confira em mudou se foi o esperado), sem_efeito_aparente (não repita; siga o proximo) ou nao_da_para_confirmar (confira no print). na_janela diz onde o gesto caiu: se não é o programa pedido, foi no lugar errado.

Programas: programas com nome diz se está aberto, na bandeja ou instalado. Aberto, focar com parte do título; fechado, abrir com o nome do menu Iniciar. App que acabou de abrir pode ficar atrás: confira em janelas antes de abrir de novo. Programa com abas (Bloco de notas, navegador) pode abrir na janela da pessoa: para não mexer no que é dela, abra uma janela nova pelo atalho do programa. fechar com parte do título fecha a janela, como o X; o programa ainda pergunta se quer salvar.

Texto: clique no campo e use digitar. ritmo: natural (pausas de mão, para site), rapido ou instantaneo (tudo de uma vez, para app local), automatico (padrão: rápido nos editores, natural no resto). Na barra de endereço do navegador, aperte delete antes do enter, ou ele completa com outra página do histórico. tecla aperta uma combinação (ctrl+s), segura com segurar ou manda uma sequencia. invocar e definir_valor agem no controle pela acessibilidade, sem mouse.

Quando já sabe o caminho, mande os gestos seguidos na mesma resposta; se um falhar, os seguintes não rodam.

Jogo, editor de imagem e modelagem desenham a tela: a lista vem quase vazia e o print orienta. ver com regiao amplia um pedaço pequeno; esperar com ate_mudar espera a animação em vez de adivinhar o tempo; arrastar e rolar aceitam botao e com (modificadores).

Para navegar pela tela, use o Chrome que o campo navegador do primeiro resultado indica. Carrossel e menu animado andam um clique por vez.

Sempre: código no celular e login passam para a pessoa com pedir_a_pessoa, e aí tudo é recusado até ela devolver. O primeiro gesto de cada turno pede aprovação. Fale com a pessoa pelo dizer, que aparece na moldura, e chame encerrar quando parar de usar a tela.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNoCoordenada no print (clicar, mover, arrastar, rolar).
yNoCoordenada no print.
comNoEm `arrastar` e `rolar`, modificadores segurados durante o gesto, como `shift` ou `ctrl+alt`.
acaoYes
nomeNoEm `programas`, o programa procurado (diz se roda sem janela e se está instalado); em `abrir`, o nome do programa como aparece no menu Iniciar.
botaoNoEm `arrastar`, o botao do mouse (padrao esquerdo).
dizerNoEm qualquer acao, uma frase curta (ate 120 caracteres) que aparece na caixinha da moldura para a pessoa, que nao ve o chat enquanto voce usa a tela.
pausaNoEm `tecla` com `sequencia`, segundos entre uma tecla e a outra (padrao 0,15).
ritmoNoEm `digitar`: automatico (padrao) acelera editores locais conhecidos e usa pausas naturais nos demais programas; rapido envia teclas com pausa curta; instantaneo manda o texto inteiro de uma vez; natural digita caractere por caractere com pausas variaveis.
teclaNoEm `tecla`, a combinacao, como `ctrl+s` ou `enter`.
textoNoEm `digitar`.
valorNoEm `definir_valor`, o texto do campo ou o nome da opcao da lista.
depoisNoComo conferir o gesto. `texto` (padrao) volta a lista de elementos, e o print so quando a janela nao se descreve.
janelaNoEm `focar` e `fechar`, parte do titulo da janela, como aparece em `janelas`.
marcarNoEm `ver`, numera os elementos da janela no print; vale para os prints seguintes do turno.
motivoNoEm `pedir_a_pessoa`, o passo que e da pessoa (ex. fazer login no portal).
para_xNoEm `arrastar`, o destino no print.
para_yNoEm `arrastar`, o destino no print.
regiaoNoEm `ver`, so este pedaco, ampliado para ler (menu de jogo, painel de editor); em `esperar` com `ate_mudar`, so este pedaco e vigiado. No espaco do print.
direcaoNo
segurarNoEm `tecla`, quantos segundos a combinacao fica apertada (maximo 10), para andar ou correr num jogo; solta sozinha no fim.
contextoNoEm `ler` com `procurar`, quantas linhas antes e depois de cada achado (padrao 1, ate 6).
elementoNoO numero observado na ultima leitura (`elementos` ou `ver` com `marcar`), sempre a partir de 1; nunca use 0. Obrigatorio em `invocar` e `definir_valor`.
procurarNoEm `ler`, so as linhas com este termo (como "R$"), cada uma com a de antes e a de depois: le a janela inteira e devolve o que interessa.
segundosNoEm `esperar` (maximo 30).
ate_mudarNoEm `esperar`, volta assim que a tela (ou a `regiao`) mudar, ate `segundos`.
sequenciaNoEm `tecla`, varias teclas em ordem numa chamada, como ["direita", "direita", "z"]; "cima:0.6" segura 0,6 s. Ate 40 teclas.
quantidadeNoEm `rolar`, cliques de roda (padrao 3).
ver_depoisNoAntigo; `depois` manda. Falso e o mesmo que `depois: nada`, verdadeiro o mesmo que `depois: print`.
confiar_no_printNoEm clique ou arrasto por coordenada depois de outros gestos: confirma que a tela em volta do alvo mudou porque você esperava (pintar sobre o que acabou de desenhar).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description carries the full behavioral burden and does so richly. It discloses post-gesture verdicts (`confirmado`, `mudou`, `sem_efeito_aparente`, `nao_da_para_confirmar`), the `na_janela` placement check, approval requirements for the first gesture each turn, refusal of all actions after `pedir_a_pessoa` until the human returns, and special behaviors like apps opening behind or programs opening in the person's window. It also explains that `fechar` behaves like the X and that programs may still ask to save.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but front-loaded: it opens with what the tool does and when to use it before moving into workflow details. Each paragraph has a clear theme (orientation, verdicts, programs, text, games, approval), and most sentences add distinct operational value. It is slightly dense and could use tighter grouping, but the length is defensible for a 30-parameter computer-control tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 30 parameters, no annotations, no output schema, and high schema coverage, the description supplies the missing behavioral and workflow context. It covers approval, human handoff with `pedir_a_pessoa`, communication via `dizer`, when to call `encerrar`, and special cases like games, carousels, and animated menus. Nothing essential for correct invocation appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 93%, so the baseline is 3, but the description adds practical usage semantics beyond the schema. It explains how to orient with `ver` and `marcar: true`, to target by `elemento: n` or by screenshot coordinates rather than guessing, and to use `ritmo` differently for websites versus local apps. It also notes browser-address-bar behavior (press `delete` before `enter`) and batching gestures in one turn with failure halting subsequent gestures, which enriches several parameters beyond their schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a concrete verb and resource: it sees the screen and uses real mouse and keyboard. It immediately distinguishes this tool from the sibling `browser`, saying site tasks are better handled there and this tool covers what the browser cannot reach. An agent can tell it apart from `browser` and `gravacao` without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool versus the alternative: for computer programs and anything the browser does not reach, while website tasks should go through `browser`. It also gives detailed routing guidance for sub-actions like `ver` with `marcar: true`, `elementos`, `ler` with `procurar`, `focar` versus `abrir`, and `pedir_a_pessoa` for login or phone-code steps. When-not conditions are covered through the handoff to the human and the browser alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools