Radar noEixo

List deals

list_deals

Read-only

Lista negociações ativas no pipeline de vendas. Retorna contatos com valor do negócio, etapa do pipeline, status, última atualização e quando foi a última mensagem do cliente e a da empresa (ultima_mensagem_cliente_em / ultima_mensagem_empresa_em). Com sem_resposta_ha_dias, traz só quem não respondeu à última mensagem da empresa há mais desse número de dias (ex.: etapa "Orçamento enviado" + 1 dia = lista do follow-up). Com agente, traz só quem tem conversa atendida por aquele agente (contas com vários agentes; ex.: o follow-up de uma marca não pega lead de outra).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_deals"
  }
}

Input Schema

Name	Required	Description
`funil`	No	Filtra a etapa só neste funil (id ou nome).
`limit`	No	Quantidade máxima (padrão 20, máx 100)
`agente`	No	Nome do agente (ex.: "Desafio"): só contatos com conversa atendida por ele (opcional)
`status`	No	Filtrar por status do contato
`min_value`	No	Filtrar por valor mínimo do negócio (R$)
`pipeline_stage`	No	Filtrar por nome exato da etapa do pipeline (opcional)
`sem_resposta_ha_dias`	No	Só contatos em que a empresa falou por último e o cliente não respondeu há mais de N dias (opcional)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 7, 2026

addedInput schema / properties / funil

Added value: +{
+  "description": "Filtra a etapa só neste funil (id ou nome).",
+  "type": "string"
+}

Changed1 schema field changedOct 31, 2026

addedInput schema / properties / agente

Added value: +{
+  "description": "Nome do agente (ex.: \"Desafio\"): só contatos com conversa atendida por ele (opcional)",
+  "type": "string"
+}

First observedOct 26, 2026

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered by structured data. The description adds genuine behavioral context beyond that: the exact field set returned and how the agente filter scopes results per atendimento. It says nothing about ordering, pagination beyond the schema's limit, or what happens when filters combine and yield nothing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and return shape, then filter semantics in descending order of subtlety. Every sentence carries information; the parenthetical examples are long but each one disambiguates a filter that would otherwise be misused. Slightly dense, but no filler.

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?

With seven optional parameters and no output schema, the description carries the burden of describing the return shape, and it does so by naming the returned fields. Combined with annotations covering safety and a fully documented schema, an agent has enough to call it correctly. Ordering and default sort remain unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all seven parameters and the baseline is 3. The description does add real meaning beyond it for sem_resposta_ha_dias (last message from company, no reply for N days, with a worked example) and agente (only conversations handled by that agent). That added semantic content, particularly for the filter-composition cases, pushes it above a bare baseline but not decisively.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource+scope: 'Lista negociações ativas no pipeline de vendas', and immediately enumerates the returned fields (valor do negócio, etapa, status, timestamps de mensagem). That is far more informative than a restated title. It does not name a sibling such as list_contacts or list_pipelines to draw the boundary explicitly, so it stops 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete usage contexts for the two non-obvious filters: the follow-up scenario ('etapa "Orçamento enviado" + 1 dia = lista do follow-up') and the multi-agent brand scenario. However, it offers no explicit when-not guidance or named alternatives for the broader 'list contacts vs list deals' decision.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Radar noEixo tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?