Run your first blueprint in Diaphora cloud

The Frags runtime executes blueprints wherever it runs — on your own machine or on Diaphora's managed infrastructure. Running in Diaphora cloud adds three things your local runtime doesn't have: persistent tool connections that carry auth across every run, a stable API and MCP endpoint callers can reach without spinning anything up, and a scheduler that fires your blueprint on a cadence.

This guide takes the shortest path to a real, cloud-hosted run: connect your tools, write a blueprint that uses them, deploy it, and call it.

Before you start

You'll need a Diaphora workspace. If you don't have one yet, sign up at diaphora.ai — a workspace is created for you on sign-up.

Everything in this guide is done from the Diaphora dashboard. If you want to prototype blueprints on your own machine first, see Running Frags Locally.

Step 1: Connect your tools

A blueprint that calls real tools — Slack, Salesforce, Notion, a database — needs those tools connected before it runs. In Diaphora cloud, tool connections are workspace-level: you connect a tool once and every blueprint that declares require mcp <name> can use it.

Open Settings → Tools in your workspace. For each MCP server you want to use:

Click + Add tool.
Paste the server's URL.
If the server requires OAuth, supply the client_id and client_secret and click Authorize — Diaphora walks you through the OAuth flow and stores the resulting tokens.
Wait for the status to show ready. A tool that shows an error won't be callable from a blueprint.

Built-in tools — web search (use search) and HTTP (use http) are available in every workspace without any configuration.

For how tool connections work under the hood, see Setting up tools.

Step 2: Write your blueprint

A blueprint is an FML file that declares the tools it needs, the inputs it accepts, and the sessions that do the work — each with a typed output schema. Here's a complete example: it fetches CRM and Slack signals ahead of a meeting, then builds a structured prep doc.

FML

require mcp salesforce
require mcp slack

parameter("meetingQuery", type=string, title="Meeting or contact to prep for")

session("fetch-signals") {
    use mcp salesforce
    use mcp slack

    + Pull the most recent Salesforce account activity and Slack messages
      related to {{ .params.meetingQuery }}.
    - Extract what's most relevant to the upcoming call.

    schema {
        account_name: string
        recent_activity: string[]   # Key Salesforce events from the last 30 days
        slack_signals: string[]     # Relevant messages or threads
    }
}

session("build-prep", after="fetch-signals") {
    context true
    - Build a structured call prep document from the signals.

    schema {
        overview: string
        talking_points: string[]
        open_items: string[]
        suggested_agenda: string[]
    }
}

Four things are doing all the work:

require mcp salesforce / require mcp slack — declares the tools this blueprint uses. These must be connected (Step 1) before the blueprint can run.
parameter(...) — a typed, validated input the caller supplies at run time. Reference it anywhere with {{ .params.meetingQuery }}.
session("fetch-signals") { ... } — the first isolated LLM step. The + prePrompt gathers live data (tools are available here); the - prompt turns what was gathered into typed output.
session("build-prep", after="fetch-signals") { ... } — waits for fetch-signals to finish, pulls its output into context with context true, and builds the prep doc.

For the full session anatomy, see Anatomy of a session. For how data moves between sessions, see Data flow: params, vars & context.

Step 3: Deploy the blueprint

In the Diaphora dashboard, open Blueprints → + New blueprint. Paste your FML and click Deploy.

Diaphora validates the FML, checks that every require mcp <name> is connected, and — if both pass — makes the blueprint available at a stable endpoint. The blueprint overview shows:

Tools — each require mcp with its current connection status. A tool showing an error needs to be fixed in Settings → Tools before the blueprint can run.
Parameters — the inputs the blueprint accepts, with their types and defaults.
Run — a form to fire the blueprint manually with any parameter values.

If the FML has a syntax error or references a disconnected tool, the dashboard surfaces the error and the deploy does not go through. Fix the issue and redeploy — there's no partial deploy state to clean up.

Step 4: Run it

There are three ways to call a deployed blueprint.

From the dashboard. Open the blueprint and click Run. Fill in the parameters and click Run blueprint. The execution panel streams each session's output as it finishes; when the run completes, you get the full typed JSON result keyed by session name.

Over the API. Every deployed blueprint has a stable endpoint:

Shell

curl -X POST https://api.diaphora.ai/v1/blueprints/<id>/run \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"meetingQuery": "Acme Corp renewal call"}'

See the API reference for streaming runs and long-running execution patterns.

From an MCP client. Your deployed blueprints are also available as MCP tools. Connect your MCP client to https://mcp.diaphora.ai with your workspace token and every blueprint appears as a callable tool. See the MCP reference.

Step 5: Schedule it (optional)

A blueprint that runs on demand is useful. A blueprint that runs itself is a product. Open Schedules in the left rail of the blueprint overview, click + New schedule, and set:

Cadence — Hourly, Daily, Weekly, or Monthly.
Timezone — the platform handles daylight-saving shifts.
Parameters — the values each scheduled run uses, frozen at schedule creation. Edit the schedule to change them without redeploying the blueprint.

The platform shows a plain-English preview as you configure — Every Monday at 9:00 AM (America/New_York) — so there's no cron syntax to verify. For a full walkthrough including a real weekly email brief, see Schedule recurring blueprints.

What you have now

A single FML file, deployed to Diaphora cloud, gives you:

A stable API endpoint callable from any HTTP client or your app's backend.
An MCP tool any MCP-aware agent or IDE can call.
Persistent tool connections — auth managed by the platform, not baked into the blueprint.
An optional schedule that runs the blueprint hands-off on any cadence.

The blueprint itself stays portable: the same FML runs locally with the Frags CLI or on Diaphora cloud — only the tool connection layer changes.

Next steps

Browse ready-made blueprints in the blueprint marketplace — pick one, connect its tools, and deploy.
Go deeper on sessions in Anatomy of a session.
Connect more data sources in Connect Frags to your data.
Fan out sessions and add conditional logic in Control the flow of a blueprint.
Call a deployed blueprint from your application with the Python or TypeScript SDK.

← All guides

Connect your tools, write a blueprint, deploy it, and call it — the shortest path to a real, cloud-hosted run with a stable API endpoint, MCP tool, and optional schedule.