Skip to content

Add built-in tools to AIShell #394

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jul 7, 2025
Merged

Conversation

daxian-dbw
Copy link
Member

@daxian-dbw daxian-dbw commented Jul 3, 2025

PR Summary

This PR exposes built-in tools to agents of AIShell. The built-in tools are also exposed as AIFunction instances so they can be consumed similarly as the MCP client tools.
The detailed changes are:

  1. Updated the channel between the AIShell module and aish app to support retrieving context information from the connected PowerShell session. The supported context information includes:

    • CurrentLocation
    • CommandHistory
    • TerminalContent
    • EnvironmentVariables
  2. Updated the AIShell module to

    • keep track of the "current location" and "command history" using InvokeCommand.LocationChangedAction and Runspace.AvailabilityChanged events.
    • support retrieving terminal window content on Windows using screen scraping.
    • support get environment variables and their values (value for a sensitive env var is redacted)
  3. Added the BuiltInTool type that inherits AIFunction. This type has the implementation for both the discovery and invocation of the built-in tool. Built-in tools all depend on a connected PowerShell session being available, so today, for the standalone aish, no built-in tools are available. The following built-in tools are supported with this PR:

    • get_working_directory
    • get_command_history
    • get_terminal_content
    • get_environment_variables
    • copy_text_to_clipboard
    • post_code_to_terminal

    run_command_in_terminal and get_terminal_output will come in a separate PR.

  4. Updated McpManager to expose built-in tools to agents, and call built-in tools as needed.

  5. Updated Host to show built-in tools along with available MCP servers/tools.

  6. Updated Invoke-AIShell to allow passing in the query message with ReadLine call, so that a query message doesn't need to be enclosed in double/single quotes.

@StevenBucher98
Copy link
Collaborator

Love the tools! Few questions/thoughts

  • Can these tools be consumed by other MCP clients if say the AI Shell module started the local MCP service?
  • Does it make sense for 'get_current_location' to be more descriptive like get_current_working_directory or just get_directory, I suggest only for more relevant context to the AI provider.
  • In the same vein as above, does get_powershell_command_history for get_command_history, mainly just seeing how these can also be utilized else where to help other MCP clients get more connected with PS session etc, however I also get it adds weird complexities with say connecting a PS MCP server to VSCode for example, like which PS session etc?
  • Does Get_environment_variable get other variables in the current session too or do you think that needs to be its own thing?
  • Feels like a get_last_error may make sense to implement too so I could ask AI Shell the question "Help me fix this last error" and it would know what to do

@daxian-dbw
Copy link
Member Author

daxian-dbw commented Jul 7, 2025

Can these tools be consumed by other MCP clients if say the AI Shell module started the local MCP service?

The AIShell module cannot be made a MCP server. A local MCP server must be using the stdio transport, meaning a MCP client will start the server process and communicate with it using the standard input and output, so by definition, the MCP server works as a background daemon process, not an interactive one.

However, AIShell module is designed to let AIShell work with an interactive PowerShell session. The standard output/input/error streams of the PowerShell session are not redirected in this case.

Does it make sense for 'get_current_location' to be more descriptive like get_current_working_directory or just get_directory, I suggest only for more relevant context to the AI provider.

That makes sense. I will change it to be get_working_directory.

In the same vein as above, does get_powershell_command_history for get_command_history, mainly just seeing how these can also be utilized else where to help other MCP clients get more connected with PS session etc, however I also get it adds weird complexities with say connecting a PS MCP server to VSCode for example, like which PS session etc?

Those built-in tools cannot be exposed to other MCP clients (see my comments to the 1st question above). PowerShell needs to have its own MCP server.

Does Get_environment_variable get other variables in the current session too or do you think that needs to be its own thing?

No, it only gets the environment variables from the connected PowerShell session. I'm working on another built-in tool run_command_in_terminal. An LLM can use it to run any commands in the connected PowerShell session, so if it has to get a variable, it can do it using that built-in tool.

Feels like a get_last_error may make sense to implement too so I could ask AI Shell the question "Help me fix this last error" and it would know what to do

Good idea! It sounds like a very useful tool to have. I will get to it in a separate PR.

@daxian-dbw daxian-dbw merged commit d24bd31 into PowerShell:main Jul 7, 2025
4 checks passed
@daxian-dbw daxian-dbw deleted the get-context branch July 7, 2025 17:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants