Skip to main content
Glama

UPí — upCampo

by br.com.upcampo
OverviewDiscussionsAdmin

Cadastros

consultar_cadastros
Read-only

Os cadastros da fazenda — safras, culturas, variedades, talhões, plantio, tipos de atividade, pluviômetros, locais de estoque, classes, produtos e fornecedores —, com os ids que as tools cadastrar_* pedem para alterar e para ligar um cadastro ao outro. A visão andamento mostra o que a fazenda já tem: é por ela que se começa uma implantação.

Visões disponíveis (parâmetro "visao"):

  • andamento: Uma linha com a contagem de cada cadastro da fazenda. Ordem da implantação: safra → cultura → variedade → talhão (e o mapa do talhão) → plantio → tipo de atividade → subtipo → pluviômetro → local de estoque → classe → produto → fornecedor → tipo de equipamento → equipamento → funcionário → estoque inicial (lancar_entrada_nota, Entrada avulsa). O próximo passo é o primeiro que estiver zerado. Filtros: nenhum.

  • safras: Safras da empresa, com período e quantos talhões plantados cada uma tem. Filtros: nome.

  • culturas: Culturas da empresa. DA_BASE_UPCAMPO: veio da base da upCampo, com estágios. Filtros: nome.

  • variedades: Variedades da fazenda, com a cultura de cada uma. Filtros: nome, cultura.

  • talhoes: Talhões da fazenda, com área (ha), setor, quantos plantios em andamento e se já têm MAPA DO TALHÃO (TEM_MAPA; CENTRO_LATITUDE/CENTRO_LONGITUDE é o ponto do talhão). Filtros: nome, setor.

  • plantios: O que está plantado em cada talhão, por safra: cultura, variedade, área e data. VARIAS_VARIEDADES: o talhão tem mais de uma variedade (mantido pelo portal). Filtros: safra, nome, cultura, aceita período.

  • tipos_atividade: Tipos de atividade da fazenda, com a categoria, a natureza (plantio, colheita, aplicação…) e o que a execução da OS exige. Filtros: nome, natureza.

  • pluviometros: Pluviômetros da fazenda, um por linha, com os talhões que cada um cobre. Filtros: nome.

  • locais: Locais de estoque da fazenda, com quantos produtos têm saldo em cada um. Filtros: nome.

  • classes: Classes de produto da empresa, com quantos produtos cada uma tem. Filtros: nome.

  • produtos: Produtos da empresa, com unidade e classe. Filtros: nome, classe. Lista no máximo 100 linhas por chamada.

  • entidades: Fornecedores, clientes e demais entidades da empresa. DOCUMENTO é o CPF ou CNPJ como está gravado (os antigos podem ter máscara). Filtros: nome, documento, fornecedor. Lista no máximo 100 linhas por chamada.

  • tipos_equipamento: Tipos de equipamento da empresa, com quantos equipamentos a fazenda tem de cada. Filtros: nome.

  • equipamentos: Máquinas, veículos e implementos da fazenda, com tipo, medidor, última leitura e placa. IMPLEMENTO distingue implemento de máquina. Filtros: nome, tipo, placa. Lista no máximo 100 linhas por chamada.

  • subtipos: Subtipos (Identificação Resumida) da fazenda, com a etapa e os tipos de atividade em que cada um vale. QTDE_TIPOS_ATIVIDADE 0: não está vinculado a nenhum tipo. Filtros: nome, tipo_atividade.

  • funcionarios: Funcionários da fazenda, com função e contato. Filtros: nome, funcao.

Quando "visao" não é informada, usa "andamento". Filtro de texto casa por trecho, sem diferenciar maiúsculas nem acento ("aplicacao" acha "Aplicação") — exceto os marcados "(valor exato)", que exigem o valor inteiro, como código, placa e número. A resposta traz "total_disponivel": quantas linhas o filtro encontra ao todo. Chame uma vez só, já com o limite que a resposta vai usar — nunca repita a consulta mudando só o limite; se só o número interessa e o total pode ser grande, um limite baixo basta.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nomeNoNome da safra. Vale nas visões: safras, culturas, variedades, talhoes, plantios, tipos_atividade, pluviometros, locais, classes, produtos, entidades, tipos_equipamento, equipamentos, subtipos, funcionarios.
tipoNoTipo do equipamento. Vale nas visões: equipamentos.
placaNoPlaca, ou parte dela. Vale nas visões: equipamentos.
pularNoLinhas a pular, para ler um resultado grande em partes. Use com limite quando total_disponivel for maior que o que veio.
safraNoNome da safra. Vale nas visões: plantios.
setorNoNome do setor. Vale nas visões: talhoes.
visaoNoQual recorte consultar. Padrão: andamento.
classeNoNome da classe. Vale nas visões: produtos.
funcaoNoFunção. Vale nas visões: funcionarios.
limiteNoMáximo de linhas devolvidas. Padrão 100, teto 500.
culturaNoNome da cultura. Vale nas visões: variedades, plantios.
fazendaNoNome da fazenda. Omita para usar a fazenda corrente do usuário — é o padrão, e é o que o usuário espera quando não cita nenhuma. Informe apenas quando ele nomear outra fazenda. Cada consulta trata de uma fazenda por vez.
naturezaNoPlantio, Colheita, Aplicação, Adubação, Preparo de solo… Vale nas visões: tipos_atividade.
documentoNoCPF ou CNPJ, ou parte dele. Vale nas visões: entidades.
data_finalNoFim do período, inclusive, em dd/mm/aaaa ou aaaa-mm-dd.
fornecedorNoSó fornecedores. Vale nas visões: entidades.
data_inicialNoInício do período, em dd/mm/aaaa ou aaaa-mm-dd.
tipo_atividadeNoTipo de atividade em que o subtipo vale. Vale nas visões: subtipos.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
totalYesLinhas devolvidas nesta resposta.
visaoYes
avisosNoO que o servidor aplicou sem ser pedido, como um período padrão.
linhasYes
fazendaYes
truncadoYestrue quando há mais linhas além das devolvidas.
total_disponivelYesQuantas linhas o filtro encontra ao todo, qualquer que seja o limite pedido.
filtros_ignoradosYesFiltros que não existem na visão escolhida e por isso não foram aplicados.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / nome / description
      Previous value: -"Nome da safra. Vale nas visões: safras, culturas, variedades, talhoes, plantios, tipos_atividade, pluviometros, locais, classes, produtos, entidades, tipos_equipamento, equipamentos, funcionarios."New value: +"Nome da safra. Vale nas visões: safras, culturas, variedades, talhoes, plantios, tipos_atividade, pluviometros, locais, classes, produtos, entidades, tipos_equipamento, equipamentos, subtipos, funcionarios."
    • addedInput schema / properties / tipo_atividade
      Added value: +{
+  "description": "Tipo de atividade em que o subtipo vale. Vale nas visões: subtipos.",
+  "type": "string"
+}
    • changedInput schema / properties / visao / enum
      Previous value: -[
-  "andamento",
-  "safras",
-  "culturas",
-  "variedades",
-  "talhoes",
-  "plantios",
-  "tipos_atividade",
-  "pluviometros",
-  "locais",
-  "classes",
-  "produtos",
-  "entidades",
-  "tipos_equipamento",
-  "equipamentos",
-  "funcionarios"
-]New value: +[
+  "andamento",
+  "safras",
+  "culturas",
+  "variedades",
+  "talhoes",
+  "plantios",
+  "tipos_atividade",
+  "pluviometros",
+  "locais",
+  "classes",
+  "produtos",
+  "entidades",
+  "tipos_equipamento",
+  "equipamentos",
+  "subtipos",
+  "funcionarios"
+]
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses filter-matching behavior (substring match, case- and accent-insensitive, except '(valor exato)' fields like código/placa/número), that the response carries total_disponivel, that fazenda defaults to the user's current farm and one farm is queried per call, and explicit pagination advice ('Chame uma vez só… nunca repita a consulta mudando só o limite'). This is rich behavioral context that annotations alone cannot convey.

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?

It is long, but the length is largely earned by 16 distinct views; it is front-loaded with the resource inventory and the starting-view guidance, then bulleted per view. Some redundancy exists because the per-view 'Filtros:' lists duplicate what the schema already states for each parameter.

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?

With an output schema present, return values need not be re-explained, yet the description still flags total_disponivel and limit behavior. For a 0-required, 18-param, 16-view tool it covers view selection, filtering, defaults, and pagination thoroughly — an agent has everything needed to call it correctly.

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 coverage is 100%, so the schema already documents each parameter's applicable views; baseline would be 3. The description adds meaning by restating which filters apply per view and, more importantly, by explaining the text-filter matching semantics and the exato-marker exception that the schema does not encode.

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 description states a specific verb+resource and enumerates exactly which registries are covered (safras, culturas, variedades, talhões, plantio, produtos, fornecedores, etc.), plus its relationship to the cadastrar_* tools that consume the returned ids. An agent can immediately tell this is the read/registry-query tool and what data it exposes, rather than a create or operational tool.

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 gives strong internal routing guidance: default visao=andamento, that andamento is where an implementation starts, the recommended ordering of the rollout, and per-view filters. It does not explicitly state when NOT to use it or contrast against the sibling consultar_* tools (estoque, produção, frota), so it stops short of full when/when-not coverage.

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

All UPí — upCampo toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources