Tool catalogue
Tool catalogue
The Furnace MCP server exposes roughly 380 tools. That's too many to hold in a context window at once, and too many to read through here. This page explains how the surface is organized so an agent — human-directed or autonomous — can find the ten tools it actually needs without loading the other 370.
The surface is organized by domain, not alphabetically
Every tool name (with one exception, below) is prefixed with the domain it
belongs to: content_get_page, tasks_list, media_upload, and so on. The
prefix tells you which product surface a tool touches before you read its
description.
| Prefix | Domain |
|---|---|
access_ | Sharing, roles, and permission grants |
analytics_ | Event tracking and reporting |
communications_ | Messaging and notification delivery |
content_ | Pages, articles, and docs |
content_layout_ | Named page layouts |
dictionaries / treatise_ | Historical-text search (no shared prefix; see note below) |
embeddings_ | Vector search and embedding management |
feature_flag_ | Feature flag reads and writes |
hero_promo_ | Homepage hero/promo slots |
kvark_ | Notes, boards, and reminders (the Kvark data model) |
ledger_ | Accounting: journal, invoices, reports |
marozzo_ | Marozzo assistant chat |
me_ | The caller's own profile and preferences |
media_ / video_ | Uploaded images, files, and video |
notes_ | Freeform notes |
notifications_ | In-app notification delivery |
ops_ | Operational reads and writes across apps |
platform_ | App lifecycle and platform-level operations |
studio_ | Workflow Studio authoring |
tasks_ | Task lists and boards |
workflows_ | Durable workflow runs |
The one naming exception: whoami
Every tool above is namespaced. whoami is not — it's a single bare tool
name, deliberately kept short because it's the first thing most clients call
to check "who am I, and is this token even working." It resolves the active
Bearer token to the user (or the string service for a platform-level key)
it belongs to.
Listing tools doesn't require authentication
tools/list (and initialize, ping, resources/list, resources/read,
and the notification methods) work without a Bearer token. You can connect
anonymously and enumerate the full catalogue — names, descriptions, input
schemas — before deciding whether you need to authenticate at all.
tools/call is the one method that requires it: every actual tool
invocation needs a Bearer token, whoami included. An unauthenticated
tools/call returns a JSON-RPC authentication error rather than a partial
result.
A strategy for agents
Don't hardcode a subset of tool names and hope it's still current. Instead:
- Call
tools/listonce per session and cache the result. - Filter by prefix for the domain you're working in (e.g. everything
starting
tasks_for a task-management flow). - Read the filtered tools' descriptions and input schemas to pick the right one — descriptions are written to be enough on their own, without needing this page or the source.
- Only call
tools/call(with a Bearer token) once you know which tool and arguments you need.
This keeps a large, evolving tool surface out of your working context until the moment you need a specific piece of it.
See also: MCP, Authentication, REST API — most MCP tools are thin wrappers over the same REST endpoints, so the REST reference is a useful cross-check when a tool's input schema is ambiguous.