Cadastro Ambiental Rural: Demonstrativo, consulta em fonte oficial. Hospedado pela plataforma, sem credenciais da plataforma, pague por consulta com crédito pré-pago. Consulta informação de fontes e órgãos oficiais brasileiros (a mesma disponível ao cidadão), não é dado sigiloso. O cliente é o controlador dos dados e responde pela finalidade legítima (LGPD).
| Name | Required | Description | Default |
|---|---|---|---|
| car | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't contradict themanding these are safe read operations. The description adds useful context: it confirms it's not confidential data must mention LGPD control responsibilities, which is beyond the annotations. However, it doesn't detail rate limits, pagination, or error behavior, but given the annotation coverage, a 3 is fair.
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?
The description is one long paragraph of three sentences. It includes essential context (official source, prepaid credits, LGPD) but is front-loaded with the tool name in the first sentence, which is redundant. It could be split into bullet points or shorter sentences for readability. Every sentence adds value, but structure is not optimized.
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?
The tool is simple (one parameter, no output schema), so the description doesn't need to explain much. However, it omits critical information: the format of 'car' (although obvious to Brazilian domain), what data is returned, and any legal or usage caveats beyond LGPD. Given that annotations cover safety, the description should still specify the input format and response nature, which are missing.
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?
The input schema has only one parameter 'car' with no description, and schema_description_coverage is 0%. The description does not explain what 'car' is (presumably the CAR code) or give any format example. The description adds no semantic meaning beyond the placeholder name, leaving the agent guessing about the required data.
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?
The description says it is a 'Cadastro Ambiental Rural: Demonstrativo, consulta em fonte oficial.' It clearly identifies the resource (CAR demonstrativo) and that it queries an official source, but the verb 'consulta' (consult/query) is generic and doesn't specify whether it fetches a report, calculates a value, or retrieves a document. It distinguishes from siblings by being the only one about CAR, but the exact action remains vague.
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?
The description mentions it's hosted on the platform, requires prepaid credits, and queries official Brazilian sources, but it does not specify when to use this tool versus alternatives. There are no sibling tools for data queries, so there is no guidance on selection, and no prerequisites (e.g., need for valid CAR code) or exclusion conditions are stated.
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.
As ferramentas têm funções majoritariamente distintas: autenticação, consulta, conexão, marketplace, suporte, versão e estado do toolkit. Há alguma ambiguidade entre connect/authenticate e entre marketplace/toolkit_info, mas as descrições permitem separar os usos.
Os nomes alternam entre verbos simples, verbos com complemento, substantivos compostos e a estrutura híbrida em português `car_demonstrativo_consultar`. Ainda assim, são legíveis e no geral seguem separação por underscore, o que evita caos total.
São 7 ferramentas, mas apenas `car_demonstrativo_consultar` é realmente do domínio Cadastro Ambiental Rural; as demais são utilitárias genéricas da plataforma MCP. O número total é aceitável, mas o conjunto é desbalanceado para um servidor que deveria ser centrado no domínio.
A operação principal de consulta existe e cobre a necessidade imediata de acesso ao demonstrativo. Porém, não há ferramentas complementares para detalhamento, listagem, status ou variações da consulta CAR, e o servidor fica razoavelmente raso para a amplitude do nome 'Cadastro Ambiental Rural'.