Using Member Functions of a Class as LangGraph Tools: Fixing the 'self' Error

You cannot directly decorate a bound instance method with @tool in LangChain and LangGraph because the decorator wraps the method as a StructuredTool, and at runtime the already-bound self conflicts with an implicit self passed by the framework, producing TypeError: StructuredTool._run() got multiple values for argument 'self'. The fix is to wrap the instance method inside a closure that captures self and then decorate that closure with @tool. This keeps your class-based state (like a local directory path) accessible while giving LangChain a plain callable it can invoke correctly.

The Full Answer

When you build an agent with LangChain and LangGraph, you often want tools that share state. A natural design is to put those tools as methods on a class, so they can access instance attributes like a base directory, a database connection, or a configuration object. The code below shows the pattern that triggers the error.

The Problem: Decorating a Bound Method

Consider this FileInterface class. The intent is to store a local directory path in self.localdir and expose a read_file tool that only reads files inside that directory.

from pathlib import Path
from langchain_core.tools import tool

class FileInterface:
    def __init__(self):
        self.localdir = Path.cwd()

    def get_tools(self):
        return [self.read_file, ...]

    @tool
    def read_file(self, path: str) -> str:
        """tool for reading file at path"""
        # ... check path is inside self.localdir ...
        return path.read()

When you instantiate the class and pass the tools to create_agent, the agent invokes the tool and you get:

TypeError: StructuredTool._run() got multiple values for argument 'self'

The full traceback (from Source 1) shows the error originates in langchain_core/tools/base.py at the _run method. The root cause is explained in Source 2: when you decorate a method with @tool, LangChain wraps it as a StructuredTool. But because the method is already bound to an instance (i.e., self is already attached), the framework passes another self argument at runtime. Python then sees two values for self and raises the error.

The Solution: Closure Wrapping

The accepted solution from Source 2 is to not decorate the method directly. Instead, you create a plain function inside a tools() method (or any method that returns the tool list) and decorate that function with @tool. Inside that function, you call the real instance method via the captured self.

Here is the corrected class:

from pathlib import Path
from langchain_core.tools import tool

class FileInterface:

    def __init__(self, base_dir: str):
        self.base_dir = Path(base_dir)

    def _read_file(self, filename: str) -> str:
        path = self.base_dir / filename
        return path.read_text()

    def tools(self):
        # ---- you must wrap in a closure like this ----
        @tool
        def read_file(filename: str) -> str:
            """Read a file from disk inside base_dir"""
            return self._read_file(filename)

        return [read_file]

Key changes:

• The @tool decorator is applied to a local function read_file, not to the method _read_file. This local function is a plain callable, not a bound method, so LangChain can wrap it without the self conflict.
• The actual work is delegated to self._read_file(filename), which has full access to self.base_dir and any other instance state.
• The method that returns tools is named tools() (not get_tools()), but any name works. The important thing is that it creates a new closure each time it is called.

Full Working Example

Source 2 provides a complete, tested example using ChatOllama and the create_agent function. Here it is with the original imports and structure:

from pathlib import Path

from langchain_core.tools import tool
from langchain.agents import create_agent
from langchain_ollama.chat_models import ChatOllama

class FileInterface:

    def __init__(self, base_dir: str):
        self.base_dir = Path(base_dir)

    def _read_file(self, filename: str) -> str:
        path = self.base_dir / filename
        return path.read_text()

    def tools(self):
        # ---- you must wrap in a closure like this ----
        @tool
        def read_file(filename: str) -> str:
            """Read a file from disk inside base_dir"""
            return self._read_file(filename)

        return [read_file]

# -------------- usage --------------
# 1) instantiate your class
fs = FileInterface(".")

# 2) define your model
llm = ChatOllama(
    model="llama3.2:latest"
)

# 3) build an agent with your tools
agent = create_agent(llm, tools=fs.tools())

# 4) call it
response = agent.invoke({
    "messages": [
        {"role": "user", "content": "Open the file README.md and summarize it in one bullet point."}
    ]
})
print(response)

When run, the agent produces a tool_calls entry showing that the read_file tool was invoked with {'filename': 'README.md'}. The final AIMessage contains the summary. You can extract the last message with:

print(response["messages"][-1].content)

Output (from Source 2):

Here is a summary of the README.md file in one bullet point:

* The LangChain project provides a set of tools that enable models to interact with external systems such as APIs, databases, or file systems using structured input. These tools extend model capabilities by letting them interface directly with the world through well-defined inputs and outputs.

Why This Works

The closure pattern works because of how Python's scoping rules interact with LangChain's tool wrapping. When you write:

def tools(self):
    @tool
    def read_file(filename: str) -> str:
        return self._read_file(filename)
    return [read_file]

The read_file function is defined inside the tools method. It references self, which is a parameter of the enclosing method. At the time tools() is called, self is bound to the FileInterface instance. The read_file function captures that self reference in its closure. When LangChain later invokes read_file(filename), it calls a plain function with one argument (filename). There is no self parameter in the function signature, so there is no conflict. Inside the function, self._read_file(filename) uses the captured self to access the instance.

This is different from decorating the method directly:

@tool
def read_file(self, path: str) -> str:
    ...

Here, the function signature includes self. When LangChain wraps it, it creates a StructuredTool whose _run method expects the arguments defined in the signature. But because the method is bound, Python already supplies self when the method is called as self.read_file. The framework then tries to pass self again, causing the duplicate argument error.

Alternative Approaches (Not in Sources, but Worth Knowing)

While the sources only present the closure pattern, there are other ways to achieve the same result. These are not covered in the source material but are common in the LangChain community:

• Using functools.partial: You can bind self to a method using functools.partial and then wrap the result with @tool. However, this can be fragile because partial objects may not have the right signature for LangChain's schema inference.
• Creating a tool from a function that takes a class instance as a parameter: You can define a standalone function that accepts the class instance as a parameter and use InjectedToolArg or ToolRuntime to pass it. This is more complex and not shown in the sources.
• Using BaseTool subclass: You can subclass BaseTool and implement _run yourself, storing the class instance as an attribute. This gives you full control but requires more boilerplate.

The closure pattern is the simplest and most maintainable approach, and it is the one confirmed to work by the accepted answer.