---
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