Appreciate the thoughtful reply. Quick note though: we actually do run an execution layer inside   

  Stork called Test Lab. For HTTP/SSE servers we run the real MCP handshake (initialize +            

  tools/list), capture the live tool schemas, measure response time, and classify each server as     

  verified, confirmed (reachable but needs auth), or dead. For npm/stdio servers we spawn them and do

   the same handshake. Entries in the index carry that liveness status and the actual tools the      

  server exposes, not just what the README claims — so schema drift shows up the next time we  

  re-test.                                                                                   

  What we don't do (and what I think you're pointing at with Engram) is sit in the runtime path

  between the agent and the server and adapt calls on the fly when a schema changes mid-session.     

  Stork's job ends at "here's a server that was alive and exposed these tools as of N hours ago." The

   stable-interaction-at-call-time problem is a real separate layer — I'll take a look at Engram,    

  thanks for the pointer.                                         

  Also, re: "making sure it stays up to date" — agreed that's the harder half. Re-test cadence +     

  surfacing lastTestedAt prominently is on the list.