Smithery, fast-mcp'yi reddetti. Claude tüm MCP server'ı yarım saatte resmi SDK'ya taşıdı — yeniden yazma ucuz oldu çünkü ilk kat ince yazılmıştı.
smarts projesi MCP'yi altı gün önce ekledi. Claude Code'a fast-mcp gem'iyle üç tool ayağa kaldırttım:
get_contract_info(chain, address) — kontrat adı, protokol adapter etiketi, function/event sayılarıread_contract_state(chain, address, function_name, args?) — tek view/pure çağrısı, 60 saniye cacheget_uniswap_v3_pool(chain, address) — V3 panelinin tamamı: çift yönlü fiyat, liquidity, tick, USD TVLO commit 27ca82e feat(mcp): serve live contract data over MCP via fast-mcp, 2026-04-21 sabaha karşı 1:37. Yaklaşık 30 dakika. Pürüzsüz geçti.
Altı gün sonra, bu akşam — 2026-04-27, 20:24 — başka bir commit push'ladım: 4df08fa feat(mcp): switch to official mcp gem with Streamable HTTP transport.
İkisi arasında ne oldu?
smarts'ı Smithery'ye (MCP server'ları için bir dizin) kayıt için gönderdim. Tarayıcısı hemen 405 döndü:
POST /mcp/sse → 405 Method Not Allowed
Anlamam biraz vakit aldı: fast-mcp 1.6.0 (en son release) hâlâ MCP spec 2024-11-05'in HTTP+SSE transport'unu kullanıyor. Modern MCP istemcileri ise spec 2025-03-26'nın Streamable HTTP'sine çoktan geçti — tek endpoint, aynı URL üzerinde POST + DELETE, ayrı bir /sse yolu yok.
Yani: spec bir adım önde, baskın community gem'i hâlâ yetişmemiş.
fast-mcp'nin yetişmesini bekleyecek değildim. MCP server katmanı, istemcilerin tüketmesi için var — spec uyumluluğu, hangi gem'in elde daha rahat durduğundan ağır basıyor.
fast-mcp'yi Anthropic'in resmi mcp 0.14.0 gem'iyle değiştirdim. Bu turda Amp'te yeni bir thread açtım (altta hâlâ Claude Opus dönüyor, Claude Code ile aynı model).
Migrasyonda ne yere indi:
Transport yeniden döşendi
# Eski: fast-mcp /sse'yle birlikte /mcp'ye otomatik mount oluyor
# Yeni: açık mount, tek endpoint
mount StreamableHTTPTransport.new(server, stateless: true), at: "/mcp"
stateless: true kilit nokta. Server, per-session state'i hafızada tutmuyor; bu da Puma'yı workers > 0 ile çalıştırıp sticky session'a ihtiyaç duymadan yatay ölçeklemeyi mümkün kılıyor.
Tool API yeniden yapılandırması
Eski fast-mcp biçimi:
class GetContractInfoTool < ApplicationTool
arguments do
required(:chain).filled(:string)
required(:address).filled(:string)
end
def call(chain:, address:)
# iş mantığı
end
end
Resmi gem, SDK tesisatını base sınıfa itiyor:
class ApplicationTool < MCP::Tool
def self.call(**args, server_context: nil)
hash = payload(**args)
MCP::Tool::Response.new([{ type: "text", text: hash.to_json }])
end
end
class GetContractInfoTool < ApplicationTool
input_schema(
properties: {
chain: { type: "string" },
address: { type: "string" }
},
required: %w[chain address]
)
def self.payload(chain:, address:)
# iş mantığı, Hash döndürür
end
end
Alt sınıflar yalnızca payload(**args)'in hangi Hash'i döndürdüğüyle ilgilenir; base sınıf onu MCP::Tool::Response içindeki JSON-encoded text block'a sarar. İki kazanç:
Tool.payload(chain:, address:)'in Hash'ine assert edebilir, protokol envelope'unu soymaya gerek yokdry-schema DSL'ini ham JSON Schema literal'larıyla değiştirdim. Geri adım gibi duruyor ama input_schema MCP spec'ten istemcinin doğrudan tükettiği alan — spec primitive'i olarak yazmak daha dürüst.
Testlerin taşınması
433 test, Tool.new.call(...)'tan Tool.payload(...)'a taşındı. Hepsi yeşil.
discovery / docs senkronu
.well-known/mcp.json artık transport: "streamable-http", protocol_version: "2025-03-26"https://smarts.md/mcp'ye güncellendiclaude mcp add flag'i --transport sse'den --transport http'ye geçtimcp artık primary, fast-mcp legacy/deprecated olarak işaretliİlk MCP entegrasyonu 30 dakika sürdü. Yeniden yazma da yaklaşık aynı. Aralarında 6 gün var.
Aklıma yatan şu: MCP gibi genç bir ekosistemde gem'lerin spec'in gerisinde kalması norm. fast-mcp kötü değil — bakım yapan da aktif. Sorun, protokolün üçüncü taraf gerçeklemelerinden daha hızlı ilerlemesi. Bu yıl sağlam görünen bir gem, altı ay sonra "eski spec'inkisi" olabilir.
Altı ay önce fast-mcp üzerine on bin satır iş mantığı yazsaydım, bugün büyük ihtimal eski spec'e çakılı kalırdım — çünkü yeniden yazma maliyeti, üzerine atlanmaya değmeyecek kadar yüksek olurdu.
Ama gerçekte olan şu: fast-mcp katmanı baştan beri ince bir sarmalayıcıydı. İş mantığı ApplicationTool alt sınıflarında oturuyordu. Yeniden yazmanın gerçek maliyeti şu kadardı:
Asıl pahalı olan iş mantığı. Protokol sarmalayıcıları ucuz ve yeniden yazılabilir olmalı. Claude Code'un bana altı gün önce yaptığı en büyük iyilik bu — iş mantığını fast-mcp callback'lerine tıkıştırmadı. SDK'yı içine alan tertemiz bir ApplicationTool soyutlaması kurdu. Bu yüzden altı gün sonraki SDK değişimi yalnızca base sınıf + schema değişikliği gerektirdi.
6 gün içinde "ilk entegrasyon → spec yükseltmesi → yeniden yazma" yolunu yürümeme izin veren şey, alttaki Claude modelinin istikrarı — hangi agent shell'inde olduğum çok da önemli değil.
Kaynak kod: https://github.com/defi-io/smarts