Radar noEixo

Update icp config

update_icp_config

DestructiveIdempotent

🎯 GARIMPO LEADS — Altera o ICP. Sem list_name: o ICP da conta (só os campos enviados mudam). Com list_name: o público próprio daquela lista, que pode ter só setores, UFs e "sem site é sinal" — o resto vem da conta; herdar_da_conta="true" apaga o público da lista. Faixas recalculadas na rodada diária (06:40). Devolve o antes e o depois.

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": "update_icp_config"
  }
}

Input Schema

Name	Required	Description
`weights`	No	JSON com pesos {"canal":50,"setor":15,"porte":35,"oportunidade":0,"regiao":0} (só na conta; só as chaves enviadas mudam)
`list_name`	No	Nome (ou parte) da lista cujo público vai mudar. Sem ele: o ICP da conta.
`target_ufs`	No	UFs alvo, separadas por vírgula ou array JSON. Vazio "" = todas.
`require_ativa`	No	"true"/"false" — CNPJ precisa estar ativo (só na conta)
`exige_whatsapp`	No	"true"/"false" — lead novo sem celular é recusado (só na conta)
`target_sectors`	No	Palavras de setor/CNAE, separadas por vírgula ou array JSON (ex.: "advoc, contab, condomin"). Substitui a lista inteira. Vazio "" = qualquer setor.
`target_user_id`	No	(Só o admin da plataforma) userId da conta a operar
`herdar_da_conta`	No	"true" = a lista volta a usar o ICP da conta (só com list_name)
`sem_site_eh_sinal`	No	"true"/"false" — empresa sem site conta como sinal de momento (para quem vende site)

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description earns credit by explaining what destruction means here ('herdar_da_conta="true" apaga o público da lista'), that only sent fields change (partial update), that ranges recalculate on the daily 06:40 run rather than instantly, and that the response contains before/after. Touches nearly all the behavioral gaps annotations leave open.

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?

Dense but front-loaded: scope rules first, then side effects and return shape. Some run-on phrasing and the emoji/product banner add no information, but nothing essential is buried or wasted.

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 9-parameter mutation tool with no output schema, the description covers scope selection, partial-update semantics, the destructive reset path, deferred recalculation, and the return payload ('o antes e o depois'). An agent can call it correctly without further probing.

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 coverage is 100%, so baseline is 3; the description adds cross-field semantics the schema cannot express — which fields are account-only (weights, require_ativa, exige_whatsapp), that herdar_da_conta requires list_name, and how empty strings reset targets to 'all'. That is real value above the per-field schema text.

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?

States a specific verb and resource ('Altera o ICP') and immediately splits the operation into two scopes: account-level ICP when list_name is absent, list-level audience when present. The read counterpart get_icp_config is not named, but the mutation intent is unambiguous.

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 explicit conditional routing: no list_name = account ICP; with list_name = that list's own audience, possibly restricted to sectors/UFs/'no site is a signal'; herdar_da_conta="true" reverts the list to the account ICP. It also flags field-level applicability ('só na conta') per parameter. No exclusions vs. siblings are stated, keeping it below 5.

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?