Quickstart

This guide takes one website live with Inception Agents. When you finish, AI agents that visit https://your-domain.com/mcp get the tools you approved, their requests reach the people you chose, and someone on your team has confirmed a test lead.

Going live is a checklist proven from the outside. Each step counts as done only when a check proves it, never because a setting was saved, and a site that later breaks falls back out of “done”.

Selling software through your own MCP server? The in-product side, where the upgrade moment reaches your customers inside Claude and ChatGPT, has its own guide: the Expansion Pack Quickstart.

Before You Start

• An Inception Agents account. Sign up with a work email.
• Your website’s host, exactly as visitors use it. www.example.com and example.com are different hosts.
• Access to your site, and nothing more:
  • WordPress: WP-CLI over SSH on the WordPress server, or the site owner does two steps in the WordPress admin. No administrator password is needed.
  • Cloudflare: an account-owned API token with Workers Admin, plus Workers Routes Write and Zone Read for this zone only, and the account ID. Never the account’s global API key.
• The Inception Agents connector. Going live runs as a conversation: add the connector to your own Claude (https://mcp.inceptionagents.com/mcp, sign in with your account), or connect your coding agent to the same server. Then run the /inception-go-live prompt. It follows the same step-by-step playbook we use, and your developer or agency can run it for you.

The Eight Stages

The go-live state lists eight stages in order. Your own Claude (or your coding agent) reads the state first and again after every step, and tells you who moves each one next.

A stage that is not waiting on an earlier one can be worked in any order. Approving tools and the test notification wait for the install proof, which is why the steps below start with the install.

1. Install on Your Site

If your host is not on your account yet, add it first (add_domain, a hostname only). Then get_install_plan looks at your homepage from the outside and recommends a path, with the access it needs, the download and the SHA-256 to check it against, and the steps in order. There are two paths.

WordPress Plugin

The plugin is not in the WordPress plugin directory yet, so it comes from our zip, and the install plan gives you the download link and its checksum. Check the checksum before installing.

# With WP-CLI on the WordPress server (the plan gives the exact URL and hash)
wp plugin install inception-agents.zip --activate --force
wp plugin get inception-agents --field=version    # 3.1.0 or newer

Without WP-CLI, the site owner uploads the same zip in Plugins → Add New → Upload Plugin and activates it.

Then connect it with a one-time install code. Ask for the code (create_install_code, for your host and the WordPress plugin) right before you connect: it works once, for 60 minutes. The code goes in on standard input, never as an argument, so it stays out of your shell history:

wp inception connect <<'EOF'
<install code>
EOF
wp inception status

Without WP-CLI, the site owner pastes the code in Settings → Inception Agents, ticks the box and clicks Connect. Nothing is sent to Inception Agents until an administrator connects the plugin, and the settings page lists what each part sends before you do.

Cloudflare Worker

For a site whose DNS is on Cloudflare, a small Worker relays your agent paths (/mcp, /.well-known/mcp.json, /agent/*, /llms.txt and the agent files) and sends every other request to your site untouched. Deploy it first with one route, the install proof at /.well-known/inception-verify, then connect it with a one-time install code: the answer’s key and secret go straight into the Worker’s secrets, and nothing prints them. After the proof passes, add the routes for the agent paths and your pages.

If Cloudflare’s bot protection is on, add a skip rule for exactly the relayed paths before the proof, so agents (and the proof) get through. Leave Cloudflare’s own switch (AI → Agent Readiness → WebMCP) off: the Worker is the install.

See Cloudflare for the Worker’s settings and the skip rule.

Prove the Install

verify_install fetches https://your-domain.com/.well-known/inception-verify with a fresh challenge, and the plugin or Worker answers it. A pass proves the website is yours and turns on /mcp for it. There is no DNS record to add and no file to upload: the install is the proof.

2. Approve What Agents Will See

Once the install proof passes, preview_agent_tools returns the exact tools an agent that is not signed in will see on your site. Each one is marked as a lookup or an action (an action contacts your business or takes a request). Read them, and approve the list only if it is right. approve_agent_tools approves the lookups that read the answers you publish as a group, so publishing, editing or archiving an answer later needs no new approval. Every other tool, including each one that acts, is approved exactly as shown. Once you are live we check your site every hour, and email the people who receive your leads if one of those tools is added, changed or removed without a new approval.

Visiting agents see your public tools only. Your analytics, audiences and campaign controls answer only to you.

3. Choose Who Receives Leads

Name the people at your business who should receive leads (set_lead_recipients). You can do that at any time. Once the install proof passes, send a test notification (send_test_notification) and ask them to confirm it arrived, checking spam too. If the list changes later, send the test again: this stage is bound to the exact list that was tested.

4. Check Reachability From the Outside

check_reachability looks at your site the way an AI agent does: the page script (present once, for your account), /.well-known/mcp.json, /mcp and the tools it lists with a standard MCP client, and your briefing. Each failing check says what is wrong and how to fix it. A configuration change can take a few minutes to reach every edge location, so a pending configuration means wait, not fix.

5. Send a Test Lead

When the earlier stages pass, run_live_test acts as a buyer’s agent on your live site: it asks a few questions, then requests a callback. Your lead list gets an email marked TEST, with what the agent asked first and a link to replay the conversation. It is never billed.

Someone on the lead list opens the TEST email and clicks I received this test lead. A reply does not count. When they have, the site can go live.

What Happens Next

When a real buyer’s agent comes, the request reaches you one of two ways:

• The person confirms on your branded card when they are on your page.
• Their own agent completes the request for them, with their name, a way to reach them and their go-ahead, and gets a reference back to tell them.

Nothing reaches you without their go-ahead, and every lead says how it was given. An agent can complete a request, but it can never opt anyone into your marketing: only the person’s own tick does that. One contact can complete five requests a day with you, and agents that call too fast are told to wait.

Each lead arrives in your Leads inbox and by email, with the person’s own words, the facts, how they said yes, and What their agent asked first, plus a link to Replay the conversation in your dashboard. Once you’re live, we check your site every hour and email your team if agents stop being able to reach it.

Next Steps

• Core Concepts — detection, optimization and measurement, and how they fit together
• How Agents Evaluate — what each AI platform prioritizes when evaluating your content
• llms.txt — customize your machine-readable site description
• Agent Traffic — read your agent visits and what was served to them