Serena 代码助手
STDIO语义化代码分析与编辑的智能编程助手
语义化代码分析与编辑的智能编程助手
Here is a demonstration of Serena implementing a small feature for itself (a better log GUI) with Claude Desktop. Note how Serena's tools enable Claude to find and edit the right symbols.
https://github.com/user-attachments/assets/6eaa9aa1-610d-4723-a2d6-bf1e487ba753
Serena is under active development! See the latest updates, upcoming features, and lessons learned to stay up to date.
Serena provides the necessary tools for coding workflows, but an LLM is required to do the actual work, orchestrating tool use.
For example, supercharge the performance of Claude Code with a one-line shell command.
Serena can be integrated with an LLM in several ways:
Serena's semantic code analysis capabilities build on language servers using the widely implemented language server protocol (LSP). The LSP provides a set of versatile code querying and editing functionalities based on symbolic understanding of the code. Equipped with these capabilities, Serena discovers and edits code just like a seasoned developer making use of an IDE's capabilities would. Serena can efficiently find the right context and do the right thing even in very large and complex projects! So not only is it free and open-source, it frequently achieves better results than existing solutions that charge a premium.
Language servers provide support for a wide range of programming languages. With Serena, we provide
direct, out-of-the-box support for:
indirect support (may require some code changes/manual installation) for:
These languages are supported by the language server library multilspy, which Serena uses under the hood. But we did not explicitly test whether the support for these languages actually works.
Further languages can, in principle, easily be supported by providing a shallow adapter for a new language server implementation.
You can use Serena for any coding tasks – whether it is focussed on analysis, planning, designing new components or refactoring existing ones. Since Serena's tools allow an LLM to close the cognitive perception-action loop, agents based on Serena can autonomously carry out coding tasks from start to finish – from the initial analysis to the implementation, testing and, finally, the version control system commit.
Serena can read, write and execute code, read logs and the terminal output. While we do not necessarily encourage it, "vibe coding" is certainly possible, and if you want to almost feel like "the code no longer exists", you may find Serena even more adequate for vibing than an agent inside an IDE (since you will have a separate GUI that really lets you forget).
Even the free tier of Anthropic's Claude has support for MCP Servers, so you can use Serena with Claude for free.
Presumably, the same will soon be possible with ChatGPT Desktop once support for MCP servers is added.
Through Agno, you furthermore have the option to use Serena with a free/open-weights model.
Serena is Oraios AI's contribution to the developer community.
We use it ourselves on a regular basis.
We got tired of having to pay multiple IDE-based subscriptions (such as Windsurf or Cursor) that forced us to keep purchasing tokens on top of the chat subscription costs we already had. The substantial API costs incurred by tools like Claude Code, Cline, Aider and other API-based tools are similarly unattractive. We thus built Serena with the prospect of being able to cancel most other subscriptions.
Serena can be used in various ways, below you will find instructions for selected integrations.
Serena is managed by uv, so you will need to install it).
Serena is a great way to make Claude Code both cheaper and more powerful! We are collecting several examples for that and have heard very positive feedback so far. Claude Code users can add serena with (from the project dir)
claude mcp add serena -- uvx --from git+https://github.com/oraios/serena serena-mcp-server --context ide-assistant --project $(pwd)
You should ask claude to read the initial instructions as the first prompt, where it will receive information on how to use Serena's tools. We also recommend that you index your code once before starting (especially for larger projects), it will accelerate the symbolic operations.
# from the project directory, or pass the path to the project as argument uvx --from git+https://github.com/oraios/serena index-project
You can either
If you just want the default config, you can skip this part, and a config file will be created when you first run Serena.cp src/serena/resources/serena_config.template.yml serena_config.yml
or use uvx to run Serena directly by relying on
uvx --from git+https://github.com/oraios/serena serena-mcp-server.exe
in your MCP config (delete the .exe on macOS or Linux).
You can now add Serena to your MCP client as described below for various clients and activate your first project. For larger projects, we recommend that you first index them to accelerate Serena's tools on the first usage.
uvx --from git+https://github.com/oraios/serena index-project /path/to/project
In the default configuration, Serena will start a small dashboard on localhost that will display logs and allow shutting down the MCP server (since many clients fail to cleanup processes, leaving zombies behind). If you don't want that, simply set
web_dashboardtoFalsein yourserena_config.ymlor pass
Serena's behavior (like available projects, active tools and prompts) is configured in four places:
serena_config.yml for general settings that apply to all clients and projectsserena-mcp-server in your client's config (see below),
which will apply to all sessions started by the respective client. In particular, the context parameter
should be set appropriately for Serena to be best adjusted to existing tools and capabilities of your client.
See for a detailed explanation. You can override all entries from the serena_config.yml through command line arguments..serena/project.yml file within your project. This will hold project-level configuration that is used whenever
that project is activated.⚠️ Note: Serena is under active development. We are continuously adding features, improving stability and the UX. As a result, configuration may change in a breaking manner. If you have an invalid configuration, the MCP server or Serena-based Agent may fail to start (investigate the MCP logs in the former case). Check the changelog and the configuration templates when updating Serena, adapting your configurations accordingly.
After the initial setup, continue with one of the sections below, depending on how you want to use Serena.
You can just ask the LLM to show you the config of your session, Serena has a tool for it.
The recommended way is to just ask the LLM to activate a project by providing it an absolute path to, or, in case the project was activated in the past, by it's name. The default project name is the directory name.
All projects that have been activated will be automatically added to your serena_config.yml, and for each
project, the file .serena/project.yml will be generated. You can adjust the latter, e.g., by changing the name
(which you refer to during the activation) or other options. Make sure to not have two different projects with the
same name.
If you are mostly working with the same project, you can also configure to always activate a project at startup
by passing --project <path_or_name> to the serena-mcp-server command in your client's MCP config.
Configure the MCP server in your client.
For Claude Desktop (available for Windows and macOS), go to File / Settings / Developer / MCP Servers / Edit Config,
which will let you open the JSON file claude_desktop_config.json. Add the following (with adjusted paths) to enable Serena:
{ "mcpServers": { "serena": { "command": "/abs/path/to/uv", "args": ["run", "--directory", "/abs/path/to/serena", "serena-mcp-server"] } } }
⚠️ EXPERIMENTAL: Docker support is currently experimental with several limitations. Please read the Docker documentation for important caveats before using.
Alternatively, you can run Serena using Docker:
{ "mcpServers": { "serena": { "command": "docker", "args": ["run", "--rm", "-i", "--network", "host", "-v", "/path/to/your/projects:/workspaces/projects", "ghcr.io/oraios/serena:latest", "serena-mcp-server", "--transport", "stdio"] } } }
Replace /path/to/your/projects with the absolute path to your projects directory. The Docker approach provides:
See the Docker documentation for detailed setup instructions, configuration options, and known limitations.
If you are using paths containing backslashes for paths on Windows
(note that you can also just use forward slashes), be sure to escape them correctly (\\).
That's it! Save the config and then restart Claude Desktop. You are ready for activating your first project
ℹ️ You can further customize the run command, see
uv run serena-mcp-server --help
ℹ️ You can use Serena without cloning or configuring it explicitly by using the Docker image above or:
{ "mcpServers": { "serena": { "command": "uvx", "args": ["--from", "git+https://github.com/oraios/serena", "serena-mcp-server"] } } }
Some client/OS/setup configurations were reported to cause issues when using Serena with the standard stdio protocol, where the MCP server is started by the client application.
If you experience such problems, you can start Serena in sse mode by running, e.g.,
uv run serena-mcp-server --transport sse --port 9121
Then configure your client to connect to http://localhost:9121.
Note: on Windows and macOS there are official Claude Desktop applications by Anthropic, for Linux there is an open-source community version.
⚠️ Be sure to fully quit the Claude Desktop application, as closing Claude will just minimize it to the system tray – at least on Windows.
⚠️ Some clients, currently including Claude Desktop, may leave behind zombie processes. You will have to find and terminate them manually then. With Serena, you can activate the dashboard to prevent unnoted processes and also use the dashboard for shutting down Serena.
After restarting, you should see Serena's tools in your chat interface (notice the small hammer icon).
⚠️ Tool Names: Claude Desktop (and most MCP Clients) don't resolve the name of the server. So you shouldn't say something like "use Serena's tools". Instead, you can instruct the LLM to use symbolic tools or to use a particular tool by referring to its name. Moreover, in some clients, if you use multiple MCP Servers, you might get tool name collisions which lead to undefined behavior.
ℹ️ Note that MCP servers which use stdio as a protocol are somewhat unusual as far as client/server architectures go, as the server necessarily has to be started by the client in order for communication to take place via the server's standard input/output stream. In other words, you do not need to start the server yourself. The client application (e.g. Claude Desktop) takes care of this and therefore needs to be configured with a launch command. In SSE transport you control the lifetime of the server yourself.
For more information on MCP servers with Claude Desktop, see the official quick start guide.
Being an MCP Server, Serena can be included in any MCP Client. The same configuration as above,
perhaps with small client-specific modifications, should work. Most of the popular
existing coding assistants (IDE extensions or VSCode-like IDEs) support connections
to MCP Servers. It is ** recommended to use the ide-assistant context** for these integrations by adding "--context", "ide-assistant" to the args in your MCP client's configuration. Including Serena generally boosts their performance
by providing them tools for symbolic operations.
In this case, the billing for the usage continues to be controlled by the client of your choice (unlike with the Claude Desktop client). But you may still want to use Serena through such an approach, e.g., for one of the following reasons:
goose is a standalone coding agent which has an integration for MCP servers and offers a CLI (as well as a GUI on macOS). Using goose is currently the simplest way of running Serena through a CLI-based UI with an LLM of your choice.
Follow the instructions here to install it.
After that, use goose configure to add an extension. For adding Serena, choose the option Command-line Extension, name it Serena and add the following as command:
/abs/path/to/uv run --directory /abs/path/to/serena serena-mcp-server --project /optional/abs/path/to/project
Since Serena can do all necessary editing and command operations, you should disable the developer extension that goose enables by default.
For that execute
goose configure
again, choose the option Toggle Extensions, and make sure Serena is enabled selected while developer is not.
That's it. Read through the configuration options of goose to see what you can do with it (which is a lot, like setting different levels of permissions for tool execution).
Goose does not seem to always properly terminate python processes for MCP servers when a session ends. You may want to disable the Serena GUI and/or to manually cleanup any running python processes after finishing your work with goose.
Agno is a model-agnostic agent framework that allows you to turn Serena into an agent (independent of the MCP technology) with a large number of underlying LLMs. Agno is currently the simplest way of running Serena in a chat GUI with an LLM of your choice (unless you are using a Mac, then you might prefer goose, which requires almost no setup).
While Agno is not yet entirely stable, we chose it, because it comes with its own open-source UI, making it easy to directly use the agent using a chat interface. With Agno, Serena is turned into an agent (so no longer an MCP Server), so it can be used in programmatic ways (for example for benchmarking or within your application).
Here's how it works (see also Agno's documentation):
Download the agent-ui code with npx
npx create-agent-ui@latest
or, alternatively, clone it manually:
git clone https://github.com/agno-agi/agent-ui.git cd agent-ui pnpm install pnpm dev
Install serena with the optional requirements:
# You can also only select agno,google or agno,anthropic instead of all-extras uv pip install --all-extras -r pyproject.toml -e .
Copy .env.example to .env and fill in the API keys for the provider(s) you
intend to use.
Start the agno agent app with
uv run python scripts/agno_agent.py
By default, the script uses Claude as the model, but you can choose any model supported by Agno (which is essentially any existing model).
In a new terminal, start the agno UI with
cd agent-ui pnpm dev
Connect the UI to the agent you started above and start chatting. You will have the same tools as in the MCP server version.
Here is a short demo of Serena performing a small analysis task with the newest Gemini model:
https://github.com/user-attachments/assets/ccfcb968-277d-4ca9-af7f-b84578858c62
⚠️ IMPORTANT: In contrast to the MCP server approach, tool execution in the Agno UI does
not ask for the user's permission. The shell tool is particularly critical, as it can perform arbitrary code execution.
While we have never encountered any issues with
this in our testing with Claude, allowing this may not be entirely safe.
You may choose to disable certain tools for your setup in your Serena project's
configuration file (.yml).
It should be straightforward to incorporate Serena into any agent framework (like pydantic-ai, langgraph or others). Typically, you need only to write an adapter for Serena's tools to the tool representation in the framework of your choice, as was done by us for Agno with SerenaAgnoToolkit.
Serena combines tools for semantic code retrieval with editing capabilities and shell execution. Serena's behavior can be further customized through Modes and Contexts. Find the complete list of tools below.
The use of all tools is generally recommended, as this allows Serena to provide the most value: Only by executing shell commands (in particular, tests) can Serena identify and correct mistakes autonomously.
However, it should be noted that the execute_shell_command tool allows for arbitrary code execution.
When using Serena as an MCP Server, clients will typically ask the user for permission
before executing a tool, so as long as the user inspects execution parameters beforehand,
this should not be a problem.
However, if you have concerns, you can choose to disable certain commands in your project's
.yml configuration file.
If you only want to use Serena purely for analyzing code and suggesting implementations
without modifying the codebase, you can enable read-only mode by setting read_only: true in your project configuration file.
This will automatically disable all editing tools and prevent any modifications to your codebase while still
allowing all analysis and exploration capabilities.
In general, be sure to back up your work and use a version control system in order to avoid losing any work.
Serena's behavior and toolset can be adjusted using contexts and modes. These allow for a high degree of customization to best suit your workflow and the environment Serena is operating in.
A context defines the general environment in which Serena is operating. It influences the initial system prompt and the set of available tools. A context is set at startup when launching Serena (e.g., via CLI options for an MCP server or in the agent script) and cannot be changed during an active session.
Serena comes with pre-defined contexts:
desktop-app: Tailored for use with desktop applications like Claude Desktop. This is the default.agent: Designed for scenarios where Serena acts as a more autonomous agent, for example, when used with Agno.ide-assistant: Optimized for integration into IDEs like VSCode, Cursor, or Cline, focusing on in-editor coding assistance.
Choose the context that best matches the type of integration you are using.When launching Serena, specify the context using --context <context-name>.
Note that for cases where parameter lists are specified (e.g. Claude Desktop), you must add two parameters to the list.
Modes further refine Serena's behavior for specific types of tasks or interaction styles. Multiple modes can be active simultaneously, allowing you to combine their effects. Modes influence the system prompt and can also alter the set of available tools by excluding certain ones.
Examples of built-in modes include:
planning: Focuses Serena on planning and analysis tasks.editing: Optimizes Serena for direct code modification tasks.interactive: Suitable for a conversational, back-and-forth interaction style.one-shot: Configures Serena for tasks that should be completed in a single response, often used with planning for generating reports or initial plans.no-onboarding: Skips the initial onboarding process if it's not needed for a particular session.onboarding: (Usually triggered automatically) Focuses on the project onboarding process.Modes can be set at startup (similar to contexts) but can also be switched dynamically during a session. You can instruct the LLM to use the switch_modes tool to activate a different set of modes (e.g., "switch to planning and one-shot modes").
When launching Serena, specify modes using --mode <mode-name>; multiple modes can be specified, e.g. --mode planning --mode no-onboarding.
:warning: Mode Compatibility: While you can combine modes, some may be semantically incompatible (e.g., interactive and one-shot). Serena currently does not prevent incompatible combinations; it is up to the user to choose sensible mode configurations.
You can create your own contexts and modes to precisely tailor Serena to your needs in two ways:
.yml files in the config/contexts/ or config/modes/ directories within your local Serena repository. These custom contexts/modes will be automatically registered and available for use by their name (filename without the .yml extension). They will also appear in listings of available contexts/modes..yml file for a context or mode.A context or mode YAML file typically defines:
name: (Optional if filename is used) The name of the context/mode.prompt: A string that will be incorporated into Serena's system prompt.description: (Optional) A brief description.excluded_tools: A list of tool names (strings) to disable when this context/mode is active.This customization allows for deep integration and adaptation of Serena to specific project requirements or personal preferences.
By default, Serena will perform an onboarding process when it is started for the first time for a project. The goal of the onboarding is for Serena to get familiar with the project and to store memories, which it can then draw upon in future interactions. If an LLM should fail to complete the onboarding and does not actually write the respective memories to disk, you may need to ask it to do so explicitly.
The onboarding will usually read a lot of content from the project, thus filling up the context. It can therefore be advisable to switch to another conversation once the onboarding is complete. After the onboarding, we recommend that you have a quick look at the memories and, if necessary, edit them or add additional ones.
Memories are files stored in .serena/memories/ in the project directory,
which the agent can choose to read in subsequent interactions.
Feel free to read and adjust them as needed; you can also add new ones manually.
Every file in the .serena/memories/ directory is a memory file.
Whenever Serena starts working on a project, the list of memories is
provided, and the agent can decide to read them.
We found that memories can significantly improve the user experience with Serena.
Serena uses the code structure for finding, reading and editing code. This means that it will
work well with well-structured code but may perform poorly on fully unstructured one (like a "God class"
with enormous, non-modular functions).
Furthermore, for languages that are not statically typed, type annotations are highly beneficial.
It is best to start a code generation task from a clean git state. Not only will
this make it easier for you to inspect the changes, but also the model itself will
have a chance of seeing what it has changed by calling git diff and thereby
correct itself or continue working in a followup conversation if needed.
:warning: Important: since Serena will write to files using the system-native line endings
and it might want to look at the git diff, it is important to
set git config core.autocrlf to true on Windows.
With git config core.autocrlf set to false on Windows, you may end up with huge diffs
only due to line endings. It is generally a good idea to globally enable this git setting on Windows:
git config --global core.autocrlf true
Serena can successfully complete tasks in an agent loop, where it iteratively acquires information, performs actions, and reflects on the results. However, Serena cannot use a debugger; it must rely on the results of program executions, linting results, and test results to assess the correctness of its actions. Therefore, software that is designed to meaningful interpretable outputs (e.g. log messages) and that has a good test coverage is much easier to work with for Serena.
We generally recommend to start an editing task from a state where all linting checks and tests pass.
We found that it is often a good idea to spend some time conceptualizing and planning a task before actually implementing it, especially for non-trivial task. This helps both in achieving better results and in increasing the feeling of control and staying in the loop. You can make a detailed plan in one session, where Serena may read a lot of your code to build up the context, and then continue with the implementation in another (potentially after creating suitable memories).
In our experience, LLMs are bad at counting, i.e. they have problems inserting blocks of code in the right place. Most editing operations can be performed at the symbolic level, allowing this problem is overcome. However, sometimes, line-level insertions are useful.
Serena is instructed to double-check the line numbers and any code blocks that it will
edit, but you may find it useful to explicitly tell it how to edit code if you run into
problems.
We are working on making Serena's editing capabilities more robust.
For long and complicated tasks, or tasks where Serena has read a lot of content, you may come close to the limits of context tokens. In that case, it is often a good idea to continue in a new conversation. Serena has a dedicated tool to create a summary of the current state of the progress and all relevant info for continuing it. You can request to create this summary and write it to a memory. Then, in a new conversation, you can just ask Serena to read the memory and continue with the task. In our experience, this worked really well. On the up-side, since in a single session there is no summarization involved, Serena does not usually get lost (unlike some other agents that summarize under the hood), and it is also instructed to occasionally check whether it's on the right track.
Moreover, Serena is instructed to be frugal with context (e.g., to not read bodies of code symbols unnecessarily), but we found that Claude is not always very good in being frugal (Gemini seemed better at it). You can explicitly instruct it to not read the bodies if you know that it's not needed.
When using Serena through an MCP Client, you can use it together with other MCP servers. However, beware of tool name collisions! See info on that above.
Currently, there is a collision with the popular Filesystem MCP Server. Since Serena also provides filesystem operations, there is likely no need to ever enable these two simultaneously.
Serena provides two convenient ways of accessing the logs of the current session:
via the web-based dashboard (enabled by default)
This is supported on all platforms.
By default, it will be accessible at http://localhost:24282/dashboard/index.html,
but a higher port may be used if the default port is unavailable/multiple instances are running.
via the GUI tool (disabled by default)
This is mainly supported on Windows, but it may also work on Linux; macOS is unsupported.
Both can be enabled or disabled in Serena's configuration file (serena_config.yml, see above).
If enabled, they will automatically be opened as soon as the Serena agent/MCP server is started.
In addition to viewing logs, both tools allow to shut down the Serena agent. This function is provided, because clients like Claude Desktop may fail to terminate the MCP server subprocess when they themselves are closed.
Support for MCP Servers in Claude Desktop and the various MCP Server SDKs are relatively new developments and may display instabilities.
The working configuration of an MCP server may vary from platform to platform and from client to client. We recommend always using absolute paths, as relative paths may be sources of errors. The language server is running in a separate sub-process and is called with asyncio – sometimes a client may make it crash. If you have Serena's log window enabled, and it disappears, you'll know what happened.
Some clients (like goose) may not properly terminate MCP servers, look out for hanging python processes and terminate them manually, if needed.
To our knowledge, Serena is the first fully-featured coding agent where the entire functionality is available through an MCP server, thus not requiring API keys or subscriptions.
The most prominent subscription-based coding agents are parts of IDEs like Windsurf, Cursor and VSCode. Serena's functionality is similar to Cursor's Agent, Windsurf's Cascade or VSCode's upcoming agent mode.
Serena has the advantage of not requiring a subscription. A potential disadvantage is that it is not directly integrated into an IDE, so the inspection of newly written code is not as seamless.
More technical differences are:
An alternative to subscription-based agents are API-based agents like Claude Code, Cline, Aider, Roo Code and others, where the usage costs map directly to the API costs of the underlying LLM. Some of them (like Cline) can even be included in IDEs as an extension. They are often very powerful and their main downside are the (potentially very high) API costs.
Serena itself can be used as an API-based agent (see the section on Agno above). We have not yet written a CLI tool or a dedicated IDE extension for Serena (and there is probably no need for the latter, as Serena can already be used with any IDE that supports MCP servers). If there is demand for a Serena as a CLI tool like Claude Code, we will consider writing one.
The main difference between Serena and other API-based agents is that Serena can also be used as an MCP server, thus not requiring an API key and bypassing the API costs. This is a unique feature of Serena.
There are other MCP servers designed for coding, like DesktopCommander and codemcp. However, to the best of our knowledge, none of them provide semantic code retrieval and editing tools; they rely purely on text-based analysis. It is the integration of language servers and the MCP that makes Serena unique and so powerful for challenging coding tasks, especially in the context of larger codebases.
We built Serena on top of multiple existing open-source technologies, the most important ones being:
Without these projects, Serena would not have been possible (or would have been significantly more difficult to build).
It is straightforward to extend Serena's AI functionality with your own ideas.
Simply implement a new tool by subclassing
serena.agent.Tool and implement the apply method with a signature
that matches the tool's requirements.
Once implemented, SerenaAgent will automatically have access to the new tool.
It is also relatively straightforward to add support for a new programming language.
We look forward to seeing what the community will come up with! For details on contributing, see here.
Here is the full list of Serena's tools with a short description (output of uv run serena-list-tools):
activate_project: Activates a project by name.check_onboarding_performed: Checks whether project onboarding was already performed.create_text_file: Creates/overwrites a file in the project directory.delete_lines: Deletes a range of lines within a file.delete_memory: Deletes a memory from Serena's project-specific memory store.execute_shell_command: Executes a shell command.find_referencing_code_snippets: Finds code snippets in which the symbol at the given location is referenced.find_referencing_symbols: Finds symbols that reference the symbol at the given location (optionally filtered by type).find_symbol: Performs a global (or local) search for symbols with/containing a given name/substring (optionally filtered by type).get_active_project: Gets the name of the currently active project (if any) and lists existing projectsget_current_config: Prints the current configuration of the agent, including the active modes, tools, and context.get_symbols_overview: Gets an overview of the top-level symbols defined in a given file or directory.initial_instructions: Gets the initial instructions for the current project.
Should only be used in settings where the system prompt cannot be set,
e.g. in clients you have no control over, like Claude Desktop.insert_after_symbol: Inserts content after the end of the definition of a given symbol.insert_at_line: Inserts content at a given line in a file.insert_before_symbol: Inserts content before the beginning of the definition of a given symbol.list_dir: Lists files and directories in the given directory (optionally with recursion).list_memories: Lists memories in Serena's project-specific memory store.onboarding: Performs onboarding (identifying the project structure and essential tasks, e.g. for testing or building).prepare_for_new_conversation: Provides instructions for preparing for a new conversation (in order to continue with the necessary context).read_file: Reads a file within the project directory.read_memory: Reads the memory with the given name from Serena's project-specific memory store.replace_lines: Replaces a range of lines within a file with new content.replace_symbol_body: Replaces the full definition of a symbol.restart_language_server: Restarts the language server, may be necessary when edits not through Serena happen.search_for_pattern: Performs a search for a pattern in the project.summarize_changes: Provides instructions for summarizing the changes made to the codebase.switch_modes: Activates modes by providing a list of their namesthink_about_collected_information: Thinking tool for pondering the completeness of collected information.think_about_task_adherence: Thinking tool for determining whether the agent is still on track with the current task.think_about_whether_you_are_done: Thinking tool for determining whether the task is truly completed.write_memory: Writes a named memory (for future reference) to Serena's project-specific memory store.