Search 1.8M+ live Brazilian used-car and motorcycle listings from 90+ marketplaces, with FIPE reference prices, price distributions and cheapest-state comparisons. No API key needed.
Scored across 17 tools
Each tool targets a distinct purpose: search, listing details, market analysis, catalog browsing, and specific queries like FIPE or mileage. Even overlapping tools like get_similar_active_listings and search_vehicles are clearly scoped with explicit usage guidance in descriptions.
All tool names follow a consistent verb_noun snake_case pattern (get_, list_, search_), making it predictable for an agent to infer function from name. No mixing of conventions or vague verbs.
17 tools is slightly above the typical 3-15 range but justified by the server's breadth: it covers search, listing retrieval, catalog navigation, market analytics, and specialized valuations. Each tool earns its place; no redundant or trivial tools.
The tool surface covers core workflows: searching, retrieving listing details, comparing prices, understanding market context, and accessing technical specs. Minor gaps like batch comparison or historical trend tools exist but are not essential for the primary use case of vehicle price analysis.
Sugere OUTROS MODELOS diferentes (outras marcas/modelos) na mesma categoria, faixa de preço e tipo de carroceria — alternativas de compra. Use para 'recomende outros modelos' / 'alternativas a este carro'. (max_results padrão 4, máx 6.)
| Name | Required | Description | Default |
|---|---|---|---|
| car_id | Yes | ||
| max_results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the constraint of suggesting different models within the same category/price/body type and notes max_results default 4 with a max of 6. This is useful context but does not deeply describe return behavior, so a 3 is appropriate.
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 two compact sentences that front-load the core purpose, then provide usage triggers and a parameter note. There is no fluff, and every word adds value.
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 tool with two parameters and no output schema, the description covers purpose, usage, and parameter constraints. It does not explicitly state that the result is a list of models, but the verb 'Sugere' implies it. This is adequate but could be slightly more explicit about the return format.
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 description coverage is 0%, so the description must compensate. It explains max_results with default and maximum, and the context 'alternativas a este carro' implicitly defines car_id as the reference car. Both parameters are meaningfully covered, though car_id is not explicitly described as an integer or its role beyond context.
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 verb 'Sugere' (suggests), the resource 'OUTROS MODELOS' (other models), and the filtering criteria (same category, price range, body type). It also provides concrete example user intents ('recomende outros modelos' / 'alternativas a este carro'), making it easy to distinguish from siblings like get_similar_active_listings.
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?
It explicitly says when to use the tool with example phrases, but it does not mention when not to use it or point to alternative tools. This gives clear usage context but lacks exclusions, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tempo médio (mediana) que anúncios semelhantes ficam ativos antes de sair do ar — estimativa de liquidez/tempo de venda. 'model_year' (padrão) = mesmo modelo e ano; 'model' = todos os anos; 'model_state' = neste estado.
| Name | Required | Description | Default |
|---|---|---|---|
| car_id | Yes | ||
| granularity | No | model_year |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds behavioral value by clarifying that the statistic is a median rather than a simple average and by defining the similarity scope per granularity value, which goes beyond the structured annotation data.
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 compact and front-loaded: the first sentence defines the metric and purpose, and the second sentence compactly maps enum values to their meaning. Every sentence earns its place with no filler or repetition of schema details.
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 metric with two parameters, the description is largely complete: it defines the statistic, the meaning of the configurable granularity, and the intended use case. Minor omissions such as sample-size caveats or output format are acceptable given the tool's low complexity and strong annotations.
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 description coverage is 0%, so the description carries the burden of parameter meaning. It does this well for granularity, explaining each enum value and the default; however, car_id is not described beyond its schema title, so the compensation is incomplete.
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 identifies the metric (median active days for similar listings) and the resource, and it distinguishes this tool from sibling market-analysis tools by focusing on liquidity/time-to-sell. The granularity definitions further sharpen what 'similar' means, removing ambiguity that could otherwise lead to misuse.
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 states the intended use case as a liquidity/sale-time estimate and explains what each granularity option means, so an agent can choose the correct level. It does not explicitly name alternatives or provide when-not-to-use guidance, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estados (UF) onde este modelo está mais barato agora, por preço mediano crescente. Use para 'onde é mais barato comprar'. (top_n padrão 5, máx 10.)
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | ||
| car_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: results are ordered by increasing median price, and top_n has a default of 5 with a max of 10. Annotations already declare read-only and idempotent, so the description enhances operational understanding. No contradiction exists.
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 compact sentence plus a parenthetical, covering purpose, usage, and operational limits. Every phrase earns its place, with no filler or redundancy.
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 tool with 2 simple parameters and no output schema, the description adequately conveys what it does, how results are sorted, and usage intent. It does not detail the return format, but the phrase 'por preço mediano crescente' implies a list of states with prices. This is sufficient for the tool's simplicity.
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 description coverage is 0%, so the description must compensate. It partially explains top_n (default 5, max 10) but does not explicitly describe car_id, leaving its meaning to inference from 'este modelo' (this model). This is a gap for a required parameter.
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 returns states (UF) where the car model is cheapest now, sorted by increasing median price. This specifies a concrete resource and action, and distinguishes it from siblings like get_market_stats or get_avg_days_to_sell which address different market aspects.
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?
It provides an explicit usage cue: 'Use para "onde é mais barato comprar"' (Use for 'where is cheapest to buy'), which tells the agent when to select this tool. However, it does not mention alternatives or explicitly say when not to use it, so it lacks that exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Valor oficial da tabela FIPE deste carro e tendência recente. Use para perguntas sobre a FIPE.
| Name | Required | Description | Default |
|---|---|---|---|
| car_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered without the description. The description adds that the tool returns official value and recent trend, but it discloses no additional behavioral caveats such as data sources, rate limits, or freshness constraints.
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 very short and front-loaded with the core purpose before the usage trigger. The second sentence is not waste, but it is somewhat broad; overall it is appropriately compact for a simple read-only tool.
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 one-parameter, read-only tool with no output schema, the description covers what the tool returns and gives a usage trigger. However, it leaves the car_id parameter underspecified and does not mention when not to use the tool, so an agent still has to infer part of the invocation contract.
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 description coverage is 0%, so the description must compensate, but it only says 'deste carro' and never explicitly explains what car_id means, how to obtain it, or that it must match a previously selected car. The parameter name car_id is self-explanatory up to a point, but the description adds almost no semantic value beyond that.
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 identifies a specific resource—official FIPE valuation for a given car—and adds that it includes recent trend, which distinguishes it from broader market-stat siblings. It lacks an explicit verb like 'get' or 'returns', but the noun phrase is still clear enough for an agent to know what the tool produces.
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?
'Use para perguntas sobre a FIPE' explicitly states when the tool should be used, which is a clear trigger for an agent. It does not name sibling alternatives or exclusions, so it doesn't meet the 5-level bar, but the context provided is meaningful and non-ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fatos do próprio anúncio (cor, portas, opcionais, vendedor, fonte, km, link). Use para perguntas diretas sobre este carro específico.
| Name | Required | Description | Default |
|---|---|---|---|
| car_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the specific ad-level facts included (color, doors, seller, source, km, link), which is useful context. It does not describe error behavior, response shape, or edge cases, but for a read-only single-ID getter this is acceptable.
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, front-loaded sentence that lists the relevant output fields first and then gives the usage directive. Every part earns its place, with no filler or redundant restatement of the tool name.
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?
Given the tool has only one required parameter and no output schema, the description provides enough information for an agent to invoke it correctly: it identifies the target ('este carro') and the expected content of the result. It could mention how this relates to get_vehicle_by_id or get_technical_specs, but the core usage is clear.
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 description coverage is 0%, so the description carries the burden for explaining car_id, but it never mentions the parameter directly. The phrase 'este carro específico' only weakly implies that car_id identifies the listing. The parameter name is self-explanatory, but the description adds no explicit meaning beyond the schema.
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 identifies the resource: 'Fatos do próprio anúncio' and lists concrete data fields (cor, portas, opcionais, vendedor, fonte, km, link). It also states the use case: direct questions about a specific car. However, it lacks an explicit verb and does not name or differentiate against the closest sibling tools such as get_vehicle_by_id or get_technical_specs.
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 gives a clear invocation context: 'Use para perguntas diretas sobre este carro específico.' This tells an agent when to select this tool. It does not provide exclusions or mention when a sibling would be more appropriate, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Posição de preço DESTE anúncio: vs. tabela FIPE e vs. o mercado de anúncios ativos do mesmo modelo. Use para 'esse preço é bom?' / 'está caro ou barato?'.
| Name | Required | Description | Default |
|---|---|---|---|
| car_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description adds useful context about the comparison baselines (FIPE and active same-model listings). It does not disclose output format, units, or possible edge cases, but for a safe read-only tool this is acceptable.
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 two short sentences, front-loads the core purpose, and includes memorable example questions. There is no redundant or filler content; every phrase adds value.
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 single-parameter read-only tool with clear annotations, the description is largely sufficient for correct invocation. It explains what the tool compares and when to call it. The only minor gap is the absence of any indication about how the result is returned or interpreted (e.g., percentage, above/below FIPE).
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?
There is only one parameter, car_id, and the schema description coverage is 0%. The description indirectly explains the parameter by referring to 'DESTE anúncio', implying that car_id identifies the listing. It adds some context beyond the bare schema, but it does not explicitly define car_id or its format.
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 identifies the tool's purpose: it returns the price position of a specific listing relative to the FIPE table and to active listings of the same model. The use-case phrasing ('esse preço é bom?') makes the intent concrete. It does not explicitly name sibling tools, but the focus on 'DESTE anúncio' versus market-wide tools provides implicit differentiation.
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 explicitly states when to use the tool: when the user asks whether a price is good, expensive, or cheap. It gives clear context and user-intent mapping. However, it does not mention when not to use it or point to alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live size of the PegaRex database: total active listings, number of source platforms, and when the data was last refreshed. Use this for the current count instead of quoting a fixed number.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by calling the data 'Live,' mentioning the refresh timestamp, and instructing the agent to use it for the current count instead of a stale figure.
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?
Two sentences with no filler: the first front-loads what the tool returns, and the second states when to use it. Every sentence earns its place.
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 zero-parameter, read-only stats endpoint, the description is complete: it lists the returned fields (active listings, platforms, last refresh) and gives the usage context. There is no output schema, but the description covers the return values sufficiently.
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 is empty with zero parameters, so there is nothing for the description to add beyond the schema. Per baseline for zero-parameter tools, 4 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 states a specific resource and output: 'Live size of the PegaRex database' with 'total active listings, number of source platforms, and when the data was last refreshed.' This is unambiguous and distinct from sibling tools like get_price_distribution or get_market_position, and the usage line 'current count instead of quoting a fixed number' clarifies what makes it different.
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?
It gives explicit context: 'Use this for the current count instead of quoting a fixed number.' This tells the agent when to select the tool, but it doesn't name alternatives or give exclusions beyond not relying on a fixed number.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Avalia se a quilometragem deste carro é alta ou baixa para o modelo/ano (mediana do mercado + km/ano).
| Name | Required | Description | Default |
|---|---|---|---|
| car_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds the methodology (market median + km/year) but does not describe the output format (e.g., returns 'high'/'low' or a numeric score). It provides some extra context beyond annotations but not full behavioral detail.
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, efficient sentence that front-loads the core purpose and adds the methodology in parentheses. No wasted words or redundant information.
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 tool with one parameter and no output schema, the description conveys the essential purpose and method. It lacks explicit return-value details and error conditions, but given the tool's simplicity and annotations, it is largely adequate. Slightly more detail on the output would make it 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?
Schema description coverage is 0%, so the description must compensate for parameter meaning. However, it does not explicitly mention car_id or explain its role beyond the tool name. The agent must infer that car_id identifies the car being evaluated, which is a gap for a single-parameter tool with no schema descriptions.
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's purpose: to assess whether a car's mileage is high or low for its model/year, using market median and km/year. It is specific and distinguishes from siblings by focusing solely on mileage context.
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 mileage evaluation but does not explicitly state when to prefer this over alternatives like get_market_position or get_market_stats. No exclusions or alternative routing are provided, leaving some ambiguity among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Faixa de preços (mínimo, p25, mediana, p75, máximo) de anúncios ativos semelhantes. Use para dar contexto de preço. (year_tolerance ±anos, padrão 1, máx 5.)
| Name | Required | Description | Default |
|---|---|---|---|
| car_id | Yes | ||
| year_tolerance | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds the exact output structure (min, p25, median, p75, max) and the year tolerance bounds, which goes beyond what annotations provide. There is no contradiction between description and 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?
The description is concise and front-loaded: it states the output, the intended use, and the key parameter constraint in two short sentences. Every element adds value without redundancy.
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 description includes the return values and the parameter bounds, which is sufficient for a tool with no output schema. It does not elaborate on what 'similar' means or any additional constraints, but for a price-context tool this is likely adequate. Minor gap: it does not clarify whether the results are based on the car_id alone or other criteria, but the annotation openWorldHint=false suggests closed-world behavior.
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 schema description coverage is 0%, so the description must compensate. It explains year_tolerance with default and max values, and it implies car_id is used to identify the vehicle for finding similar listings. While car_id is not explicitly described, its role is clear from the context of 'similar active listings.' This is adequate compensation given the tool's simplicity.
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 price range (min, p25, median, p75, max) for similar active listings. It also gives the intended use ('dar contexto de preço'). It does not explicitly differentiate from sibling tools like get_market_stats or get_fipe_valuation, but the focus on 'similar active listings' and the specific output quantiles makes its purpose distinctive.
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 gives an explicit usage context ('Use para dar contexto de preço') and provides parameter guidance for year_tolerance (default 1, max 5). It does not state when not to use this tool or name alternatives, but the provided context is sufficient for an agent to decide when this is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Outras unidades à venda do MESMO modelo (mesmo carro, outros anúncios) — ex.: mais baratas, outras cores/anos. Use para 'tem opções mais baratas DESTE carro?'. NÃO use para sugerir modelos diferentes. (max_results padrão 5, máx 8; cheaper_only=true só mais baratos que este.)
| Name | Required | Description | Default |
|---|---|---|---|
| car_id | Yes | ||
| max_results | No | ||
| cheaper_only | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, so the description adds value by disclosing the output scope (only same-model active listings), the max_results hard cap of 8 not present in the schema, and the effect of cheaper_only. It does not discuss response shape, but this is a minor gap for a read-only list tool.
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 compact and front-loaded: scope, example, trigger, exclusion, and parameter constraints each earn their place. The parenthetical packs parameter semantics without redundant filler.
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 3-parameter read-only tool with rich annotations, the description is complete enough for correct selection and invocation: it identifies the input car, optional result limits and filters, and what kind of listings are returned. No critical operational details 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?
With 0% schema description coverage, the description takes on the parameter burden: it explains max_results default 5 and max 8, and cheaper_only=true returns only listings cheaper than the given car. car_id is only implicitly described as 'DESTE carro', which is slightly thin but recoverable from the tool's context.
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 uses a specific verb+resource: it returns other units for sale of the same model/car, illustrated with examples like cheaper options and other colors/years. It also clearly differentiates from the sibling get_alternative_models by stating it must not be used to suggest different models.
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?
It provides an explicit positive trigger ('Use para ... DESTE carro?') and a clear exclusion ('NÃO use para sugerir modelos diferentes'), so an agent knows when to invoke this tool versus an alternative-models tool. No inference is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ficha técnica completa (motor, potência, torque, câmbio, consumo,
desempenho, dimensões, freios, pneus). section opcional restringe a uma
seção: 'Motor', 'Transmissão', 'Consumo', 'Desempenho', 'Dimensões',
'Freios', 'Pneus', 'Suspensão'.
| Name | Required | Description | Default |
|---|---|---|---|
| car_id | Yes | ||
| section | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile via readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to restate that. It adds useful behavioral context by explaining that `section` restricts the response to one named section, including the exact accepted values. However, it does not disclose response format, error behavior, or data freshness, which a bare read-only lookup could reasonably mention.
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 purpose ('Ficha técnica completa') before enumerating the data domains. The inline list of valid `section` values is necessary because the schema defines no enums, so it earns its place despite making the sentence somewhat long.
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?
This is a simple two-parameter read-only lookup, and the description adequately communicates the response content and the optional filtering behavior. The absence of an output schema is mitigated by the enumerated technical-spec domains, though exact return structure and validation behavior for invalid section names remain unspecified.
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 description adds meaningful detail for `section`, listing all valid values and explaining that it restricts the result to a single section, which the bare anyOf schema does not convey. However, `car_id`, the required parameter, is only identified by its name and type; with 0% schema description coverage, the required identifier deserves explicit semantic clarification.
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 identifies the resource: a complete technical spec sheet (engine, power, torque, transmission, consumption, performance, dimensions, brakes, tires). It also introduces the optional `section` restriction, which helps distinguish this from broader vehicle-level tools. It does not explicitly contrast with sibling tools like get_listing_details or get_vehicle_by_id, but the content is specific enough that confusion is unlikely.
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 provides no guidance about when to use this tool versus its siblings, such as get_listing_details or get_market_stats. It states what data is returned but not which scenarios call for this tool or which alternatives would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full details of a single listing by its PegaRex id: brand, model, version, year, price, mileage, fuel, transmission, city/state, FIPE price, deal_score, source platform and the original ad URL.
| Name | Required | Description | Default |
|---|---|---|---|
| car_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds a useful list of returned fields, but it does not disclose any additional behavioral traits such as error handling, permission needs, or response shape. With annotations covering the safety profile, a 3 is appropriate.
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, well-structured sentence that leads with the verb and resource, then compactly lists the returned fields. There is no redundancy or filler; every word adds value.
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 lookup by ID, the description covers the return fields and the key identifier semantics. It lacks an explicit note about the overlapping sibling tool get_listing_details and potential edge cases, but given the low complexity and annotations, it is largely 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?
The schema only defines car_id as an integer with no description. The description adds that it is the 'PegaRex id', giving domain meaning to the parameter. This helps compensate for the 0% schema coverage, but it does not provide format details or constraints beyond that.
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 action ('Fetch') and resource ('single listing by its PegaRex id') plus a detailed list of returned fields. It is specific but does not explicitly differentiate itself from the sibling tool get_listing_details, so it falls short of 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?
No guidance is provided on when to use this tool versus alternatives like search_vehicles or get_listing_details. The description only states what it does, leaving the agent to infer usage from the name and general context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available vehicle brands (makes) with their catalog id and active
listing count. Pass a brand's id as brand_id to search_vehicles/list_models
for fast, exact filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Cars | |
| body_style | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds value by specifying the return contents (catalog id and active listing count) beyond what the schema or annotations provide. It does not disclose any additional behavioral traits (e.g., pagination, limits), but for a lightweight list this is sufficient.
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 two sentences with no fluff. The core purpose is front-loaded, and the second sentence delivers actionable usage guidance. Every word earns its place.
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 list tool, the description covers the essential information: what it lists, what it returns, and how to use the output. It lacks parameter explanations (covered under parameter semantics) and does not mention potential constraints like pagination, but these are minor for a tool that likely returns a small list. The read-only nature is already conveyed by annotations, so the description is otherwise 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?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. However, the description does not explain what 'category' or 'body_style' mean or how they affect the results. The category enum is somewhat self-explanatory, but body_style is ambiguous, and the description provides no guidance, leaving a significant gap.
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 states a specific action (List) and resource (available vehicle brands/makes), and clearly distinguishes its purpose by naming the outputs (catalog id and active listing count). It also relates to sibling tools (search_vehicles, list_models), making it unambiguous what this tool is for.
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 explicitly tells the agent to pass the resulting brand_id to search_vehicles/list_models for fast filtering, which explains when and why to use this tool. It does not explicitly state when not to use it or mention alternatives like list_filter_options, but the context is clear enough for a simple list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the valid values for the constrained search filters — fuel_type, transmission, sort_by — and the list of source platforms. Use this to build a valid call to search_vehicles in a single round-trip.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context by naming the constrained filter categories and the dependency on search_vehicles, but it does not describe output structure or data volatility; this is acceptable given the annotation coverage.
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?
Two sentences, no filler, with the return scope front-loaded and the usage instruction placed right after. Every sentence earns its place.
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 parameters, a rich annotation set, and no output schema, the description fully covers what the tool returns and how it should be used. An agent can decide when to call it and what to do next without additional information.
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 tool has zero parameters, so there is no parameter detail the description must supplement. It still adds value by naming the filter fields the returned values correspond to, which helps the agent interpret the tool's purpose.
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 action ('Return the valid values') and identifies the specific resource: constrained search filters (fuel_type, transmission, sort_by) and source platforms. This distinguishes it from sibling get_* and list_* tools by directly tying it to search_vehicles.
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 phrase 'Use this to build a valid call to search_vehicles in a single round-trip' explicitly tells the agent when to invoke this tool. It does not name alternatives or exclusions, but the prerequisite relationship to search_vehicles is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List models for a brand (pass brand_id from list_brands, or a brand name) with each model's catalog id and active listing count.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | ||
| brand_id | No | ||
| category | No | Cars |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds useful context about return fields and the source of brand_id, going beyond what annotations provide. No contradiction with 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?
The description is a single, dense sentence that front-loads the purpose and includes essential input and output details. No wasted words; every phrase earns its place.
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 list tool with annotations covering safety and no output schema, the description covers the main purpose, input source, and return fields. It does not clarify behavior when neither brand nor brand_id is provided, nor explain the category filter, which are minor gaps given the tool's simplicity.
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 coverage is 0%, so the description must compensate. It explains brand and brand_id ('pass brand_id... or a brand name') but does not mention the category parameter, which has an enum with default 'Cars'. Thus, two of three parameters are explained, but category remains undocumented in the description.
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's purpose: 'List models for a brand' with specific output details ('each model's catalog id and active listing count'). It also differentiates from siblings like list_brands by referencing brand_id from list_brands, making the scope unambiguous.
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 gives a clear usage hint: 'pass brand_id from list_brands, or a brand name', indicating the prerequisite step of calling list_brands. It does not explicitly mention when not to use this tool or compare with list_versions, but the workflow guidance is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List versions/trims for a model (pass model_id from list_models, or brand+model names) with each version's catalog id and active listing count.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | ||
| model | No | ||
| category | No | Cars | |
| model_id | No | ||
| year_max | No | ||
| year_min | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds useful context about output fields and the model identification input, but does not disclose additional behavioral traits such as authentication requirements, rate limits, or behavior when no results are found. Given the strong annotation coverage, a 3 is appropriate.
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 sentence that front-loads the verb and resource, then immediately provides the input source and expected output. Every phrase adds value with no filler or redundancy.
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 read-only, idempotent list tool with no output schema, the description provides the essential information: what to list, how to identify the model, and what the result contains. It does not mention optional year filters or the category default, but these are not required for a correct basic invocation and the core usage is fully covered.
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 description coverage is 0%, so the description must compensate. It does explain the core identification parameters: model_id comes from list_models, and brand+model names are an alternative. However, it does not clarify year_min/year_max or the category parameter, relying on their names and the enum to carry meaning. This is partial but not complete compensation for the lack of schema descriptions.
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 uses a specific verb and resource: 'List versions/trims for a model', which clearly differentiates this tool from siblings like list_models and list_brands. It also states what the output contains (catalog id and active listing count), so an agent can immediately understand the tool's purpose and scope.
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 gives explicit invocation guidance: either pass a model_id from list_models or use brand+model names. This provides clear context on how to call the tool and where to source the identifier. It does not explicitly state when not to use it or name alternatives, but the prerequisite relationship with list_models is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 1.8M+ Brazilian vehicle listings aggregated from 96 platforms (OLX, Webmotors, Napista, etc.). Returns listings with price, year, mileage, location, source platform, the original ad URL, FIPE reference price and a deal_score (% vs FIPE; negative means priced below FIPE).
Tips for best results:
- Free-text `query` matches the listing TITLE only (e.g. "Onix LTZ turbo").
- For exact brand/model/version filtering, resolve names to ids first with
list_brands / list_models / list_versions and pass brand_id/model_id/
version_id — it is faster and more accurate than the text fields.
- `location` is a 2-letter UF (e.g. "SP") or a city name.
- `sort_by="newest"` (default) lists the most recently LISTED cars first —
the date a listing first appeared on its source, not when we last saw it.
- `sort_by="best_deal"` ranks by lowest price-to-FIPE ratio.
- `per_page` is capped at 50. Use `page` (1-20) to paginate; past the first
20 pages, narrow the search with filters. `total_count` and
`total_pages` are returned.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| brand | No | ||
| model | No | ||
| query | No | ||
| source | No | ||
| sort_by | No | newest | |
| version | No | ||
| brand_id | No | ||
| category | No | Cars | |
| location | No | ||
| model_id | No | ||
| per_page | No | ||
| year_max | No | ||
| year_min | No | ||
| fuel_type | No | ||
| price_max | No | ||
| price_min | No | ||
| body_style | No | ||
| version_id | No | ||
| mileage_max | No | ||
| mileage_min | No | ||
| transmission | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark read-only and idempotent, but the description adds rich behavioral context: deal_score semantics, sort_by='newest' meaning (listed date, not last seen), per_page cap, and total_count/total_pages in response. No contradiction with readOnlyHint.
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?
Well-structured with a concise intro followed by bulleted tips. Every sentence adds value: the intro defines scope and output, tips clarify semantics and boundaries. No redundant fluff, front-loaded with the core purpose.
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 complex tool with 22 optional parameters and no output schema, the description effectively communicates the response shape, pagination behavior, and deal_score interpretation. It covers the most impactful parameters but omits detailed explanations for many filters, which is acceptable given the breadth.
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 zero descriptions, so the description carries the burden. It explains several key parameters: query (title match), location (UF or city), sort_by options, per_page cap, and page usage. However, many filter parameters (price, year, transmission, fuel_type, etc.) are left unexplained, and the description doesn't cover all 22 parameters.
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 explicitly states it searches 1.8M+ Brazilian listings aggregated from 96 platforms and enumerates the returned fields (price, year, mileage, location, source, URL, FIPE price, deal_score). This clearly differentiates it from siblings like get_vehicle_by_id (single vehicle) and list_brands (metadata).
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?
Provides actionable usage tips: when to use free-text query vs resolved IDs, explains location format, sort options, and pagination limits with advice to narrow past page 20. While it doesn't explicitly contrast with all sibling tools, the guidance on pre-resolving with list_* tools implies the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_alternative_modelsget_avg_days_to_sellget_cheapest_statesget_fipe_valuationget_listing_detailsget_market_positionget_market_statsget_mileage_contextget_price_distributionget_similar_active_listingsget_technical_specsget_vehicle_by_idlist_brandslist_filter_optionslist_modelslist_versionssearch_vehicles
Add one secure layer between your agents and this server.