I am using function calling tools to implement custom applications. As I progress I noticed a pattern where alot of tools are reusable.
I had the idea of packaging tools definitions and code to reuse them.
I am searching for existing solutions to share, distribute, search, dynamically load tools at runtime, auto generate tools, automate AI to look in registry for existing tool.
Hereās a breakdown of the sequence process for the architecture:
Tools API Sequence:
GET /api/tools: Fetches a list of tools from the database (DB).
POST /api/tools: Creates a new tool entry in the tools table of DB.
GET /api/tools/{id}: Retrieves a specific tool by its id from the tools table in DB.
PUT /api/tools/{id}: Updates a specific tool identified by id in the tools table of DB.
DELETE /api/tools/{id}: Deletes a specific tool identified by id from the tools table in DB.
POST /api/tools/search: Executes a search query for tools based on criteria sent to the API.
Supabase DB Interaction:
Tables: Contains entities tools and tool_versions.
Interaction: Tools API interacts with DB to perform CRUD operations (Create, Read, Update, Delete) on tools and tool_versions entities.
Supabase Storage:
Handles storage for tool code files (Supabase Storage).
Used for uploading and retrieving tool code files associated with tools stored in DB.
SDK Components:
list: Fetches a list of tools (ListTool communicates with GetToolsAPI).
create: Creates a new tool (CreateTool interacts with PostToolsAPI).
get: Retrieves a specific tool (GetTool communicates with GetToolByIdAPI).
update: Updates an existing tool (UpdateTool interacts with UpdateToolAPI).
delete: Deletes a tool (DeleteTool communicates with DeleteToolAPI).
search: Performs a search for tools (SearchTool communicates with SearchToolsAPI).
authenticate: Handles authentication for SDK operations.
Tool Client:
load (DynamicImportModule): Dynamically imports tool code for execution.
Tool Executor: Executes tools after dynamically importing their code.
Interacts with GetToolByIdAPI to fetch tool details and Storage for storing/retrieving tool code files.
These components collectively form the architecture described in diagram, focusing on API interactions, database operations, storage management, SDK functionalities, and tool execution capabilities
Looks promising. Supabase is a great platform as well. Initially I wasnāt a fan of Deno but I really grew to love it more. I see a future where most people wonāt even code their model interactions. It would all be done using a Zapier-like platform where tool calls are hosted.
Hereās another site that does something similar. Maybe worth collaborating?
This is more geared towards GPT actions though.
The site hasnāt changed for months though. Iām wondering if it was abandoned
Good luck with your progress! Definitely a good idea
I looked at this a little before. I think it is interesting as well.
A couple of quick question:
Are the functions are expected to be execution context free? (i.e. if these functions import non standard packages and/or refer to global variables, how is this supposed to be handled?
Why cannot this be done in context of the data structures already available in OpenAI context (as opposed tp an additional database)?
Look at this little tool for an example. It is integrated live connected to a database, interacting with it. Giving me insights, query, modify schema, make diagram by natural language.
I am aiming at packaging that āSkillā as tool to reuse it at will with simple drag and drop without coding from my tool repo so I never have to recode that again. I want to build a āSkillā repository so anyone can contribute and we can share those skills to create anything. For example: never code again filesystem access, Github integrations, etc. Eventually, generate those skills by AI on the fly as it learns and gets smarter. It will use them automatically at will. Get it?
I did implement runtime code that integrates itself at runtime. So AI can generate tools, upload the code, use it. Itās very early stage but itās working.
Good call. The no-code visual flow will be what makes it extra special.
It will be a grand project, in terms of size. I had thought of something similar almost a year ago. Unfortunately I used ReactFlow to visualize it and then used just NodeJS to create these āblocksā. ReactFlow was far too limiting for the scale I wanted.
If I were to attempt it again I would use Rust for the back-end and then use something serverless like Fly Io for each different tool. Both Python and JavaScript just donāt pair well with serverless but Supabase is definitely a good compromise.
(Just copied and pasted from my changes tab in CSS)
Also dealing with some text being cut
This was before the CSS change. Again though, Iām on a weird spec.
Removing this fixed it for me and didnāt make any immediate noticeable detrimental effects:
.self-stretch {
- align-self: stretch;
}
Wasnāt a big fan of the slowly typing out pop-up that has no immediate exit. I do appreciate me some straight up HTML + SVGs instead of images though. Opens a beautiful world of low-resource animation
Ho yeah thanks however it totally not ready and tested. The website you saw was more a POC. Its not a product at all. I found a skilled collaborator good at front end. Its gonna be changed totally. I did everything alone for the past years and now im teaming up as it is not possible for one person. If your seeking for challenge let me know, im always looking for skilled collaborator. My vision is much more then that and very futuristic. Lots lots lots of failure for the past years to get there. Hehe
I built something different. Its a UI with HUD widgets translucid. Ideal for AR glass or web. It might go that direction. Since its no keyboard mouse, UI must be adapted to be more useful.