New: Cookbooks and AI ExplanationsStep-by-Step recipes to solve problems connected to Roadmaps and Cheat Sheets. Need more details? Use AI buttons for structured and simple explanations with concrete examples throughout the whole platform.Take a look
My server has a lookup the model calls before almost every real request, one extra round trip apiece, for a value that barely changes from one conversation to the next.
What you'll have at the end
A read-only MCP resource holding the lookup, with prep calls for the same job measured before and after
You need
A working MCP server with at least one tool whose real job is a lookup the model needs before almost every other call, a name-to-id mapping or a settings list that gets read far more often than it changes, plus an agent loop you can run a handful of real tasks through while watching which tools fire.
Not covered
Turning a value that genuinely depends on the current request, a live price or a status check tied to one specific record, into a resource; that kind of value stays a tool.
Catch a broken MCP tool with Inspector
confirm the new resource actually shows up, and the old tool is really gone, before wiring either into your loop.
MCP tool overload makes your model pick the wrong one
when the real problem is too many overlapping tools rather than one repeated lookup, that calls for a different fix than moving one value into a resource.
Checked 15 Aug 2026
Part of the MCP Servers Implementation cookbook