The Prompt Filtering Trap
TRIGGER
Intermediate tool results were consuming massive context when agents called tools directly—a 2-hour meeting transcript (50,000 tokens) had to flow through context twice just to copy it between systems, and large datasets like 10,000-row spreadsheets exceeded context limits entirely, breaking workflows.
APPROACH
Route MCP tool calls through a code execution environment where agents write code to fetch, filter, and transform data before returning results to context. Input: raw tool results (10,000 spreadsheet rows). Output: filtered/aggregated results logged to context (5 rows matching criteria). Example: instead of returning all rows from `gdrive.getSheet()`, agent writes `allRows.filter(row => row.Status === 'pending').slice(0, 5)` and only the 5 matching rows enter context.
PATTERN
“50,000 tokens burned on a meeting transcript that needed 500—the "prompt filtering trap" where you ask the model to "return only relevant rows" but it can't filter what it hasn't tokenized. The context cost is already paid. Move filtering upstream to code execution, before the context boundary.”
✓ WORKS WHEN
- Tool results regularly exceed 5,000 tokens before filtering
- Filtering logic can be expressed in code (field selection, row filtering, aggregation)
- Agent has access to a sandboxed code execution environment
- Data processing doesn't require model reasoning to determine relevance
- Multiple data sources need joining or transformation before model analysis
✗ FAILS WHEN
- Determining what's relevant requires semantic understanding only the model can provide
- Tool results are already compact (<1,000 tokens) making filtering overhead net-negative
- Code execution environment isn't available or sandboxing is insufficient for security requirements
- Data structures are too complex or undocumented for reliable code-based filtering
- Real-time streaming is required where batch filtering adds unacceptable latency