A plain-English walkthrough of every machine-readable surface this directory publishes — why it's there, who it helps, and a link to the live endpoint so you can inspect it yourself.
Ask your AI assistant — ChatGPT, Claude, Perplexity, a dedicated wedding planner bot — for celebrant recommendations in Australia. It can read every profile on this site, search by location or specialty, and even email a shortlisted celebrant on your behalf through our relay. You stay in control: the celebrant replies to your email, you take the conversation from there, and we're not involved in the booking.
Being in this directory means your public profile is genuinely visible to the new generation of AI tools couples use to plan. We've built — and maintain — the discovery plumbing (61 celebrants indexed today). When an assistant recommends you, the enquiry that lands in your inbox has a date, a location, and a real couple behind it. You opt in by default; opt out any time from your listing edit page.
What this site asks bots to do — and not do.
Alongside the standard Allow directives, we publish a Content-Signal line from the
contentsignals.org draft:
ai-train=no, search=yes, ai-input=yes. In plain English: don't harvest celebrant bios for model training, but please do index us for search and cite us in AI-assisted answers. That lets couples find celebrants through the AI tools they already use, without turning the directory into free training data.
Every HTTP response on this site carries Link headers pointing at the machine-readable versions of the content — the service-desc, describedby, sitemap, api-catalog, agent-skills, and a2a-agent-card relations. An agent that lands on any page can follow these without scraping to find the structured data.
Verify with curl -sI https://australianweddingcelebrants.com.au/ | grep -i '^link:'
Auto-generated list of every URL on the site, refreshed every build. Useful for Google/Bing and any crawler-style agent doing bulk ingestion.
The site content, but in formats an LLM can actually digest.
Following the llmstxt.org convention: a concise text summary of the site (who we are, tier system, all celebrants with tier, location, and URL) plus a full-dump variant that inlines every celebrant's body copy. An LLM that wants broad context in one fetch can read these instead of crawling the HTML.
Every HTML page has a markdown counterpart. Request any URL on this site with Accept: text/markdown and you'll get the markdown version with Content-Type: text/markdown and an X-Markdown-Tokens estimate — a Cloudflare Pages Function at the edge swaps the response. Browsers still get HTML; agents get the cleaner token-efficient version.
Try: curl -H 'Accept: text/markdown' https://australianweddingcelebrants.com.au/
Every celebrant as typed JSON — slug, tier, locations, categories, australia_wide / international flags, contact fields, profile URLs. Updated on every build. This is the backbone that the MCP server and A2A agent both read from.
Well-known URLs where agents look first to figure out what we offer.
An application/linkset+json document that advertises every machine-readable surface we run — the directory dataset, the MCP endpoint, the A2A endpoint — each with its spec URL and docs. Lets an agent find everything in one GET.
The static discovery card for our MCP server. Advertises the transport (http), endpoint URL, and identity. This is how an MCP-capable assistant finds our server without being hard-coded to it.
A published skill (find-australian-wedding-celebrant) that teaches any agent how to use this directory well — when to trigger, how to explain tiers, a recommended 5-step flow, and the common pitfalls to avoid. The index is auto-regenerated on every build with a SHA-256 digest so clients can verify they've got the right version.
The standard A2A protocol card. Names this site as an agent that other agents can delegate to, lists our two skills (search_celebrants and enquire_celebrant), and publishes the endpoint.
The services behind the discovery cards.
A Model Context Protocol server (Streamable HTTP transport, protocol version 2025-06-18) running on our Cloudflare Worker. Exposes five read-only tools: search_celebrants, browse_by_location (includes celebrants who travel Australia-wide), browse_by_tier, get_celebrant_profile, and list_all_celebrants. Any MCP-capable client — Claude Desktop, Cursor, Zed, a custom agent — can connect and use it.
curl -X POST https://api.australianweddingcelebrants.com.au/mcp \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"search_celebrants",
"arguments":{"query":"byron bay"}}}'
An Agent-to-Agent endpoint for assistants that want to delegate a task rather than call tools. The headline skill is enquire_celebrant: a couple's planning assistant sends a qualified payload (couple name + email, wedding date, location, at least 30 characters of ceremony notes), we validate and rate-limit, and we email the celebrant with the couple as Reply-To. The celebrant and the couple take it from there — we don't sit in the middle of the conversation.
What we commit to: no commission, no contract, no interference in the booking. We're a free pass-through for celebrants in the directory. Couples see our disclaimer on every A2A response; celebrants see it in plain English in every enquiry email. Celebrants can opt out of agent-relayed enquiries at any time.
Abuse controls: 10 enquiries per IP per day, 1 per IP per celebrant per day, 30 per celebrant per day across all agents. One "Report spam" click in any enquiry email bans the sender IP for 30 days; three reports against the same agent name permanently block that agent.
For AI assistants running inside a user's browser (the emerging WebMCP standard, currently in Chrome's early preview). When you load any page on this site, we register five tools with navigator.modelContext.registerTool — search, browse by location, browse by tier, view a profile, submit a listing. An in-browser assistant can invoke them directly. Zero-op in browsers that don't support the API.
No. Our robots.txt carries a Content-Signal directive of ai-train=no, which asks compliant crawlers not to use celebrant bios as training data. We allow search indexing (search=yes) and AI-assisted answers (ai-input=yes) because those help couples find a celebrant — which is what every celebrant on this site wants.
We publish machine-readable versions of every page (llms.txt, directory.json, .md endpoints) plus a proper MCP server at api.australianweddingcelebrants.com.au/mcp that an AI agent can call to search, browse by location or tier, and fetch full profiles. We also expose the same capabilities through A2A so one agent can delegate to another.
Yes, through the A2A enquire_celebrant skill. The couple's assistant sends us a qualified payload (couple name + email, wedding date, location, detailed notes), we validate and rate-limit it, then email the celebrant with the couple as Reply-To. The celebrant replies directly — the directory is not in the loop. No commission, no contract, pass-through only.
Yes. Every celebrant can uncheck 'Let AI agents relay wedding enquiries to my email address' on their listing edit page. We'll immediately stop relaying enquiries to them. No questions asked.
Just as important as the list above.
ai-train=no signal is explicit about this).This whole agent-discovery stack — the MCP server, A2A relay, Content Signals, skills index, the lot — was built by Josh Withers, who also runs every celebrant listing in this directory. If you're a business and you want your own website to be this legibly useful to search engines, answer engines, and AI agents, this is the kind of work Josh does every day through his two agencies:
Celebrants in this directory get this infrastructure for free. You're not charged for the MCP surface, the A2A relay, or anything else on this page. If you want something like it for your own business, the two links above are the way.
Questions, suggestions, or want to see another agent surface added?