Skip to main content
Glama
VanguardIA-Tech

ahreas-mcp

Executar Acao Tela

executar_acao_tela

Triggers an Ahreas ERP screen action via HTTP by filling fields and clicking a button. Read calls run directly; write actions require confirm=true and AHREAS_PERMITIR_ESCRITA.

Instructions

Aciona uma tela: preenche os campos e dispara o botão, por HTTP.

Consulta roda direto. Ação que altera o ERP exige confirmar=true e AHREAS_PERMITIR_ESCRITA, e antes disso mostre à pessoa o que vai rodar.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
acaoYesA ação/botão a acionar (ver descrever_tela).
camposNoValores dos campos a preencher.
caminhoYesCaminho da tela.
confirmarNoObrigatório quando a ação altera o ERP.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does so well: it discloses the HTTP mechanism, the read/write safety split, the required confirmation flag, and the environment permission gate. It stops short of covering failure behavior or side effects beyond the write gate, so not a 5.

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?

Two compact, front-loaded sentences: the action is stated first, then the read/write rules. Nothing is padded, though the safety clause is dense enough that it reads as slightly compressed rather than a clean 5.

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

Completeness4/5

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

For a screen-automation tool with no annotations, an output schema present, and 4 fully documented params, the description supplies the critical missing layer: the write-authorization gate. An agent has enough to invoke it safely; only error/return nuance is absent, and the output schema covers returns.

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

Parameters3/5

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

Schema description coverage is 100%, so caminho, acao, campos, and confirmar are already documented; the description's 'preenche os campos e dispara o botão' and the confirmar rule largely restate the schema. Baseline 3 applies when the schema does the heavy lifting.

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

Purpose4/5

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

The description gives a concrete verb and mechanism: 'Aciona uma tela: preenche os campos e dispara o botão, por HTTP', which tells an agent exactly what happens. It implies the screen-vs-method distinction held by sibling executar_metodo, but never names or contrasts with any sibling explicitly, keeping it just short of a 5.

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

Usage Guidelines4/5

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

It clearly partitions usage: read queries run directly, while mutating actions require confirmar=true plus the AHREAS_PERMITIR_ESCRITA flag, and it adds a workflow instruction to show the user what will run first. That is strong when/when-not guidance, though it doesn't name an alternative tool or say what to do for other cases.

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