πŸ“Ό loadout.md SPEC v0.1

The file that makes an MCP smart.

MCP gives an agent tools. A loadout gives those tools judgment β€” what to ask before acting, how to sequence the work, what to avoid, when to stop for human approval, and what β€œdone” actually means. One markdown file. Any MCP client.

A Loadout doesn’t just act. It asks first.

Tools are not enough

Connect an agent to a powerful MCP and it can do a thousand things β€” including a hundred you'd never want. The missing layer isn't capability. It's judgment.

MCP alone

40 tools, zero context. The agent guesses your audience, invents your offer, sends before you've seen anything, and calls it done because it stopped.

MCP + loadout.md

Interviews you first. Works the sequence. Refuses what the file forbids. Slams to a stop at the approval gate. Proves it's done with a verifiable check.

Three non-negotiables

Everything else in the format bends. These don't.

1

Ask first

The file opens with a config interview β€” and the agent only asks what it can't discover from the file, the conversation, its memory, or the account itself. In a chat, these are questions; in a dashboard, the same lines render as a form. One artifact, two front-ends.

2

One approval gate, minimum

Before anything irreversible β€” a send, a post, an automation β€” the workflow stops and a human approves. A loadout without a gate is a script, not a loadout.

3

Done is verifiable

β€œDone means” must be checkable β€” name the read tool that proves the work happened. No vibes-based completion.

The format

Seven parts, in order. Full section reference in the spec README.

# <Name> β€” Loadout

```yaml
loadout: <slug>          # required β€” stable id
mcp: <server url>       # required β€” the MCP this file drives
tier: <access tier>    # optional
cadence: weekly        # optional β€” rhythm if run as a recurring loop
```

**The job:** one paragraph. The outcome, in the operator's language.

## Before you run β€” ask the user
Only ask what you don't already know. Check the Config, the conversation,
memory, and the account first. Confirm inferences in one line.
1. **Who is this for?** (hint)
2. **What's the asset?** (name + URL)

## Config
```yaml
audience:              # keys become stable form-field ids
asset:
```

## Steps
### 1. See β€” call `a_real_tool`, study the signal
### 2. Decide β€” rank, filter, dedupe against history
### 3. STOP β€” approval gate β›”
Present everything. Nothing irreversible happens past here without a human.
### 4. Act β€” only what was approved Β· ### 5. Close the loop for next run

## Never
- The hard boundaries. No fabrication. No acting without approval.

## Done means
- Verifiable β€” name the read tool that proves it (`list_actions`, …)

A real one

Not a hypothetical β€” this file runs against a production MCP. It interviews for config, studies live market signal, learns the account's voice from its own post history, drafts with the capture automation attached, and stops at the gate for approval.

examples/content.loadout.md

    
βœ“  Extracted from production runs β€” this spec documents what worked, not what sounded good.

Running one

Connect the MCP named in the file's header, then paste the whole file into your agent with this:

Load this Loadout and run it. Follow the file exactly: - ask me the config questions BEFORE doing anything else - do not perform any irreversible action without my explicit approval - when done, verify the result the way the file says to.

Works in Claude, ChatGPT, Cursor, or any MCP client. Dashboard runtimes render the same file as a form + checklist + approval queue β€” Apex by LeadShark is the reference runtime the format was proven against.

Validator

Paste a loadout.md β€” checked against the v0.1 spec, entirely in your browser. Nothing leaves this page.