Core tool
List the compiled skills you can replay
A tenant-scoped index of every skill that has been compiled and stored — names to pass to run_skill, and nothing else.
list_skills
What it is
The job: Answer “what do I already have?” before spending anything.
list_skills is the thin index: names and metadata for the skills your tenant has compiled. It reads from the tenant-scoped store in the web application, not from the engine, so what you see is yours and only yours.
It is free and it takes no arguments. If you need more than a name — which params a skill wants, which secrets it fills, whether you are actually able to sign into its host right now — use list_catalog instead, which is the same list with the run contract attached.
The call
Call it exactly like this.
Copied from the tool's registration and the route handler — not paraphrased.
// MCP tool call — server "twin-browser"
{
"tool": "list_skills",
"arguments": {}
}curl -X GET "https://twin-browser.com/api/v1/skills" \
-H "Authorization: Bearer $TWIN_API_KEY"Returns
{ "skills": [ { "name": "acme-login", "goal": "login", "host": "app.example.com", "version": 2, … } ] }What it costs
Free
A metadata read. No credits are reserved and none are charged.
See the full rate cardWhich one
When a different tool is the right call.
The honest answer is often the neighbouring tool. These are the trades.
list_cataloglist_catalog is strictly more useful and costs the same (nothing): same skills, plus the params, secrets and per-host auth readiness. The only reason to prefer list_skills is that you want the smallest possible response.
list_catalogsearch_libraryDifferent corpus entirely. list_skills is yours; search_library is the sanitized cross-tenant one.
search_libraryKeep going