builtin-tool

Create and wire LobeHub builtin tool packages with manifests, runtimes, and executors.

1|Updated May 20, 2026

Search Tags:#runtime #registration #executor #builtin-tool #agent-tooling #tool-packaging

Ready to run

npx skills add https://github.com/mDevsLabs/mAI --skill builtin-tool-mdevslabs

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: builtin-tool
Source: https://github.com/mDevsLabs/mAI/tree/main/.agents/skills/builtin-tool
Command: npx skills add https://github.com/mDevsLabs/mAI --skill builtin-tool-mdevslabs

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Build and wire LobeHub builtin tool packages to enable agent-callable tooling, including manifests, runtimes, executors, and client UI surfaces.

Core Features & Use Cases

Define and publish a complete tool package with manifest, types, system prompt, and runtime bindings.
Wire the five faces (Manifest + Types, ExecutionRuntime, Executor, Client UI, and registry wiring) into server and client environments.
Reuse and evolve a consistent blueprint for adding new builtin tools with shared registration patterns.

Quick Start

Create a new builtin-tool package following the directory layout and export contracts to expose APIs for tool discovery and execution.

Frequently Asked Questions about builtin-tool

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I build and wire LobeHub builtin tools for agents?▼

To build LobeHub builtin tools, you create a package with manifests, types, and runtime bindings, then wire the five faces into server and client registries for agent execution.

What is the five-face architecture for agent tool packaging?▼

The five-face architecture for agent tool packaging consists of Manifest, Types, ExecutionRuntime, Executor, Client UI, and registry wiring to ensure strict typing and pure runtime integration.

How does tool registration work in the LobeHub execution runtime?▼

Tool registration in the execution runtime works by exporting defined contracts from your builtin tool package, allowing server and frontend registries to discover and call the executor.

Do I need to write separate executors for server and client UI registries?▼

You must wire the executor into both environments, but the builtin tool architecture uses shared registration patterns to reuse the core execution runtime across both surfaces.

What is the best way to add a new builtin tool to an existing agent tooling setup?▼

The best way to add a new builtin tool is to follow the directory layout and export contracts, reusing the blueprint to wire manifests, executors, and client UI into the registries.