Radar noEixo

List knowledge gaps

list_knowledge_gaps

Read-only

🧠 INSIGHTS DE ATENDIMENTO — Lista perguntas/respostas problemáticas do agente, de 3 fontes possíveis (campo source): "tool" = o próprio agente sinalizou que não sabia responder (flag_knowledge_gap); "heuristic" = detectado por frase-gatilho de evasiva ("não sei", "vou verificar e retorno") mesmo sem o agente chamar a tool; "async_qa" = revisão assíncrona (cron) encontrou uma resposta dada COM CONFIANÇA que contradiz ou não é sustentada pela base de conhecimento — uma alucinação silenciosa, não uma evasiva. Use para revisar lacunas de conhecimento e priorizar o que adicionar à KB ou ao prompt. "tool"/"heuristic" exigem AgentConfig.knowledgeGapTrackingEnabled ligado; "async_qa" exige AgentConfig.asyncQaEnabled ligado (ambos via update_agent_config). Sem target_user_id, consulta a PRÓPRIA conta autenticada; o administrador da plataforma pode passar target_user_id para consultar a conta de um cliente.

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_knowledge_gaps"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Máximo de resultados (padrão: 50, máx: 200)
`status`	No	Filtrar por status (padrão: "pending")
`target_user_id`	No	ID da conta-alvo (opcional; APENAS o admin da plataforma pode usar). Padrão: a conta autenticada.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description goes further by disclosing that tool/heuristic sources require knowledgeGapTrackingEnabled and async_qa requires asyncQaEnabled, and by explaining that async_qa detects silent hallucinations rather than evasions. It also states the default account-scoping behavior and admin-only target_user_id access, which is valuable operational context.

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?

The description is front-loaded with the tool's core purpose and then explains the source taxonomy before stating prerequisites. It is dense but each section adds useful meaning. The source definitions are somewhat long, but they are the key differentiator for this tool.

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?

The description covers prerequisites, source semantics, and scoping well. However, there is no output schema, and the description does not explain what a returned gap record contains (e.g., question text, answer, status, timestamps). It also references a `source` parameter that is absent from the schema, leaving the actual filtering capability of the tool unclear.

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

Parameters2/5

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

Schema coverage is 100%, so the schema already documents limit, status, and target_user_id. The description repeats target_user_id's admin/default behavior and does not clarify limit or status. Worse, it describes a `source` parameter with three values, but no `source` property exists in the input schema — this mismatch could lead an agent to pass an unsupported parameter.

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 states a specific verb and resource (list problematic agent questions/answers) and clearly distinguishes the three gap sources (tool, heuristic, async_qa) by how each is triggered. An agent can tell this is not a generic KB listing tool and knows exactly what kind of records it returns.

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?

It gives a clear use case (reviewing knowledge gaps and prioritizing KB/prompt updates) and states prerequisites for each source via AgentConfig flags. It also explains the target_user_id scoping rule. It does not name sibling tools like resolve_knowledge_gap or search_knowledge_base to clarify when to use those instead, which keeps it below a 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?