Teaching an LLM to pull MCP Resources and Prompts on demand (instead of drowning it in context)

A developer detailed a technique for integrating Model Context Protocol (MCP) resources and prompts into an LLM's tool-calling loop, converting them into synthetic tools to avoid context bloat. The approach, built on LangGraph and langchain-mcp-adapters, allows the model to fetch resources on demand, preserving full fidelity and reducing token usage.

How we wired the Model Context Protocol's "application-controlled" primitives into a model-controlled tool-calling loop — and why that small shift changes everything about context hygiene. The Model Context Protocol MCP gives a server three ways to expose capability: tools , resources , and prompts . Tools drop straight into an LLM's function-calling loop. Resources and prompts don't — they're application-controlled , so most integrations just dump every resource's content into the system prompt and hope for the best. That approach bloats context, truncates large documents, breaks on binary files, and gives the model zero say in what it actually needs. Our fix: promote resources and prompts into synthetic, auto-approved LLM tools — read resource uri and invoke prompt name . The system prompt now carries only a lightweight catalog URIs + descriptions . The model reads a resource only when it decides it needs one , through the exact same tool-calling machinery it already uses. On-demand, selective, full-fidelity. MCP defines three server capabilities, but the interesting part is who's in control of each: | Primitive | Who decides when it's used | Natural fit for tool-calling? | |---|---|---| Tools | The model it calls them | ✅ Yes — this is what function calling is | Resources | The application / user | ❌ No native hook in the loop | Prompts | The user usually a slash-command | ❌ No native hook in the loop | Tool calling is model-controlled by design: the LLM emits a tool use block, you execute it, you feed the result back. Beautiful. Resources and prompts are application-controlled . The spec's mental model is a human clicking "attach this file" or "/use this prompt template." There is no obvious place for them inside an autonomous agent's reasoning loop. So what do most integrations do? The path of least resistance is to fetch every resource at startup and paste it into the system prompt: Available Resources Resource: SUM ABAP Test Matrix URI: sap-btp://sum-abap-v1 Content: <... 11,000 characters of markdown ... Resource: API Docs URI: sap-btp://api-docs Content: <... more ... Four problems show up fast: content :2000 — and now large documents are silently chopped. In our case the SUM ABAP matrix lost its entire product list and output-format section below the 2,000-char line. blob.as string , hit a UnicodeDecodeError , and quietly emit " No content available " .Here's the shift. The LLM already has a clean, well-understood way to ask for something on demand: it calls a tool. So instead of fighting the control model, we translate it. We register two DARA-internal tools that don't exist on any MCP server — they're synthesized client-side: read resource uri invoke prompt name The system prompt now advertises only a catalog — names, URIs, and descriptions, no content : Available Resources The following resources can be read on demand. To read one, call the read resource tool with its exact URI. Do not assume a resource's contents until you have read it. Resource: SUM ABAP Test Matrix URI: sap-btp://sum-abap-v1 Description: SUM Software Update Manager test matrix specification for ABAP products The model sees what exists, then reaches for exactly what it needs — through the tool loop it already speaks fluently. We built this on top of LangGraph + langchain-mcp-adapters , but the pattern is framework-agnostic. read resource is a StructuredTool with a one-field schema. Its func is a no-op lambda — we never actually run it as a function; we intercept it in the graph see step 3 . python from pydantic import BaseModel, Field from langchain core.tools import StructuredTool class ReadResourceArgs BaseModel : uri: str = Field description="The exact URI of the MCP resource to read, " "e.g. 'sap-btp://sum-abap-v1'." read resource tool = StructuredTool.from function func=lambda uri: "", placeholder — handled in the graph name="read resource", description= "Read the full contents of an MCP resource by its URI. " "Call this when the user asks to read, open, or summarize a resource, " "or when you need a resource's contents to answer. " "Only resources listed under 'Available Resources' can be read." , args schema= ReadResourceArgs, tools = list tools + read resource tool allowed tools without review.append "read resource" auto-approve, no human gate Two things matter here: We fetch resources once the adapter already returns their content as Blob objects and index them by URI so the on-demand read is an O 1 lookup — no second network round-trip: resources content = {} for res in resources or : uri, name, description, content = extract resource fields res URIs can arrive as pydantic AnyUrl objects — normalize to str so the plain-string URI the LLM passes actually matches the dict key. Gotcha uri = str uri if uri is not None else "" if uri and uri = "unknown": resources content uri = {"name": name, "content": content} When the model emits a read resource call, we don't invoke a function — we look up the content and hand it back as a tool message . Because a tool result flows naturally back into the model's context, the content lands only when requested : if tool call "name" == "read resource": uri = str tool call "args" .get "uri", "" res = resources content.get uri if res: new messages.append { "role": "tool", "name": "read resource", "content": res "content" , full content, no truncation "tool call id": tool call "id" , } else: available = list resources content.keys new messages.append { "role": "tool", "name": "read resource", "content": f"Resource '{uri}' not found. Available URIs: {available}", "tool call id": tool call "id" , } continue The mirror image for prompts: invoke prompt injects the template's messages as real Human / AI turns, which is exactly how the MCP spec intends prompts to be surfaced. langchain-mcp-adapters collapses every resource into a Blob : text lands in .data as a str , binary as raw bytes , with the media type on the .mimetype attribute not in metadata — a common trip-up . So we branch on the mime type instead of blindly calling .as string : php def is text mime mime: str - bool: mime = mime or "" .lower .split ";" 0 .strip return mime.startswith "text/" or mime.endswith "+json", "+xml", "+yaml" or mime in {"application/json", "application/xml", "application/yaml"} inside the extractor, for a Blob: data = getattr resource, "data", None if isinstance data, bytes : if is text mime mime : return uri, name, description, data.decode "utf-8" Binary PDF, PNG, ... → an honest descriptor, NOT raw bytes/base64 return uri, name, description, f" Binary resource: {mime or 'application/octet-stream'}, " f"{ human size len data }. This is not text and cannot be inlined; " f"open it with a client that handles its media type. " This is aligned with the MCP spec itself: binary payloads belong in typed media content blocks or are referenced by URI — never stuffed into a text field. A model reading Binary resource: application/pdf, 240.0 KB knows exactly what it's looking at and can decide what to do, instead of choking on garbage or getting a misleading "no content." ┌─────────────────┐ │ User message │ └────────┬────────┘ │ ▼ ┌──────────────────────────────────────────┐ │ System prompt = resource CATALOG only │ │ URIs + descriptions, NO content │ └────────┬─────────────────────────────────┘ │ ▼ ┌───────────────┐ │ LLM decides │ └──┬─────────┬──┘ │ │ needs a │ │ doesn't need one resource│ └──────────────► Answer directly ▼ ┌──────────────────────────┐ │ tool use: read resource │ │ uri │ └────────────┬─────────────┘ ▼ ┌──────────────────────────────┐ │ Graph intercepts the call │ │ auto-approved, no HITL gate │ └────────────┬─────────────────┘ ▼ ┌──────────────────────────────┐ │ Look up URI in content map │ └───────┬───────────────┬──────┘ │ text │ binary ▼ ▼ ┌────────────────┐ ┌──────────────────────┐ │ Full content │ │ Descriptor: │ │ as tool message│ │ mime type + size │ └───────┬────────┘ └───────────┬──────────┘ │ │ └───────────┬───────────┘ ▼ back to LLM ──► answer Only the "needs a resource" branch ever pays the content cost — and it pays the full cost, untruncated, for just that resource. AnyUrl vs str . AnyUrl objects. If your content map is keyed by AnyUrl and the LLM passes a plain string, .get silently misses. Normalize to str on .mimetype , not metadata. langchain-mcp-adapters Blob s, the media type is an attribute; metadata only carries the uri . Read the right field or every binary looks like application/octet-stream . description . Invest in it. func is fine.The binary branch is the single hook for richer handling: extract PDF text server-side, or emit an ImageContent block to a vision-capable model for images. Because everything already funnels through one read resource path, adding a modality is a localized change — not a re-architecture. The bigger takeaway: when a protocol primitive doesn't fit your execution model, don't force the model to swallow it up front. Give the model an affordance to ask , and let the loop it already understands do the rest. Built on the Model Context Protocol 2025-03-26 , LangGraph, and langchain-mcp-adapters. The pattern is framework-agnostic — anywhere you have tool-calling and MCP, you can do this.