Description
Summary
When building agents that use MCP servers (such as Supabase MCP) via the Agents SDK, the runtime context
is successfully passed to each tool invocation and is visible server-side as tool_context.context
. However, the LLM does not have access to this context at prompt time, so it cannot reliably interpolate values (like user_uuid
) from the context into tool call inputs (such as SQL queries). This results in the LLM fabricating/hallucinating UUIDs or placeholders, rather than using the actual runtime value.
Reproduction Steps
- Create an Agent with a tool like
execute_sql
and pass a runtime context (e.g.,{'user_uuid': 'e4122dcd-f5e8-47fb-83c7-effb7176261b'}
) toRunner.run()
. - Instruct the agent (via
instructions
) to use theuser_uuid
from context when generating queries. - Prompt:
Query my weapons using the uuid in context
- Observe via tool debug output that the LLM-generated SQL does not use the context value, but instead inserts either a hallucinated UUID, an example UUID from the instructions, or a placeholder like
'user_uuid'
.
Expected Behavior
The LLM should be able to access tool_context.context
(or any runtime context) and interpolate those values into tool call inputs (e.g., WHERE user_id = '{user_uuid}'
) without the developer having to manually inject these values into the prompt or instructions.
Actual Behavior
The LLM cannot access runtime context directly; it hallucinates values unless the developer dynamically modifies the prompt or input string before each call.
Example Output (Debug Trace):
# Context sent:
{"user_uuid": "e4122dcd-f5e8-47fb-83c7-effb7176261b"}
# Tool invocation payload (should use the context UUID, but instead...)
"query": "SELECT * FROM user_weapon_inventory WHERE user_id = '8588b876-5cf6-4f28-875f-3662d1544f19';"
# or
"query": "SELECT * FROM user_weapon_inventory WHERE user_id = '0f4e9f63-0e9c-4567-987d-0c8b0c5d8f11';"
# or
"query": "SELECT * FROM user_weapon_inventory WHERE user_id = 'user_uuid';"
Activity
rm-openai commentedon May 18, 2025
@dhbrand I can't think of any good way to do this. MCP servers are external dependencies - e.g. they could be remote servers running on someone else's infra. So e.g. the Supabase MCP server doesn't have any code that would read from the context, even if we managed to pass it over somehow.
You could theoretically intercept calls to MCP (i.e. create your own custom MCP server that wraps Supabase MCP; when a tool is called, inject any variables from the context and then call the supabase server tool).