PegaRex MCP Server

Average days to sell

get_avg_days_to_sell

Read-onlyIdempotent

Calculate median days a similar car listing stays active before selling, using a car ID and optional granularity to gauge market liquidity.

Instructions

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "car_id": "<car_id>"
    },
    "name": "get_avg_days_to_sell"
  }
}

Input Schema

Name	Required	Description	Default
`car_id`	Yes
`granularity`	No		model_year

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 25, 2026

TDQS

A4.4/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server