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';"