carpedia_historico_precoSérie histórica de preço FIPE de uma versão×ano-modelo, com variação e projeção de depreciação (sempre marcada como estimativa — é modelo estatístico do próprio Carpedia, não dado FIPE oficial).
| Name | Required | Description | Default |
|---|---|---|---|
| ano | Yes | Ano-modelo de 4 dígitos, ou "32000" para 0km. | |
| fipeId | Yes | Id da versão no catálogo Carpedia. |
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?
The description adds a valuable caveat beyond the annotations: the depreciation projection is always marked as an estimate, based on Carpedia's own statistical model, not official FIPE data. This is critical for setting agent expectations. Annotations already declare read-only and idempotent behavior, so the description focuses on the estimate disclosure.
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, dense sentence that front-loads the main purpose (historical series) and then adds the critical caveat about the estimate. It is efficient and contains no filler, though it packs several concepts together that could be slightly clearer if split.
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?
With no output schema, the description carries the burden of explaining the return. It mentions the series, variation, and depreciation projection, which covers the key output components. However, it does not specify the time granularity (e.g., monthly, yearly) or the exact structure of the series, which could leave an agent uncertain about the response format. Given the tool's relative simplicity, this is acceptable but not fully complete.
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?
Both parameters (fipeId and ano) are fully described in the schema with 100% coverage. The description references 'versão×ano-modelo', which maps to the parameters, but does not add additional format, constraints, or usage details beyond what the schema already provides. Baseline 3 is appropriate.
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 provides a historical FIPE price series for a specific version-year model, including variation and depreciation projection. This differentiates it from the sibling carpedia_preco_fipe, which likely provides the current price. The mention of 'versão×ano-modelo' ties directly to the parameters.
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?
Usage is implied by the description: one would use this tool when needing historical price data or depreciation projections. However, there is no explicit guidance on when to prefer this over carpedia_preco_fipe or other siblings, and no when-not-to-use exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.