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.

MCPlist_skills.mcp.jsonjson
// MCP tool call — server "twin-browser"
{
  "tool": "list_skills",
  "arguments": {}
}
GET /api/v1/skillsrequest.shbash
curl -X GET "https://twin-browser.com/api/v1/skills" \
  -H "Authorization: Bearer $TWIN_API_KEY"

Returns

response.jsonjson
{ "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 card

Which one

When a different tool is the right call.

The honest answer is often the neighbouring tool. These are the trades.

list_catalog

list_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_catalog
search_library

Different corpus entirely. list_skills is yours; search_library is the sanitized cross-tenant one.

search_library