Criei um servidor MCP que dá memória persistente de IA ao seu banco de dados SQL

Há algum tempo, tentei construir um assistente de codificação local. Baixei o Qwen3, o liguei no meu MacBook com 16GB de RAM e, em um dia, percebi que a qualidade da saída estava longe de ser comparável à do Claude ou do GPT-5. O modelo poderia se adaptar. Ele simplesmente não conseguia competir.

Então, mudei a pergunta.

Se eu não consigo tornar o modelo mais inteligente no meu hardware, posso tornar o que eu alimento nele mais inteligente?

Para onde os tokens realmente vão

Comecei a observar onde minhas sessões do Claude / Cursor / Copilot realmente gastavam seus tokens. A surpresa: a maior parte não era raciocínio. Era consulta.

Cada nova conversa sobre o banco de dados da minha empresa redescobria as mesmas coisas:

• O que significa status = 3? (cancelado)
• Como orders se junta a users? (orders.user_id → users.id)
• O que é aquele enum JobStatus? (uma dúzia de códigos inteiros que ninguém lembra)

O modelo descobriu, a sessão terminou e amanhã ele descobriu novamente. Mesmos tokens, mesma latência, toda vez. A parte cara de trabalhar com uma IA não era o pensamento — era reensinar coisas que ela já havia aprendido ontem.

Há muita atenção agora em reduzir os tokens de saída da IA (falar como um homem das cavernas, eliminar as formalidades, etc.). Mas no meu fluxo de trabalho, o maior vazamento estava no lado da entrada: pagando o custo total de tokens a cada sessão para restabelecer um contexto que nunca mudou.

"Memória" não é um recurso, é uma questão de arquitetura

Os clientes de IA estão começando a adicionar recursos de "memória". Mas eles são proprietários, opacos e bloqueados a uma ferramenta. A memória do Claude não ajuda o Cursor. A do Cursor não ajuda o Copilot. Você não pode inspecioná-la, não pode compartilhá-la com um colega e não pode compará-la.

O que eu realmente queria era uma camada de contexto explícita, inspecionável e compartilhável que qualquer cliente de IA pudesse ler de forma determinística — mesma resposta toda vez, mesmo arquivo que minha equipe poderia passar adiante.

Escolhi o custo de reaprendizagem mais alto no meu mundo para começar: bancos de dados SQL.

Apresentando amnesic

amnesic é um servidor MCP de código aberto que dá a qualquer cliente de IA memória semântica persistente de seus bancos de dados SQL. O nome é irônico — ele é tudo, menos amnésico. Ele se lembra.

Você (ou a IA) anota uma tabela ou coluna uma vez:

db_annotate(
    table="orders",
    column="status",
    column_description="Estado do ciclo de vida do pedido",
    enum_values={"1": "pendente", "2": "enviado", "3": "cancelado", "4": "entregue"},
)

…e é armazenado em um arquivo SQLite local. Cada futura chamada db_get_schema mescla essas anotações de volta na resposta — através de sessões, entre clientes de IA, para sempre:

Você:  Quantos pedidos cancelados este mês?
IA:   [chamadas db_get_schema("orders")]
      → status coluna: enum {"3": "cancelado", ...}
      [escreve SQL correto imediatamente, sem redescoberta]
      SELECT COUNT(*) FROM orders WHERE status = 3 AND ...

Sem reexplicações. Sem turnos desperdiçados. A anotação persistiu.

As decisões técnicas que eu defenderia

Algumas escolhas que podem interessar pessoas construindo ferramentas semelhantes:

SQLite FTS5 em vez de um banco de dados vetorial

Comecei com ChromaDB para busca — "encontrar a tabela que lida com pagamentos." Então eu removi. O FTS5 embutido do SQLite com classificação BM25 cobre o caso de uso "encontrar a tabela/coluna certa" a zero custo de dependência. Sem embeddings, sem download de modelo, sem serviço externo. Para uma ferramenta que deve ser uma camada local leve, puxar um stack vetorial de mais de 50MB foi a troca errada.

db_search("pagamento")
# → classificado: orders.payment_method, tabela consumerpayments, ...
#   tudo de um índice local FTS5, sem rede, sem embeddings

Aplicação de leitura somente em duas camadas

amnesic se conecta a bancos de dados de produção, então a IA deve nunca ser capaz de modificar nada. Duas camadas independentes:

1. Análise SQL estática — rejeitar qualquer coisa que não seja SELECT / WITH; capturar palavras-chave de escrita, SELECT ... INTO OUTFILE, e gravações escondidas dentro de CTEs.
2. Rollback de transação — cada consulta é executada dentro de uma transação que é imediatamente revertida. Mesmo que uma gravação tenha passado pela camada 1, nada é confirmado.

Cinto e suspensórios. A IA não deve ser capaz de excluir sua tabela, mesmo por acidente.

Um arquivo SQLite por conexão

Cache de esquema + anotações + gráfico de relacionamento FK + o índice FTS5 vivem em um único arquivo SQLite por conexão de banco de dados. Portátil, inspecionável, chmod 600. Quer passar seu conhecimento acumulado para um colega? É um único arquivo.