Transformando o Registro MCP do GitHub em uma Capacidade Naftiko

O Registro MCP do GitHub existe. É uma peça real de infraestrutura agora — fornecedores publicam nele, empresas o espelham, IDEs estão começando a apontar para ele para descoberta.

O problema com o registro hoje, como desenvolvedor, é que é uma página da web que você rola. Seu agente a lê mal. Sua equipe de segurança a consulta manualmente. Sua automação de plataforma não pode realmente chamá-la como uma ferramenta porque não parece uma — parece um catálogo JSON de metadados, com busca por palavra-chave.

Este post é a versão de engenharia do argumento: embrulhe o registro como uma capacidade Naftiko, exponha três superfícies de uma especificação e transforme-o em algo que todos os consumidores (humanos, agentes, pipelines) possam chamar da mesma forma.

A forma de uma capacidade Naftiko

Uma capacidade Naftiko YAML é um único artefato que declara duas coisas:

• consumes — quais APIs upstream a capacidade chama
• exposes — quais superfícies a capacidade serve para fora (REST, MCP, Habilidades de Agente)

O Naftiko Engine executa a especificação. O mesmo artefato é a unidade implantável, a documentação e o contrato de governança. As especificações não se desviam do tempo de execução, porque a especificação é o artefato de tempo de execução. O wiki do framework tem o argumento em formato longo sob Integração Orientada por Especificação.

Para o Registro MCP do GitHub, a forma da capacidade é aproximadamente:

naftiko: "1.0.0-alpha2

info:
  name: descoberta-registro-github-mcp
  description: Superfície de descoberta conversacional sobre o Registro MCP do GitHub
  version: "1.0.0

consumes:
  github-registry:
    type: http
    baseUrl: https://api.github.com
    auth: instalação_app_github
    operations:
      listar-entradas-registro:
        method: GET
        path: /repos/{{ .registry_owner }}/{{ .registry_repo }}/contents/servers
      obter-entrada-registro:
        method: GET
        path: /repos/{{ .registry_owner }}/{{ .registry_repo }}/contents/servers/{{ .entry_path }}

Esse é o lado de consumo. A capacidade agora sabe como ler o registro através da API de Conteúdos do GitHub. O próximo bloco é onde a descoberta conversacional entra — o lado exposes.

Três exposições, uma especificação

exposes:
  rest:
    operations:
      encontrar-servidores-mcp:
        method: GET
        path: /v1/mcp-servers
        parameters:
          - name: propósito
            in: query
            schema: { type: string }
          - name: fornecedor
            in: query
            schema: { type: string }
          - name: status_revisão
            in: query
            schema: { type: string, enum: [aprovado, pendente, revogado] }
        outputParameters:
          - name: servidores
            type: array
            jsonpath: $.results[*]
            items:
              - { name: urn,            jsonpath: $.urn }
              - { name: url_instalacao,    jsonpath: $.install.url }
              - { name: escopos,         jsonpath: $.install.scopes[*] }
              - { name: status_revisão,  jsonpath: $.governance.review.status }
              - { name: data_revisão,    jsonpath: $.governance.review.date }

  mcp