Problem
Currently opencli loads all built-in adapters unconditionally. There is no way to suppress them, which causes two practical issues:
1. Built-in adapters pollute the agent tool list
When using opencli as an AI agent tool (e.g. via the smart-search skill in Claude Code), all 140+ built-in adapters are exposed to the model at once. This bloats the tool listing, increases token usage, and makes it harder for the agent to pick the right tool. There is no mechanism to disable or hide specific sites.
Request: Add a config option to disable built-in adapters, e.g. in ~/.opencli/config.json:
{
"disableBuiltins": true,
"disabledSites": ["1688", "amazon", "bloomberg"]
}
Or an env var: OPENCLI_DISABLE_BUILTINS=1
2. No project-level CLI isolation
The current discovery order is fixed:
BUILTIN_CLIS (npm package)
~/.opencli/clis/ (user-level)
~/.opencli/plugins/ (user-level)
There is no project-local discovery. When working in a monorepo or a project that defines its own domain-specific tools, there is no way to:
- Scope a set of CLIs to a specific project directory
- Have different projects expose different tool sets to the agent
- Check project-local tools into version control alongside the code
Request: Add a project-level discovery step, loading from the current working directory:
./.opencli/clis/ ← project-local adapters
./.opencli/plugins/ ← project-local plugins
Combined with disableBuiltins, this would allow a project to define exactly the tools it needs and expose only those to the agent — clean, isolated, version-controlled.
Use case
A project that communicates with internal APIs wants to expose 3 custom tools to an AI agent, without the agent seeing 140+ unrelated built-in adapters. Today this is impossible without patching the npm package directly.
Version
@jackwener/opencli v1.7.14
Problem
Currently opencli loads all built-in adapters unconditionally. There is no way to suppress them, which causes two practical issues:
1. Built-in adapters pollute the agent tool list
When using opencli as an AI agent tool (e.g. via the
smart-searchskill in Claude Code), all 140+ built-in adapters are exposed to the model at once. This bloats the tool listing, increases token usage, and makes it harder for the agent to pick the right tool. There is no mechanism to disable or hide specific sites.Request: Add a config option to disable built-in adapters, e.g. in
~/.opencli/config.json:{ "disableBuiltins": true, "disabledSites": ["1688", "amazon", "bloomberg"] }Or an env var:
OPENCLI_DISABLE_BUILTINS=12. No project-level CLI isolation
The current discovery order is fixed:
BUILTIN_CLIS(npm package)~/.opencli/clis/(user-level)~/.opencli/plugins/(user-level)There is no project-local discovery. When working in a monorepo or a project that defines its own domain-specific tools, there is no way to:
Request: Add a project-level discovery step, loading from the current working directory:
Combined with
disableBuiltins, this would allow a project to define exactly the tools it needs and expose only those to the agent — clean, isolated, version-controlled.Use case
A project that communicates with internal APIs wants to expose 3 custom tools to an AI agent, without the agent seeing 140+ unrelated built-in adapters. Today this is impossible without patching the npm package directly.
Version
@jackwener/opencliv1.7.14