Coloque o MCP ao lado da sua API, não por cima dela

O texto da naftiko.io parte de um padrão comum: pegar o servidor de API que já existe, colocar um servidor MCP na frente e mapear cada tool para um endpoint. Entrega rápido, mas cria duas camadas para operar, dois contratos para manter alinhados (a descrição OpenAPI e as descrições de tool que a parafraseiam) e um salto de rede extra em cada chamada do agente. O caminho vira agente, servidor MCP, servidor de API, sistemas upstream.

A alternativa é a capability do Ikanos, que declara o que consome (as APIs upstream), os fluxos que agregam essas chamadas e o que expõe. REST e MCP são dois adapters na mesma lista exposes, ambos apontando para o mesmo fluxo via ref. Chamadas, credenciais, mapeamentos e lógica de etapas são escritos uma vez. A migração é incremental: o recurso ainda não migrado passa por um forward que repassa a requisição à API existente, o migrado vira operação sobre um fluxo, e o mesmo fluxo vira tool MCP com um ref. O texto separa o que existe hoje do que está em revisão: elicitation (uma etapa elicit pausa o fluxo e pergunta ao usuário via MCP) e tasks duráveis (fluxo com mode: task que sobrevive a reinício). Em REST, esse mesmo fluxo responde 501 Not Implemented e indica a etapa que precisava de entrada.

Para quem opera uma API e pensa em abrir uma interface para agentes, a leitura é que o wrapper MCP é o caminho mais curto, mas fixa o teto do protocolo novo no que o REST já faz. Se você espera precisar de perguntas no meio da chamada ou de tarefas longas, vale avaliar a lógica de negócio em um só lugar desde o início. É a tese do autor, que também vende a ferramenta, e parte dos recursos citados ainda está em revisão.