Exposing recipes to chat

An exposed recipe appears in the tool catalog that the built-in chat and every connected agent read — name, description, and variables are all the model sees when deciding what to call. Exposure is a distribution decision on the same recipe: it still runs from the panel, a schedule, or a trigger exactly as before.

#Decide what to expose

Set chat_exposed: true deliberately. Your own locally-authored recipes are offered to chat by default; recipes installed from packs stay hidden unless the author opted them in — every exposed entry makes the catalog the model must read a little longer, so exposure is per-recipe, not blanket.

Expose a recipe when all three hold:

1. The job is something you'd ask for in words — "what's overdue?", "draft the intro", "watch for the quote from Peter".
2. It runs from its arguments alone — no page context, nothing the model can't supply.
3. It is the entry point of its workflow.

Keep hidden: silent producers, the reactive halves of watcher pairs, cleanup utilities, and acting recipes that only make sense launched from a proposal or review — a model should never be offered a lever whose preconditions it cannot see. A multi-recipe workflow typically exposes its entry and its review recipe, nothing else.

#Arguments: flat and self-describing

Chat fills variables like command-line flags. Keep them flat scalars, booleans, and arrays — never an object that hides the real shape:

"variables": {
  "expected_sender_email": { "label": "Sender email", "type": "string",
                             "required": true, "default": "" },
  "subject_contains_any": { "label": "Subject terms", "type": "array",
                            "default": [] },
  "acct": { "label": "Accounting connection", "type": "connection",
            "connection_kind": "api", "default": "" }
}

Label everything (add help when a value has a format), mark only true requirements required, and give the rest working defaults. An invocation on pure defaults should work or fail closed with a clear message — never half-run. And don't demand raw vendor record ids as arguments when the recipe can resolve them from a human handle like an email or a date range; the model rarely holds ids.

#Write the description for selection

The model chooses between many tools on name and description alone.

• Name the recipe imperatively and specifically: audit-subscriptions-from-mail, not subscription-helper.
• State what it reads and what it never does. "Read-only; never sends or deletes" lets the model pick the safe tool confidently.
• Distinguish run now from runs on a cadence. A recipe that arms a watch for a future one-shot event must say it waits and is not a recurring schedule — that is what steers the model between running it and scheduling it.
• Name the inputs it expects, so the model asks you for missing values instead of guessing.

#What chat gets back

The tool result is the recipe's output.render, the same sections the panel shows. Lead with a summary; label copyable blocks (a drafted reply, a generated snippet — the things you'll paste elsewhere); and offer the next step as a button action pointing at the acting recipe, rather than prose instructions the model would have to interpret.

If a run reaches a held approval, the result shows the awaiting-approval state; the closure comes later, from your decision — not from the model retrying.

#Writes still ask

A chat-invoked run passes the same boundary as everything else. Reads run under their grants; a write surfaces an approval with editable arguments, and a burst of identical writes asks once for the batch. You can relax per-action approval for a session — exactly, for a batch, or for an operation class — and only you can turn a repeated approval into a standing rule. See Grants and approvals.

Author for the ask: the step that holds should carry enough labeled context — recipient, subject, amount — that the approval reads as a decision. And never split one logical action into many small operations to slip under approval granularity; the audit trail makes that visible anyway.

#Cadences from chat

Chat can also arm a schedule for an installed recipe, and each schedule carries its own configuration. Make your variables cover the axis people will vary per schedule, and keep the description honest about what an unattended fire does — the rules in Triggers and watchers apply unchanged.

#Where exposure reaches

Everything here applies beyond the built-in chat: the MCP door offers the same exposed recipes as tools to Claude Desktop, Cursor, and any connected agent, under that door's grants. See AI chat and MCP and Connect to Recued.

#Checklist

• Exposure deliberate: entries and review recipes on; producers, reactive halves, and proposal-bound actors off.
• Arguments flat, labeled, defaulted; human handles over raw ids.
• Description: imperative, states reads/writes/never-does, run-vs-schedule explicit, inputs named.
• Defaults-only invocation works or fails closed.
• Results lead with a summary; next steps are buttons.
• Try the selection: ask chat to do the job among plausible decoys and check it picks — and parameterizes — your recipe.