Rodolpho Lopes 200cd6c2ce kb: KB-PLUGIN-031 runbook de workflow dev/deploy de plugins + commit dos registros 021-030 pendentes

- Novo runbook KB-PLUGIN-031: nascimento do plugin ate validacao E2E no
  GLPI dev (scaffold, Forgejo local, deploy CT100, console, bootstrap
  Kernel para testes CLI). Validado de ponta a ponta com o assetinherit.
- Registros KB-PLUGIN-021..030 existiam apenas no disco (drift) e foram
  incluidos no versionamento; index.json sincronizado via kb-fix.
- Ignora lixo AppleDouble/.DS_Store do macOS.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-06-11 17:59:47 +00:00

3.1 KiB

Raw Blame History

title

domain

mcprotocol — Roadmap de Resources e caso de uso N1

Contexto

A spec MCP define 3 primitivos: tools, resources e prompts. Hoje o plugin mcprotocol implementa apenas tools. A evolução natural mais valiosa pro caso GLPI é adicionar resources, especialmente para habilitar LLM como N1 (atendimento de primeiro nível).

Por que Resources e não Prompts

Resources (alto valor) — GLPI tem KB articles, tickets com histórico, anexos e CIs. Tudo isso é "documento que o LLM deveria ler", não "função que ele chama". Resources transforma N chamadas de tool em uma anexação direta no contexto.
Prompts (baixo valor) — ITSM tem workflows mas usuários já falam linguagem natural. ROI marginal.

Caso de uso central: LLM como N1

Fluxo tradicional N1:

Recebe chamado
Procura KB
Lê artigos
Aplica procedimento ou escala

Com resources + tools:

Cliente MCP anexa KB articles relevantes como resources
LLM lê no contexto sem fazer N chamadas de tool
Usa tools (glpi_ticket_*) pra agir no chamado
Caso de "N1 autônomo": webhook → busca KB+tickets similares → resources → LLM decide aplicar ou escalar

Resources prioritárias

URI pattern	Origem	Caso de uso
`kb://{id}`	`glpi_knowbaseitems`	Artigos da base de conhecimento
`ticket://{id}`	`glpi_tickets` (+ followups, solutions)	Ticket completo com histórico
`document://{id}`	`glpi_documents`	Anexos (PDFs, prints, manuais)
`computer://{id}`	`glpi_computers` (+ items)	CI técnico do ativo

Implementação sugerida

Criar src/KBResources.php (e companheiros) seguindo o padrão ToolRegistry:

class KBResources {
    public static function getResources(): array { /* ... */ }
    public static function readResource(string $uri) { /* ... */ }
}

Adicionar ResourceRegistry análogo ao ToolRegistry. Em Server.php, implementar:

resources/list — lista URIs disponíveis (paginar para KB grandes)
resources/read — retorna conteúdo por URI

Evolução futura (fora deste escopo)

SSE / Streamable HTTP completo — notificações server-push (novo ticket, SLA estourando)
Prompts — depois de resources, talvez 2-3 prompts simbólicos (triagem, fechamento padrão)
Multi-tenancy / escopo OAuth2 fino — separar permissões por escopo (tools_ticket, tools_inventory, etc.)
stdio→HTTP bridge — pacote NPM @mindplace/glpi-mcp-bridge para compatibilidade com clientes que só falam stdio

Status

Roadmap — não implementado. Prioridade após conclusão do roadmap de tools (KB-PLUGIN-020).

Referências

KB-PLUGIN-019 — Arquitetura BFF do mcprotocol
KB-PLUGIN-020 — Roadmap de tools pendentes
Spec MCP: https://spec.modelcontextprotocol.io

3.1 KiB Raw Blame History