Passing context outside the LLM to tools

[liorheber]

Hi,

Consider I have agents running on some service that contains the users jwt.
When my agents use tools or MCP servers, I want the agent to act on behalf of the user, meaning that the tools will get the jwt as part of their arguments.
What I don't wan't to do is pass the jwt to the LLM and have it pass it as an argument to the tools.

Is there any way this could be done?

This is very similar to the Context in OpenAI agents where you can add external context to tools without going through the LLM.
An alternative is to create some initialization to the tools before passing them to the agent, but that will require implementation for all tools.

Thanks

[awsarron]

When invoking agents, any kwarg can be passed. These kwargs are then passed to tools when they are invoked. For example:

from strands import Agent
from my_package import my_custom_tool

agent = Agent(tools=[my_custom_tool])

my_value = {"key1": "value1", "key2": 1234}  # can be any variable, object, anything
agent("Do the thing", my_value=my_value)

Now when tools are invoked they can access my_value with kwargs.get("my_value"). For example my_package/my_custom_tool.py:

from typing import Any

from strands.types.tools import ToolResult, ToolUse

TOOL_SPEC = {
    "name": "my_custom_tool",
    "description": "Demonstration tool that must be called for all requests.",
    "inputSchema": {},
}

def my_custom_tool(tool: ToolUse, **kwargs: Any) -> ToolResult:
    # tool has access to my_value in kwargs
    my_value = kwargs.get("my_value")
    print(f"my_value: {my_value}")

    return {
        "toolUseId": tool["toolUseId"],
        "status": "success",
        "content": [{"text": f"my_value: {my_value}"}],
    }

[isacandrei]

Would be cool to be able to do this also via MCP or decorated tools. After checking the code, this is not currently possible.

[dbschmigelski]

Hey @isacandrei , after #557 was merged you can now access the kwargs via decorated tools.

I am curious about your MCP need though as MCP tools are seen more as "off the shelf" compared to something you have configured yourself. But interested to hear more!

[isacandrei]

Hi @dbschmigelski! We have solved the context passing problem for MCP via headers. We are a B2B SaaS company, and we run our own MCP servers. Due to this we need to standardize context passing across the agentic flow.

We greatly appreciate the fix for passing kwargs in decorated tools.

[dbschmigelski]

@isacandrei , we are currently prioritizing #198. Would you be able to speak to the mechanism you are using to pass the headers.

Are you doing this at init, meaning configured in the MCPClient before the Agent is triggered? Or is this information that is changing per tool request? This use case of manipulating/wrapping/modifying MCPTools is a common pattern we have seen, so we want to figure out the easiest way to expose this in Strands directly.

[isacandrei]

hey @dbschmigelski, one way to pass the headers is like this:

def create_streamable_http_transport(user_id):
   return streamablehttp_client(
       "http://localhost:8001/mcp/",
       headers={"current_user": user_id},
   )
   
def run(user_id):
    with MCPClient(lambda : create_streamable_http_transport(user_id)) as streamable_http_mcp_client:
        # Get the tools from the MCP server
        tools = streamable_http_mcp_client.list_tools_sync()

        # Create an agent with the custom MCP client tool
        agent = Agent(
            model=model,
            system_prompt=system_prompt,
            tools=tools,
        )

        print(f"MCP Test Agent Input: {input}")
        return agent(input)

In this very simple example, we control the MCP Server(s), and all of them expect the same headers. However, we definitely see tha tin the future we might want to have different tools passing different headers, but that should not be an issue.

And yes, we always configure this before the Agent is triggered.

I've also been thinking how to make this better. For now, having a provider per each MCP server that injects the necessary header is a decent design. Appreciate you looking into this.