DETRAN MA: Licenciamento, 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 |
|---|---|---|---|
| placa | Yes | ||
| renavam | Yes |
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?
Annotations already indicate readOnly, idempotent, and non-destructive. The description adds value by disclosing payment requirements (prepaid credit) and LGPD data controller responsibilities, which are not in annotations. No contradictions.
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 a single paragraph of moderate length. It front-loads the core purpose but then adds legal and payment details that, while relevant, could be more concise. It is not overly verbose but lacks a clear, structured breakdown.
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?
For a simple read-only query tool with two params and no output schema, the description covers payment, legal responsibility, and official source. However, it fails to explain the parameters (placa and renavam) and what the response contains, leaving gaps for an agent to understand expected inputs and outputs.
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?
Schema has 2 required string parameters (placa, renavam) with 0% description coverage. The tool description provides no explanation of these parameters, leaving the agent without any semantic guidance. For a 0% coverage case, the description must compensate, and it does not.
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 clearly states the tool queries licensing information from DETRAN MA, an official source. It distinguishes from siblings (which are platform utilities) by specifying the resource (licensing) and the verb (consultar). However, it could be more specific about what exact data is returned, so not a 5.
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 implies usage for querying official licensing data and mentions it requires prepaid credit. It does not explicitly say when to use it versus alternatives, nor does it provide exclusions. Siblings are unrelated, so context is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.