Start with the bytes. The naive dump in the write-up pastes roughly 11,000 characters of markdown for a single resource, the SUM ABAP test matrix at `sap-btp://sum-abap-v1` [6]. The usual bloat guard is a slice, `content[:2000]` [7]. That keeps 2,000 characters and discards about 9,000, roughly 82 percent of the document [17], which in this case took the product list and the output-format section with it [7]. The catalog entry that replaces the dump runs three lines and about 148 characters as printed [12], so the same resource costs something near a seventy-fourth of the prompt bytes [18]. Nothing gets amputated, because nothing gets pasted [11].
Then the enforcement question. `read_resource` is registered as a StructuredTool whose `func` is a no-op lambda, and the real fetch is intercepted inside the graph [13]. That is the right place for it, since the graph is what holds the MCP session [15]. It also means the interesting code is not in the excerpt we were given, which stops at `tools =` [19]. Two things have to live at that interception point. One is URI validation: the model is told that "Only resources listed under 'Available Resources' can be read" [14], and a tool description is advice, not a check. The other is an error path, because a call that falls through to the placeholder returns the empty string [13], and an empty string reads to a model as a document that exists and happens to be blank.
The trade is prompt bytes for turns. Under the dump, everything is present before the first token of the answer [4]. Under the loop, each resource costs a full round trip: the model emits a tool_use block, the client executes it, the result goes back into the conversation [2]. Three resources needed for one answer means three of those before the answer starts, and once the content is in the message history it sits in context for every later turn anyway. What the pattern actually saves is the resources the model never asks for, plus the truncation and the binary decode failures you no longer need to handle in the prompt path [5][8].
That saving is a function of description quality. The model picks from names, URIs and one-line descriptions [11], so retrieval recall moves out of your client and into whatever text the MCP server author wrote. "SUM (Software Update Manager) test matrix specification for ABAP products" [12] is specific enough to be found; ten resources all described as API documentation are not. Before adopting this I would want the resource count, the median resource size, and a look at those descriptions, because two 800-character resources do not justify the machinery. I would also split the approval for `invoke_prompt` from `read_resource`: one returns a document, the other injects a named prompt template into the conversation [10], and auto-approving the second [9] is a decision about who gets to write the instructions.
