200cd6c2ce
- 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>
87 lines
3.1 KiB
Markdown
87 lines
3.1 KiB
Markdown
---
|
|
id: KB-PLUGIN-021
|
|
title: mcprotocol — Roadmap de Resources e caso de uso N1
|
|
domain: plugin-dev
|
|
tags:
|
|
- mcp
|
|
- resources
|
|
- n1
|
|
- knowledge-base
|
|
- roadmap
|
|
status: draft
|
|
severity: medium
|
|
created_at: 2026-05-26
|
|
updated_at: 2026-05-26
|
|
applies_to:
|
|
- glpi-11
|
|
- mcprotocol-plugin
|
|
related_records:
|
|
- KB-PLUGIN-019
|
|
- KB-PLUGIN-020
|
|
---
|
|
|
|
# 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:
|
|
1. Recebe chamado
|
|
2. Procura KB
|
|
3. Lê artigos
|
|
4. 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`:
|
|
|
|
```php
|
|
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
|