Use-case recipes
Goal-oriented playbooks the MCP server hands to agents through list_use_cases and get_use_case, and the same files over REST as SKILL.md.
The MCP reference lists every tool one by one. A recipe answers the other question an agent has: "I want to accomplish X; which calls, in what order, and what must a person have done first?" Each recipe is a short markdown playbook with front matter in the Agent Skills SKILL.md layout, so a client can also install it as a skill.
The two tools
list_use_cases takes no parameters and returns the index: one entry per recipe with slug, title, a one-line summary, triggers (phrases a request may match) and unavailable (tools the recipe needs that this server does not expose, for example the app tools on a server where apps are not enabled). The index is a few KB and nothing is written, so an agent can call it whenever a request spans several tools.
get_use_case takes slug and an optional max_chars. It returns {slug, title, version, sha256, tools, unavailable, content, download_url, truncated}. content is the recipe as markdown with front matter; max_chars trims it at a line boundary; sha256 tells a client whether a recipe changed since it last read it.
The server's connect-time instructions point at both tools, and usage_guide now accepts a section argument for one ## section of the long guide instead of all of it.
REST
Both endpoints accept a bearer token or a browser session, like the rest of /api.
| Endpoint | Returns |
|---|---|
GET /api/use-cases |
The index as JSON, with version, sha256 and download_url per recipe. |
GET /api/use-cases/{slug}/skill |
The recipe as text/markdown, downloaded as SKILL.md, with an ETag of its hash. |
Drop a downloaded file into .claude/skills/<slug>/SKILL.md (or your client's equivalent) to keep a recipe loaded without calling the server.
Recipe layout
---
name: set-up-an-agent
title: Set up an agent for one concern
description: One line; this is the summary in the index.
version: 1.0.0
triggers:
- "set up an agent for support"
tools:
- list_agents
- create_agent
---
# Title
## When to use
## Prerequisites
## Steps
## Verify
## Pitfalls
## Not possible yet
## Related
name must equal the file name. The front matter is deliberately strict: key: value scalars, key: followed by - item lines, optional quotes, and nothing else (no comments, no nesting). Prerequisites lists what a person must have done first, who can do it and on which plan; Steps are numbered with the exact tool calls and the arguments that matter; Verify says how the agent confirms it worked; Not possible yet is authoritative, so the agent tells the user instead of working around it.
The catalogue
| Slug | What it covers |
|---|---|
publish-and-update-a-document |
One link that keeps working while the content changes; folders, shared spaces, folder landing pages. |
store-images-and-large-files |
Images, PDFs and exports in a folder; assets attached to a document; uploads up to 2 GiB. |
set-up-an-agent |
Create an agent, propose its instructions, skills and workflows, write memory, add sources. |
run-a-recurring-job-with-an-agent |
A weekly or daily job driven by the agent's workflow, with standing report links, images, a journal digest and an audit trail. |
connect-an-agent-to-mcp-tools |
Attach a remote MCP server, supply credentials safely, discover tools, call them under policy. |
enable-hosted-chat-and-runs |
Turn on the hosted model, start a session, run bounded research or actions, continue after approval. |
build-and-schedule-an-app |
Create, prepare, publish and schedule a small Python or JavaScript app with secrets. |
author-an-agent-workflow |
Typed, versioned workflows: validate, save, test, release, run, score. |
deploy-an-agent-to-slack |
A paused Slack deployment, its manifest, and the steps a person finishes in the browser. |
share-a-folder-or-root |
Spaces, folder and document grants, groups, and agent publishing. |
audit-what-an-agent-did |
The journal, hosted and app runs, tool-call decisions and the audit log. |
What keeps recipes honest
Every name in a recipe's tools list, and every backticked tool call in its body, is checked in CI against the tools the server advertises, so a renamed tool breaks the build instead of misleading an agent. The unavailable field is computed from the live server at call time. Each recipe's ## Not possible yet section states the current limits plainly: for example, nothing in Fermium schedules an agent run today, and an app run cannot reach the network or write documents.