Faz um GET em qualquer rota REST da instalação Protheus conectada. Use para as APIs oficiais que não têm tool dedicada (descubra a rota com protheus_catalogo) e para os endpoints MVC customizados que a empresa criou. Somente leitura.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| path | Yes | ||
| order | No | ||
| expand | No | ||
| fields | No | ||
| filter | No | ||
| params | No | ||
| account | No | ||
| page_size | No | ||
| sql_filter | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
As annotations já declaram readOnlyHint=true, destructiveHint=false e idempotentHint=true. A descrição adiciona que a operação é GET e somente leitura, reforçando as annotations, mas não oferece contexto comportamental extra, como formato de resposta, paginação ou limitações de uso. Sem contradição, mas sem grande valor adicional além das annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Duas frases curtas, sem repetição do nome da tool e com a informação essencial no início. Cada frase contribui: a primeira define a operação e o alvo; a segunda define quando usar e como descobrir a rota.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A ferramenta é genérica e complexa, com 10 parâmetros sem descrição e sem output schema. A descrição informa o propósito e a rota de descoberta, mas não explica os parâmetros de consulta, formato de resposta ou comportamento de paginação, deixando lacunas significativas para uma invocação correta.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
A cobertura descritiva do schema é 0% e a descrição não explica nenhum dos 10 parâmetros (path, page, order, expand, fields, filter, params, account, page_size, sql_filter). O único indício é 'rota', que se mapeia a path, mas o restante fica totalmente sem semântica para o agente.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
A descrição usa verbo específico (GET), recurso específico (qualquer rota REST do Protheus) e escopo claro, diferenciando-se das tools dedicadas. Menciona explicitamente APIs oficiais sem tool dedicada e endpoints MVC customizados, o que permite distinguir de imediato de protheus_catalogo e demais siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
A descrição diz explicitamente quando usar (APIs oficiais sem tool dedicada e endpoints MVC customizados), quando não usar (APIs que já têm tool dedicada) e orienta a descobrir a rota com protheus_catalogo. Isso fornece orientação de seleção clara e acionável.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each protheus_* tool targets a distinct ERP entity or API, and descriptions explain the resource and key arguments, so an agent can usually pick the right one. The main ambiguities are the generic protheus_api, which overlaps with every dedicated reader, and the trio protheus_catalogo/protheus_diagnostico/protheus_modulos, all of which are about API/module availability.
The domain tools consistently use the protheus_ prefix in snake_case with a descriptive resource suffix, which is predictable once the pattern is recognized. There are minor deviations such as protheus_list_accounts using an English verb and the platform-level tools (authenticate, connect, marketplace, show_version, toolkit_info) not following the protheus_ prefix at all.
32 tools is above the threshold where a tool list becomes heavy for agents to scan, even though the ERP domain is broad. The set could be split into a focused Protheus reader plus a platform-management server, or several entities could be combined behind parameterized tools.
The read-only surface covers a wide range of common Protheus areas (customers, products, stock, sales, production, pricing, CRM) and protheus_api with catalogo/diagnostico allows access to additional official/custom read routes. However, there are no create/update/delete tools at all, and major ERP areas such as financial movements and HR are absent, so mutation workflows dead-end in this server.