Skip to main content
Glama
Sign In

Radar noEixo

by com.noeixodigital
OverviewDiscussionsAdmin

Create agent profile

create_agent_profile

Cria um agente na conta (recurso "Vários agentes no mesmo número"). Um agente "entrada" faz a triagem e passa a conversa para o especialista certo, que responde na hora. Com 2 ou mais agentes ativos, cada um ganha a ferramenta de passar a conversa para os outros, guiado pelo quando_passar de cada um.

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": {
      "nome": "<nome>",
      "quando_passar": "<quando_passar>"
    },
    "name": "create_agent_profile"
  }
}

Input Schema

NameRequiredDescriptionDefault
nomeYesNome do agente, como a equipe vê: "Recepção", "Vendas", "Financeiro" (até 40)
ativoNo"não" tira o agente de cena: as conversas dele voltam para o agente de entrada
botaoNoTexto do botão deste agente no menu de setores (até 20 caracteres). "" = usa o nome
ordemNoPosição na lista (número)
equipeNoLista JSON com ids das pessoas da equipe (list_agent_profiles devolve "membros") que atendem este agente. Quem for marcado vê no Chat só as conversas dos agentes em que está, mais as passadas para ela; dono e gerente sempre veem tudo. "[]" tira todo mundo
entradaNo"sim" = recebe as conversas novas (só um agente pode ser de entrada; marcar este desmarca o anterior). Sem agente de entrada, as conversas novas ficam com o agente principal
numerosNoLista JSON com ids dos números de WhatsApp (list_agent_profiles → numeros) em que este agente trabalha, ou "todos" (padrão). A passagem entre agentes e o menu de setores ficam só entre os agentes do mesmo número
produtosNoLista JSON com ids de produto (list_products) que este agente oferece, ou "todos"
entrada_emNoLista JSON com ids dos números em que este agente é o de ENTRADA: recebe as conversas novas que chegam por ele e as que o Radar começa por ele (cadência, automação, n8n, API). Troca o de entrada anterior daquele número. "[]" tira de todos. Só números em que ele trabalha
order_fieldsNoCampos personalizados próprios, no mesmo formato de update_agent_config.order_fields, ou "herdar" para usar os da conta
etapa_entradaNoVários funis: id da etapa (list_pipeline_stages) onde o agente põe o contato SEM etapa que ele atende. Vazio = não põe no funil (padrão). Contato que já está no funil não muda.
etiqueta_baseNoEtiqueta da base deste agente, ex.: "financeiro". Documentos com a etiqueta "agente:financeiro" só este agente vê; documentos sem etiqueta de agente valem para todos. "" tira
quando_passarYesQuando os OUTROS agentes devem passar a conversa para este, ex.: "dúvidas de boleto, nota fiscal e pagamento" (até 300)
system_promptNoJeito de atender deste agente (tom, ordem da conversa). Sem preço e sem horário: preço fica em Produtos, horário no agente principal. Vazio = usa o system_prompt do agente principal
target_user_idNo(Só o admin da plataforma) userId da conta a operar

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / etapa_entrada
      Added value: +{
+  "description": "Vários funis: id da etapa (list_pipeline_stages) onde o agente põe o contato SEM etapa que ele atende. Vazio = não põe no funil (padrão). Contato que já está no funil não muda.",
+  "type": "string"
+}
  2. Changed2 schema fields changed
    • addedInput schema / properties / entrada_em
      Added value: +{
+  "description": "Lista JSON com ids dos números em que este agente é o de ENTRADA: recebe as conversas novas que chegam por ele e as que o Radar começa por ele (cadência, automação, n8n, API). Troca o de entrada anterior daquele número. \"[]\" tira de todos. Só números em que ele trabalha",
+  "type": "string"
+}
    • addedInput schema / properties / numeros
      Added value: +{
+  "description": "Lista JSON com ids dos números de WhatsApp (list_agent_profiles → numeros) em que este agente trabalha, ou \"todos\" (padrão). A passagem entre agentes e o menu de setores ficam só entre os agentes do mesmo número",
+  "type": "string"
+}
  3. Changed2 schema fields changed
    • addedInput schema / properties / botao
      Added value: +{
+  "description": "Texto do botão deste agente no menu de setores (até 20 caracteres). \"\" = usa o nome",
+  "type": "string"
+}
    • addedInput schema / properties / equipe
      Added value: +{
+  "description": "Lista JSON com ids das pessoas da equipe (list_agent_profiles devolve \"membros\") que atendem este agente. Quem for marcado vê no Chat só as conversas dos agentes em que está, mais as passadas para ela; dono e gerente sempre veem tudo. \"[]\" tira todo mundo",
+  "type": "string"
+}
  4. Added

TDQS

A3.6/5.0
Behavior4/5

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

Annotations only declare it is a non-read-only, non-destructive, closed-world write. The description goes beyond that by disclosing a non-obvious system side effect: with 2+ active agents each gains a pass-conversation tool driven by each agent's quando_passar, and the entrada agent routes triage. It still omits what is returned on success and any permission/uniqueness constraints.

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?

Three sentences, front-loaded with the action, and no filler. The latter two sentences are explanatory rather than operational, but they earn their place by conveying the multi-agent model an agent needs to interpret the many parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-parameter creation tool with no output schema, the description covers the domain model well but never says what a successful call yields (e.g., a new agent id) or how creating interacts with existing profiles beyond the entrada swap. Adequate but with clear gaps for a tool of this complexity.

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% and the 15 parameters are documented in detail in the schema itself, so the baseline is 3. The description adds only marginal nuance by referencing quando_passar as the handoff trigger and the entrada concept; it does not clarify the JSON-list/"todos" conventions or the admin-only target_user_id.

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?

The description opens with a specific verb and resource ("Cria um agente na conta") and scopes it to the multi-agent-per-number feature, which distinguishes it from generic account tools. It does not explicitly contrast itself with the sibling update_agent_profile or list_agent_profiles, so the agent must infer that this is the creation counterpart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is implied through the conceptual explanation of what an "entrada" agent does and how handoff works once 2+ agents are active, which helps an agent understand the feature. However, there is no explicit "use this when..." statement, no mention of prerequisites (e.g., needing ids from list_agent_profiles/list_products), and no guidance on when to prefer update_agent_profile instead.

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

All Radar noEixo toolsInspect
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