The MCP surface is exactly nine control tools. They are the stable interface over a catalog that can grow independently:
| Tool | Purpose | Charges money? |
|---|---|---|
search_tools | Find a provider-neutral job and its catalog tools. | No |
inspect_tool | Read one selected catalog tool's live contract. | No |
run_tool | Execute one catalog tool and settle its charge. | Yes |
get_run | Read an existing run, its result, artifacts and cost. | No |
get_wallet | Read balance, holds and available spend. | No |
list_apps | Check which human-connected apps are available and ready. | No |
get_files | List files, renew reference URLs and check storage usage. | No |
upload_file | Import a reference or prepare a browser/CLI upload. | No |
delete_file | Permanently delete an authorised workspace file. | No |
The normal loop
search_tools → inspect_tool → list_apps (when relevant) → run_tool → get_run → get_walletUse tool_id returned by search_tools for inspection and execution, and the returned run_id for retrieval. The retired MCP and CLI names are not aliases. HTTP keeps resource paths; see transports.
What is not a control tool
Categories, capabilities, providers and catalog tools are catalog data. list_apps reports readiness, but connection approval and management remain human dashboard actions. Skills are agent-side recipes. None becomes another MCP tool.
Check list_apps when a workflow depends on a connected account, start with search_tools for catalog work, or follow the manual tool walkthrough when you need the explicit sequence.