Currently, the proxy requires a Skillberry Store instance to be available. It interacts with the store to retrieve a skill, effectively constructing a logical MCP server from its components (tools and prompts).
The store also acts as a repository for tools, manages these MCP servers, and is capable of executing the tools in an isolated environment.
However, the proxy can also function as a "standalone" agent. In this mode, it receives tools as part of the chat completion request and emits tool_calls as needed, without directly executing the tools itself, as in the Ottto use case.
This issue aims to more clearly define the boundary between these two operational modes.
Currently, the proxy requires a Skillberry Store instance to be available. It interacts with the store to retrieve a skill, effectively constructing a logical MCP server from its components (tools and prompts).
The store also acts as a repository for tools, manages these MCP servers, and is capable of executing the tools in an isolated environment.
However, the proxy can also function as a "standalone" agent. In this mode, it receives tools as part of the chat completion request and emits tool_calls as needed, without directly executing the tools itself, as in the Ottto use case.
This issue aims to more clearly define the boundary between these two operational modes.