Recipes

What a Recipe is

A Recipe is one task: typed inputs, a prompt, a model, and the MCP tools it may call. Those tools come from APIs already on Bazantic. After you publish, an agent calls the Recipe as a single MCP tool.

Dashboard QuickStart

The Dashboard links to Create a Recipe at /dashboard/recipes/new. The active account owns the Recipe. A published Recipe completes the QuickStart.

The new-Recipe route starts with a task prompt. The editor owns review, save, test, and publication.

Browser draft recovery requires the same caller, active account, and page path. If you return from gateway setup, Bazantic restores only a draft in that scope.

Test advice applies to the Recipe revision that ran the test. A complete current-revision test advises publication. A missing, stale, failed, cancelled, or timed-out test advises review or another test. A test does not gate publication.

Create a Recipe

If your account owns Recipes, the dashboard shows the list and one New Recipe link. If a writable account has no Recipes, the dashboard shows the prompt instead of the list. A Viewer sees the list without creation controls.

1. Describe the task.
2. Review the draft after its fields appear.
3. Change the prompt, tools, or inputs.
4. Save the draft.
5. Test the draft with real values.
6. Publish the Recipe.

Manage a Recipe from a JSON file

Run baz login first. List and get require recipe:read. Recipe changes require recipe:write.

baz recipe list [--json]
baz recipe get <handle> [--json]
baz recipe create <file> [--json]
baz recipe update <handle> <file> [--json]
baz recipe publish <handle> [--json]
baz recipe unpublish <handle> [--json]
baz recipe delete <handle> [--yes] [--json]

A create file contains these eight fields, and the optional block field:

name
description
input_schema
input_example
output_example
prompt_template
model
tool_bindings

An update file contains a nonempty subset of the same fields. Unknown fields cause an error before a network request.

block holds a Creator Mode block manifest:

• Set block to an object to attach or replace the manifest.
• Set block to null to remove the manifest.
• If an update file omits block, the stored manifest does not change.

The compact UTF-8 JSON for a control definition cannot exceed 24 KiB. This limit includes the block manifest. Update applies this limit after it merges the patch.

Neither file accepts identity, status, timestamp, or generation fields. Bazantic derives the immutable handle from name.

Each tool binding contains only gateway_slug and tool_name. The prompt contains exactly one {{inputs}} placeholder.

Run baz recipe --help for all field limits, model values, and a valid create file.

Create produces a draft. Update works only on a draft. Publish reads bounded metadata and validates current live tool bindings.

Unpublish returns the Recipe to draft state. Delete works only on a never-published draft. Delete also refuses a draft that has a published revision.

Interactive delete asks for confirmation. Noninteractive delete and --json delete require --yes.

Use Recipes and control tools in an MCP client

Install the bazantic-recipes server with baz recipe install --client <client>. The supported clients are claude-code, codex, and cursor.

The server combines public Recipe tools with authorized control tools. The webapp issues the CLI session, and the API validates the session.

Current control tools are:

bazantic_recipe_list
bazantic_recipe_get
bazantic_recipe_create
bazantic_recipe_update
bazantic_recipe_delete
bazantic_recipe_publish
bazantic_recipe_unpublish
bazantic_marketplace_search
bazantic_gateway_list_owned
bazantic_gateway_list_tools

The marketplace tool returns active, owner-published, Bazantic-verified services. The owned-gateway tool returns safe data for non-retired account gateways.

Both tools return at most four rows. Pass each next_offset value as offset until it is null.

Discovery rows omit descriptions, tags, URLs, timestamps, secrets, and raw specifications.

The live inventory tool reads one eligible gateway. The result includes tool names, descriptions, input schemas, annotations, and an availability state.

The account must own the gateway, or the verified marketplace must expose it. These three gateway tools require gateway:read.

Control calls use the CLI session. Published Recipe calls use the paid x402 gateway path.

Without a valid CLI session, the server lists and calls public Recipes only.

Reading the catalog costs nothing and needs no key. GET https://api.bazantic.com/v1/recipes returns every published Recipe with its handle, description, input schema, and examples. Append a handle for one Recipe.

A JSON-RPC tools/list at https://api.bazantic.com/mcp returns the same catalog as typed tools. That endpoint answers initialize and tools/list only. Its initialize result names the paid gateway URL, and each call goes there.

How Bazantic picks the tools

A Recipe only calls MCP tools that already exist on the platform. The draft is assembled from that catalog. It does not invent tools.

If part of the task is not covered, drop that part or add the missing API as a gateway. Set up opens the wizard with what we already know, then returns you to the same draft.

Review and edit the draft

The editor shows these sections in order:

Info. The name and description.

Prompt. The instruction Bazantic sends on each run.

Tools this Recipe can call. The bound tools. The Recipe calls only these tools.

Inputs. The fields that a caller must send. Each field carries an example, in the same row. This section starts closed.

Advanced. The model, the input schema as JSON, and the output example. This section starts closed.

Save follows Advanced. Test follows Save.

Test a draft

A test run calls the bound gateways with Bazantic's operator credential. No payment. We keep the run, the inputs, and the output. Keep a real output as the Recipe's example with Use as output example.

A free test can still change data in an upstream service. Use non-sensitive fixtures. Get approval before a test can create, update, or delete upstream data.

The run shows while it happens. The Test button shows the seconds since the start, and a line names the current step. Each row gets a tick when it completes and a cross when it fails:

• Load tools: the gateways that the Recipe binds, and the count of tools.
• Model · step N: one row for each model call.
• One row for each tool call under its step. The row shows the arguments that the model sent, the result, the duration, and the error for a failed call.

Stop ends the run on the server. Calls that already ran stay in the list.

Run log lists every event of the run with its time offset. It also shows the test run id, the start time in UTC, and the trace id. Copy log as NDJSON copies the raw events, so you can attach them to a support request. Each event carries its time in UTC in at.

Publish

Publish locks the definition and exposes the Recipe as one MCP tool. Unpublish to edit again.

The tool name is unique across Bazantic. If a name is taken, Bazantic adds a short suffix.

Ownership and roles

A Recipe belongs to one personal or organization account.

• Owner: create, read, edit, test, publish, unpublish, and delete.
• Operator: create, read, edit, test, publish, unpublish, and delete.
• Viewer: read.

User Recipe pages do not expose self-service Transfer. The transfer API and admin Transfer controls remain available.

Limits

A Recipe binds 1 to 64 tools. The task description you type to draft a Recipe is at most 4000 characters.

Data Bazantic keeps

Bazantic keeps the prompts, the drafts and the test inputs you enter in the editor. Bazantic uses them to improve the product.