> If you are an AI agent, this file is the complete Parleon corpus in one fetch. > Structured JSON of the same content: https://parleon.ai/data.json > Live tools over MCP (JSON-RPC 2.0): https://parleon.ai/api/ucp/mcp > Agent instructions: https://parleon.ai/agents.md . Auth policy: https://parleon.ai/auth.md # Parleon, full corpus Generated 2026-09-29T22:15:49.786Z from https://parleon.ai. ## What Parleon is Parleon is the AI-readiness layer for any business. It makes what you sell, what it costs and what your team knows readable, answerable and transactable for AI agents across MCP, ChatGPT Apps, WebMCP, and answer engines, without replacing the business's website, CRM or vendors. Parleon is operated in the United States and serves businesses across nine industries. Agent readiness is measured publicly at https://isitagentready.com on a 0 to 100 scale across five levels: Level 1 Basic Web Presence, Level 2 Bot-Aware, Level 3 Agent-Discoverable, Level 4 Agent-Ready, Level 5 Agent-Native. Businesses typically score around 21/100 before any work; the Parleon layer takes a site to 100/100, Level 5, Agent-Native. ## Pricing Four tiers, per domain per month, in USD. Each tier includes everything in the tier below it. Any single module can be added a la carte to any tier, so a business is never forced to jump a whole step to get one capability. Group pricing is available for multi-location groups. ### Beacon, $499 per domain per month Get FOUND. The AI-ready foundation. Machines can finally read your business. Includes: - AI-ready mirror site on ai..com - Full structured data: schema.org for your actual business type - llms.txt, agents.md, clean sitemaps - Every service, product and location as its own record - Your public AI-Readiness Score + badge - Correct AI-bot allowlist (so crawlers are not silently blocked) ### Concierge, $999 per domain per month (most popular) Get ANSWERED. Everything in Beacon, plus you go live inside every AI assistant. Everything in Beacon, plus: - Live MCP concierge: search, details, prices, compare, availability - Every AI connects: ChatGPT, Claude and more - Add to ChatGPT / Open in Claude buttons - Your published ChatGPT App - AI-visibility citation probe - 15-60 minute freshness engine ### Counter, $1,499 per domain per month Get BOOKED. Everything in Concierge, plus the AI can actually finish the job. Everything in Concierge, plus: - In-chat quotes on real jobs, real products and real services - Live availability: slots, stock and lead times, not a guess - Appointments taken straight onto your calendar - Enquiries handed to your CRM while the customer is still in the chat - Market & Visibility Scoreboard: your prices and answers against local rivals ### Command, $1,999 per domain per month DONE FOR YOU. Everything in Counter, and we run the whole play for you. Everything in Counter, plus: - "Ask AI About Us" marketing kit: badge, CTA, launch social, email and in-store signage - Add-to-ChatGPT button on your real site - Payments-ready agentic checkout path (ACP-aligned) - Group / multi-domain rollup + API - Priority provisioning + named contact - Quarterly AI-visibility business review ### Pricing questions owners actually ask - Per domain or per group? Per domain, per month. Groups get a single rollup view and group pricing. - Do I have to leave my website provider? No. The layer runs alongside the site you already have. You keep your platform, design, CRM and process. - What if I only want one module from a higher tier? Add it a la carte. Every capability is a module and can be attached to any tier on its own. - Contract or setup fee? Pricing is monthly per domain. Provisioning is included in the tier; Command adds priority provisioning with a named contact. - How do I know it is working? The AI-Readiness Score is public and re-checkable at any time on isitagentready.com. From Counter up, conversation analytics show what buyers asked the AI about the store and where it fell short. ## Modules, the capability catalog Every Parleon capability is a module: 12 of them on one shared brand brain. Each is included from its tier upward and can be added a la carte to a lower tier. ### Included from Beacon: Foundation Everything a machine needs to read your business correctly. On from day one. #### Structured Data + llms.txt Included in: Beacon, Concierge, Counter, Command. Publishes your business, everything you sell and every price as schema.org for your actual type, LocalBusiness, Service, Product and Offer, plus an llms.txt and agents.md that tell an agent what you are and how to work with you. Who it is for: Every business. This is the floor, not the ceiling. Capabilities: schema.org JSON-LD, llms.txt + agents.md, Clean sitemaps, AI-bot allowlist. #### Detail Records Included in: Beacon, Concierge, Counter, Command. One machine-readable record per thing you sell: what it is, what it includes, what it costs, what it excludes and what it needs. Attached to the item an agent reads, so an assistant can answer a specific question instead of paraphrasing a category page. Who it is for: Businesses whose detail lives in PDFs, images or a member of staff's head. Capabilities: Per-item records, Inclusions and exclusions, Structured pricing. #### Readiness Badge + Monitor Included in: Beacon, Concierge, Counter, Command. Your public AI-Readiness Score with a badge you can show, plus continuous monitoring so a website change that breaks your machine-readability gets caught instead of quietly costing you answers. Who it is for: Any business that wants proof, and a tripwire when something regresses. Capabilities: Public score, Embeddable badge, Regression alerts. ### Included from Concierge: Answer What you sell and what it costs, live inside the assistants your customers already use. #### Catalog AI Included in: Concierge, Counter, Command. The core concierge. Everything you sell exposed as agent tools: search by need and budget, pull the detail, compare two options, check what is genuinely available, surface photos and the link to the page. Answers come from your live data, not a cached brochure. Who it is for: Every business that wants to be the answer instead of a link. Capabilities: Search + filter, Detail + compare, Availability, Deep link to the page. #### Offers Included in: Concierge, Counter, Command. Current pricing, packages, promotions and seasonal offers, exposed as structured data an agent can quote with the right conditions and the right expiry. Who it is for: Businesses that run real promotions and want them repeated accurately. Capabilities: Prices + packages, Promotions, Expiry aware. #### Website Offer Sync Included in: Concierge, Counter, Command. Whatever you put on your website, offer rows, featured services, price callouts, is mirrored into the AI layer and kept in sync, so the assistant never quotes a price you changed last week. Who it is for: Anyone running an active offers page. It stops the two surfaces from drifting. Capabilities: Offer mirroring, Continuous sync, Drift detection. #### ChatGPT App Included in: Concierge, Counter, Command. Your own published app inside ChatGPT, built on the Apps SDK, running against the same live data. Customers add your business and deal with it in the conversation they are already having. Who it is for: Businesses that want a named presence in ChatGPT, not just to be cited. Capabilities: Apps SDK, Add-to-ChatGPT button, Live data. ### Included from Counter: Finish The agent stops describing the business and starts doing the work your front desk does. #### Website RAG (Brand Knowledge) Included in: Counter, Command. We index your real site: hours, staff, locations, policies, terms, guarantees and the way you talk. The agent answers questions about your business the way your people would, instead of inventing an answer or refusing. Who it is for: Businesses with real policies and a real voice they do not want flattened. Capabilities: Site knowledge index, Policy + FAQ answers, On-brand tone. #### Quotes + Booking Included in: Counter, Command. Real numbers in the conversation: a quote built from your actual price list, checked against what you genuinely have free, then the appointment taken on your calendar. It turns "can someone come out this week and what will it cost" into a slot and a figure. Who it is for: Any business where the first real question is the price or the date. Capabilities: Quotes from your price list, Live availability, Booking on your calendar. #### Conversation Analytics Included in: Counter, Command. What customers actually asked the AI about your business, what surfaced, which questions the agent could not answer, and where a conversation stopped short of a booking. The gaps are the roadmap. Who it is for: Owners and managers who want to see demand before it shows up in the CRM. Capabilities: Question themes, What surfaced, Unanswered gaps, Drop-off points. ### Included from Command: Everywhere The newest agent surfaces, and the tooling your marketing partner plugs into. #### WebMCP Overlay Included in: Command. Using WebMCP (a Chrome origin trial), the overlay exposes your site's real actions, search what you sell, price a job, book a slot, start an enquiry, as tools an in-browser agent can call on the page the customer is standing on. Who it is for: Early movers who want to own the browser-agent surface before it is table stakes. Capabilities: WebMCP origin trial, On-site agent tools, No site rebuild. #### Agency Brand-Knowledge MCP Included in: Command. An MCP endpoint pointed at your agency's own tools. Your creative team, or their AI, can pull the live catalog, current offers and the client's brand knowledge straight into ad copy, landing pages and campaigns, so the creative is on-brand and never quotes a price that changed. Who it is for: Agencies and in-house marketing teams. Included for resale partners. Capabilities: MCP for creative tooling, Live catalog + offers, Brand voice + guardrails. ## Integrations Parleon builds one authoritative model of a business, then speaks it to whichever agent is asking. A new AI channel is a new adapter on the same brain, not a rebuild of your stack. ### Agent surfaces Parleon speaks #### Claude, via MCP (Live) A Model Context Protocol server per domain. Claude connects to it and gets real tools, not scraped text: search what you sell, pull the detail, compare, check availability, quote a price, take a booking, capture an enquiry. Facts: Real tools per domain, Live data, Tool calls, not scraping. #### ChatGPT, via the Apps SDK (Live) A published ChatGPT App for your business, built on OpenAI's Apps SDK and pointed at the same brand brain. Customers add you and deal with you inside the conversation. Facts: Apps SDK, Add-to-ChatGPT button, Same data as MCP. #### WebMCP, in Chrome (Origin trial) WebMCP lets a page declare tools to a browser-side agent. Our overlay exposes your site's real actions, so an agent working in the browser can search what you sell and book a slot on your own site. Facts: Chrome origin trial, Overlay on your live site, No rebuild. #### Answer engines and AI search (Live) The crawl-and-index path. Full schema.org JSON-LD for your business type, its services, products and offers, an llms.txt and agents.md, clean sitemaps, and an AI-bot allowlist set explicitly rather than left at the platform default, so assistants that read the open web read you properly. Facts: schema.org JSON-LD, llms.txt + agents.md, AI-bot allowlist. #### Your own website (Live) A per-domain overlay that adds the agent affordances, badge, Add-to-ChatGPT, agent-readable markup and WebMCP hooks, to the site you already have. You keep your platform, your design and your vendor. Facts: Keep your platform, Drop-in overlay, No migration. ### Business data sources Parleon reads #### Your catalog or booking system (Primary data) Whatever holds the things you sell and the time you have free: a product feed, a price list, a practice management system, a scheduling tool, a spreadsheet. This is the spine of every answer the agent gives about what you can actually do and when. #### Your website (Brand knowledge) Indexed for brand knowledge: hours, locations, staff, services, policies, terms and guarantees, and the way you talk. It is what keeps the agent on-brand instead of generic. #### CRM, scheduling and website platforms (Generic adapters) Handled generically rather than by brand name. If your system can export a feed, expose an API or accept a standard lead, we can wire it. Tell us what you run and we will confirm the path before you buy anything. #### Prices, packages and promotions (Offers) Your price list, service packages, seasonal promotions and website offers, normalized into structured offers an agent can quote with the right expiry and the right conditions. ### Infrastructure #### Cloudflare The AI layer runs on Cloudflare's edge. Cloudflare now gates AI crawlers by default, and that default-deny is one of the quietest ways a business goes invisible, so we set the allowlist explicitly for every domain we run. ## Partners Parleon runs an agency and reseller white-label program at wholesale pricing. See https://parleon.ai/partners. ## Articles ### WebMCP is the part that changes things URL: https://parleon.ai/blog/webmcp-is-the-part-that-changes-things . Markdown: https://parleon.ai/blog/webmcp-is-the-part-that-changes-things.md . Published 2026-09-01. Category Technology. 6 min read. MCP lets an assistant call your business from somewhere else. WebMCP lets it use your actual website. That difference is smaller than it sounds and it changes what an agent can finish. Almost everything sold as AI readiness is about being **read**. Publish structured data, publish an llms.txt, publish a clean sitemap, and hope that when an assistant is asked about you, it has something accurate to repeat. That is worth doing. It is also the least interesting half of the problem, because a business that can only be read is a business an agent can only describe. The customer still has to leave the conversation, find your site, and start again. WebMCP is the other half. It lets your own pages hand an agent a set of tools, and the agent uses them on the page the person is looking at. ## The distinction, without the acronym soup **MCP** is off-site. Your business exposes an endpoint, and an assistant calls it from inside ChatGPT or Claude without ever visiting your website. Excellent for reach. The person never sees your brand, your photography or your layout. **WebMCP** is on-site. The tools live in the page. The agent searches your catalog, checks a real availability, works out a real price, and the screen the customer is looking at moves while it happens. It is the only one of these protocols where the person can watch the agent work and take the wheel mid-task. **Agent to agent** is business to business, and it is early. Their procurement agent talks to your sales agent. Almost nobody needs it this year. It will be cheap to be early on and expensive to be late. You want all three, but they are not the same product, and only one of them lets the agent finish something in front of the customer. ## What "finish something" means A read-only layer answers "do they have it". A tool layer answers "book it". The gap between those is where every business loses the customer: the moment the conversation ends and a form begins. If an assistant can check the real slot, quote the real price with the real conditions attached, and put a request in front of the person to confirm, the conversation never breaks. That last clause matters more than the rest of the paragraph. The tools that reach a human should not be able to complete on their own. They should fill the request in, show it, and stop. The agent does the work; the person keeps the decision. Anything else is a machine sending messages to strangers on your behalf, which is a category of software nobody has yet been glad they bought. ## The awkward part: you probably cannot ship this to your own website WebMCP is JavaScript on your pages. Which means the honest first question is not "should we do this", it is "who can put code on our website this month". For a large share of businesses the answer is: a third party, on their schedule, for a fee. That is the actual barrier, and it is why so much agent-readiness advice reads as homework nobody hands in. The way around it is to stop asking. Pages and tools can be served at the edge, on your own hostname, on a narrow set of paths, without touching your CMS and without anyone at your website vendor approving anything. Your existing pages behave exactly as they did before, because every other request never reaches the layer at all. That is a deployment detail rather than a protocol, and it is the difference between a spec you agree with and a thing that is live on Thursday. ## What to actually do Three things, in order. 1. **Find out what an assistant can read about you now.** Not what your site looks like. What comes back when something that cannot run JavaScript asks for your pages. 2. **Fix the read layer**, because a tool layer on top of wrong hours is a faster way to be wrong. 3. **Then give the agent something to press.** Search, availability, price, book. Start with the one question that loses you the most customers and make that one finishable. The businesses that get this right will not be the ones with the best content. They will be the ones an assistant can actually do something with. ### MCP 2.0 removed the handshake. Being stateless is not the same as being ready. URL: https://parleon.ai/blog/mcp-2-0-stateless-is-not-ready . Markdown: https://parleon.ai/blog/mcp-2-0-stateless-is-not-ready.md . Published 2026-08-28. Category Standards. 6 min read. The 2026-07-28 Model Context Protocol revision deletes the initialize handshake and replaces it with per-request metadata, mandatory headers and a new discovery method. Our servers were already stateless. Here is why that bought us less than we assumed, and why we are not rushing the upgrade. On 28 July the Model Context Protocol shipped its largest revision since launch. If you run anything that speaks MCP, this is the one that matters, and the way it is being summarised is going to cause people to make a specific mistake. We made the same mistake for about an hour. This is the write-up, including the part where our starting assumption was wrong. ## What actually changed The headline is that MCP became stateless. That is true, and it is bigger than it sounds. Previously a client and a server began with an `initialize` handshake, agreed a protocol version and capabilities, and carried a session identifier through every later request. The new revision removes that entirely. Each request now travels on its own, carrying its protocol version, client identity and client capabilities in a `_meta` field. There is no `initialize`, no `initialized`, and no `Mcp-Session-Id` header. Four other things changed alongside it. Request methods and tool names now travel in HTTP headers. A compliant server must accept `Mcp-Method` and `Mcp-Name`, which lets a gateway route and authorise a call without parsing the JSON body. Multi Round-Trip Requests replace server-initiated requests that needed an open stream. A server can return `resultType: "input_required"` mid-call, and the client retries with the answers included. List endpoints became cacheable. Responses from `tools/list`, `prompts/list`, `resources/list` and `resources/read` now carry `ttlMs` and `cacheScope`. And the specification adopted a formal extensions framework, moving Tasks, MCP Apps and Enterprise Managed Authorization out of experimental status. Roots, Sampling, Logging and the legacy HTTP and SSE transport are deprecated, with a twelve month minimum migration window. ## The assumption we started with, and why it was wrong Our servers do not keep session state. We knew that. So the first conclusion was the obvious one: the headline feature is already how our servers behave, therefore we are most of the way to conforming. We tested the statelessness claim two independent ways before building anything on it, because a belief about your own system is not evidence. The first test was reading the code. Our session table is written when a client initialises and drained when it disconnects, and it is never consulted anywhere else. Nothing reads it to make a decision. The second test was behavioural, run against both of our live engines. We called a tool cold with no session at all. We called it with a fabricated session identifier. We called it while deliberately withholding a real session identifier we did have. All three returned byte-identical response bodies. So the claim held. Our servers are genuinely stateless, verified twice, and we can say so without hedging. And it bought us far less than we expected. Statelessness in the new specification is not a permission, it is a prerequisite. The revision does not merely allow you to drop sessions. It removes the handshake and replaces it with a different mechanism: per-request `_meta`, mandatory headers, a required discovery method, and a `resultType` discriminator on every single result. We match the philosophy of the specification by accident. We implement essentially none of its mechanism. "We are already stateless, so we are nearly there" is the most misleading sentence anyone could take from our own evidence. We are keeping it in writing so we do not repeat it. ## The one-line change that would have been worse than doing nothing This is the part worth stealing regardless of what you run. Our servers hold a tuple of supported protocol versions. Adding `2026-07-28` to that tuple is a one-line change. It compiles, it echoes the new version back to any client that asks, and it passes every automated check we currently have, including our own conformance checker. It would also be a lie. The server would advertise conformance it does not have: no discovery method, no `resultType`, no header validation, no handling of the protocol version in `_meta`. A modern client that believed the advertisement would then fail in ways none of our checks can see, because our checks were written to test the old contract. The dangerous version of an upgrade is not the one that breaks loudly. It is the one where the version string moves, the dashboard goes green, and the actual behavior is unchanged. We came close enough to that to be uncomfortable about it. ## The feature that does not do what its name suggests The second assumption we had to correct: cacheable list results sounded like the clearest win, because catalog and offers get queried constantly and caching them would take real load off the origin. It does not do that. The `ttlMs` and `cacheScope` fields apply to `tools/list`, `prompts/list`, `resources/list`, `resources/read` and `resources/templates/list`. They do not apply to `tools/call`. A live catalog search runs through `tools/call`, so none of its output is covered. What actually gets cached is the static catalog of tools, which changes only when we deploy. That is a genuine improvement and a small one. It is also, usefully, almost risk-free: since no catalog data flows through it, the failure mode we were most worried about, an assistant confidently quoting a product that sold yesterday, is not reachable through this feature at all. We had ranked this item first for value and first for risk. It is neither. ## Why we are not upgrading yet No client is negotiating the new revision. The deprecation window is twelve months at minimum. The specification is days old. Shipping a dual-era server now would mean maintaining two contracts through a period when the second one has no callers, in a codebase where all of our business domains run the same module in a single process. That is a real constraint: it means there is no per-tenant canary release until we build one, so the first deploy of a protocol change is a fleet-wide deploy. That fact alone should slow anyone down. The honest position is that the upgrade is premature, and that saying so is more useful to our customers than a press release claiming day-one support for something no assistant is asking for yet. ## What we are doing instead The cheap, zero-risk half, now, because it costs about two engineer-days and it makes the real upgrade safe when it is time. An audit of everything the new revision deprecates, so we know our exposure before the window closes rather than after. A fix to our conformance checker so it tests the version negotiation matrix rather than assuming one revision. The checker was written when there was only one answer. Client version telemetry, which is the highest-value item on the list and was not in our original plan. Right now we cannot see which protocol revision real clients ask for. That means the trigger to upgrade is invisible to us. Once we can see it, the decision stops being a judgement call and becomes an observation. Consolidating our tool catalog, which currently exists in three hand-synchronised copies. Any protocol change touches all three, so collapsing them first makes the eventual upgrade smaller. We will do the dual-era work when telemetry shows a real client asking for it. Not before. ## What to ask a vendor about this Three questions, and they work on us too. Which protocol revision do you actually implement, and which ones do you advertise. Those should be the same number, and it is worth asking separately. How would you know if a client asked for a revision you do not support. If the answer is a support ticket, they have no telemetry. When the next revision lands, is that an adapter or a rebuild. The specific version numbers will keep moving. Two years ago none of this existed in the shape it exists in now. What should not change is that the thing you advertise and the thing you do are the same thing. --- Specification details in this post come from the Model Context Protocol 2026-07-28 release notes. Our own findings come from an internal scope of the revision completed 29 July 2026 against both of our MCP engines. ### Why AI shopping changes the funnel URL: https://parleon.ai/blog/ai-shopping-changes-the-funnel . Markdown: https://parleon.ai/blog/ai-shopping-changes-the-funnel.md . Published 2026-08-20. Category Strategy. 6 min read. When an assistant does the research, the comparison and the maths before a customer ever visits you, the first half of your funnel happens somewhere you cannot see. The business funnel has been stable for a long time. Awareness at the top, then research, then consideration across a handful of stores, then a lead, then a visit, then a deal. Every tool the industry bought over the last 15 years was built to widen one stage or reduce the leak between two of them. That model assumed something specific: the buyer moves through the stages themselves, in a browser, visiting multiple websites along the way. Break that assumption and the whole diagram stops describing what is happening. ## The middle collapses into one conversation Watch how someone shops with an assistant. They do not open five tabs. They describe a situation in plain language, often including constraints they would never type into a search box: three kids and a dog, a trade with some negative equity, needs to stay under a specific monthly number, has to happen before the end of the month. The assistant does the research. It narrows the options, compares them, factors the budget, weighs the timing, and produces a short list. Frequently it names specific products and specific businesses. Everything from research through consideration just happened inside one exchange. There was no comparison of websites, because no websites were visited. By the time the buyer touches anything you own, the consideration set has already been decided. You were either in it or you were not, and you have no record of which. ## Being in the answer replaces being in the results The old competitive question was about placement: are you ranking, are you bidding, are you on the marketplace. Those are all questions about appearing in a list that a human then chooses from. An assistant does not usually return a list. It returns an answer, often naming one or two options with a reason attached. That is a much smaller space to occupy, and getting into it works differently than ranking does. It is not about spend or authority. It is about whether the model has specific, current, verifiable information about your store that it is willing to stand behind. This is genuinely good news for a lot of businesses, because it is not a budget contest. A single location with complete structured data and a live catalog connection can be the answer over a larger group that has neither. The work is real, but it is work, not spend. ## The lead arrives later and warmer When the assistant handles discovery, comparison and a first pass at the payment, the buyer who finally contacts you is much further along than a classic lead. They know the trim they want. They have a payment range that survived contact with arithmetic. They have often already been told what their trade is roughly worth. Two consequences follow, and one of them is uncomfortable. The good one: these contacts convert better, because most of the qualifying already happened. Your people spend their time on people who are actually in market for something specific. The uncomfortable one: total lead volume can fall while sales hold or improve. If your team is measured on lead count, this looks like a problem for exactly as long as it takes someone to look at closing rate. Any store moving into this properly should decide in advance which number it is managing, because the two will disagree for a while. ## Your website changes jobs The website does not become unimportant. It becomes a different kind of important. Historically the site had to persuade. It was where a shopper who might also be looking at three competitors got convinced. In an assistant-mediated journey, persuasion has often already occurred somewhere else, and the site is where the buyer lands to confirm and act. Is the car actually there, is the price what I was told, can I book the time slot, can I start the paperwork. At the same time your site takes on a second audience that never sees the design at all. It has to serve machines correctly: complete markup, per-item identifier specs in text, structured offers, a crawler policy that lets the right agents in. Those two audiences want different things from the same pages, and most sites today are built for only one of them. The newest wrinkle is that the agent may show up on your site rather than instead of it. WebMCP, currently a Chrome origin trial, lets a page expose its real actions as tools an in-browser agent can call. In that world your website is not just readable to an agent, it is operable by one, on behalf of a shopper who is sitting right there. ## What to actually do about it Four things, in order, none of which require a redesign. Find out where you stand. Run your URL through a public agent-readiness check and get a number instead of a feeling. If you are around 21 out of 100, you are in normal company, and you now know the size of the gap. Fix the readable floor. Complete schema.org markup on every product and every offer, specs decoded out of images, an llms.txt, clean sitemaps, and a deliberate AI crawler policy. This is unglamorous and it is the prerequisite for everything else. Get connected, not just crawled. A live endpoint means assistants query your real catalog in the moment instead of reciting a stale snapshot. Being confidently wrong about availability is worse than being absent. Change what you measure. Add questions your funnel never had to ask: what did buyers ask an assistant about our store, which of our products surfaced, what could the agent not answer, where did the conversation stop short of a lead. The unanswered questions are the highest-value list you will get all year, because each one is a specific deal that almost happened. The funnel is not gone. It got compressed into a conversation, and the only meaningful question is whether your store is present inside it. ### Your sitemap is lying about how fresh your content is URL: https://parleon.ai/blog/your-sitemap-is-lying-about-freshness . Markdown: https://parleon.ai/blog/your-sitemap-is-lying-about-freshness.md . Published 2026-08-06. Category Technology. 5 min read. We crawled a business site and every single page claimed it was updated today. That number is what search engines and AI assistants use to decide what to re-read, and on most business platforms it means nothing. We spent this week rebuilding how we read websites, and found something worth publishing on its own. Every sitemap entry can carry a `lastmod` field: the date that page's content last changed. Search engines use it to decide what to re-crawl. AI systems increasingly use it to decide what is current. It is one of the few honest signals a site gives about itself. On the business we measured, **139 of 141 pages reported the same `lastmod`: the day we asked.** Not the day the staff page changed. Not the day the finance terms were updated. The day we happened to look. Ask again tomorrow and every page will claim it changed again. ## Why platforms do this It is rarely deliberate deception. It is a shortcut. Generating a truthful `lastmod` means tracking when each page's content actually changed, which means storing content versions. Generating a convincing-looking one means writing `now()` into the field when the sitemap is built. Both produce valid XML. Only one of them takes work. For a long time this cost nothing, because nobody checked. Crawlers that got burned by inflated dates simply stopped trusting the field. Google has been explicit that it treats `lastmod` as a hint and ignores it when a site proves unreliable. ## What it costs you now Three things, and the third is the one that should bother you. **Your genuine updates get no priority.** If every page always claims to be fresh, nothing stands out. The day you rewrite your service pricing, that page looks exactly like the 138 that did not change. You have spent the signal. **Crawlers waste their budget on you, then spend less.** A crawler that re-fetches your whole site daily because everything claims to be new eventually adjusts by crawling you less often. The shortcut that was supposed to get you crawled more gets you crawled less. **An assistant cannot tell your 2022 page from your 2026 one.** This is the new part, and it is why we care. When a shopper asks an assistant about your financing options, the assistant has no way to know whether the page it is reading was written last week or three years ago. Both claim today. So it answers with equal confidence either way, and if the page is stale, it states stale terms as current fact with your name attached. A wrong answer that sounds uncertain is a small problem. A wrong answer delivered confidently, attributed to your store, is a different one. ## What we do about it We stopped trusting the field. Our crawler records what a site claims, but it does not treat it as truth. Instead we compute our own signal: a normalized hash of each page's meaningful content, with navigation, scripts, styles and rotating elements stripped out. When that hash changes, the content genuinely changed. When it does not, the content did not, no matter what the sitemap says. That gives us a date we can stand behind, and we keep the two facts strictly separate: - **When we fetched it.** A crawl date. - **When its content actually changed.** Our own observation. - **When the site claims it changed.** Recorded, and treated as a claim. Collapsing those three into one number is how you end up publishing a confident wrong answer. They are different facts and they deserve different fields. We are honest about the limitation too. The change date only starts accumulating meaning from the first time we read a page. For a page we saw for the first time today, we cannot tell you whether it was written in 2022 or last week. That resolves over weeks, and until it does we would rather say we do not know than invent a date. ## What you can do about it, today **Check your own.** Open `yoursite.com/sitemap.xml` and look at the `lastmod` values. If they are all the same date, or all today, your platform is generating them rather than tracking them. **Ask your website vendor one question:** does `lastmod` reflect actual content changes, or is it stamped at build time? It is a fair question with a factual answer, and the answer tells you something about how much else on the site is real. **Do not fix it by turning it off.** A missing `lastmod` is more honest than a false one, but a truthful one is better than both. This is a fixable problem on the platform side, and platforms will fix it when enough businesses ask. ## The wider point The web is being read by machines that cannot ask a follow-up question. A human browsing your site can tell a stale page from a current one within seconds: the layout is dated, the photos are old, there is a reference to a 2022 model year. An assistant reading your markup has none of that. It has the fields you gave it. Which means the fields you give it have to be true. Not decorative, not defensive, not stamped at build time because that was easier. True. That is most of what being agent-ready actually is, and it is less glamorous than it sounds. ### MCP, WebMCP and the agentic web: a field guide URL: https://parleon.ai/blog/mcp-webmcp-field-guide . Markdown: https://parleon.ai/blog/mcp-webmcp-field-guide.md . Published 2026-07-16. Category Technology. 7 min read. A plain-language guide to the protocols behind AI shopping. What MCP is, how WebMCP differs, where ChatGPT apps and schema.org fit, and which ones actually change anything for a business. You are going to be sold MCP this year. It will appear in vendor decks, in conference sessions, and in emails from people who learned the acronym last week. It is worth twenty minutes to understand what it actually is, because the difference between the protocols determines what your store can and cannot do. Here is the field guide, in plain language, with no assumption that you write software. ## The problem all of this solves An AI model on its own can only produce text. To do something useful about your business it needs two things: current information, and the ability to take actions. There have historically been two ways to give it those. Let the model read your website, which is unreliable because websites are built for eyes and because reading gives you a snapshot rather than the truth right now. Or build a custom integration between one specific AI product and one specific system, which works well and costs a great deal, and has to be redone for the next AI product. Every protocol below is an attempt at a third option: a standard way for a system to say here is my data and here are the things you can ask me to do. ## MCP: the connection between an assistant and your systems The Model Context Protocol is a standard for exposing data and tools to an AI assistant. Think of it as a menu your systems publish. Each item on the menu is a tool with a name, a description, defined inputs and defined outputs. For a business the menu looks like search catalog, get product details, compare two products, check availability, look up current offers, estimate a trade, calculate a payment, capture a lead. When a shopper asks a question, the assistant picks the relevant tool, calls it, gets structured data back, and answers from that. Our own business server exposes 24 tools today. Three properties matter to you. It is live. The assistant is querying your actual feed at the moment of the question, not reciting what a crawler saw last week. Availability answers are correct. It is structured. The assistant receives typed data rather than prose it has to interpret, which is the single biggest reduction in the chance of an invented answer. It is reusable. Because MCP is a standard rather than a private integration, any assistant that speaks it can connect. You build the connection once instead of once per AI product. MCP is the difference between an assistant that has read about your store and one that is connected to it. ## ChatGPT apps: a named presence inside one assistant OpenAI's Apps SDK is how you get an actual app inside ChatGPT, with your name on it, that a user adds deliberately. It can render richer interface elements than plain chat and it is discoverable within that product. MCP and a ChatGPT app are complements, not alternatives. The app is a storefront inside one very large assistant. MCP is the wiring that any assistant, including that one, can connect to. Sensibly built, both point at the same underlying data so they can never disagree about what is on your lot. The strategic point is that an app is opt-in and named. Someone adds your business. That is a materially different relationship than being cited occasionally in a general answer. ## WebMCP: agents that operate your website The newest of the four, currently a Chrome origin trial, and the one most likely to be misexplained to you. MCP connects an assistant to a server somewhere. WebMCP lets a web page itself declare tools to an agent running in the browser. The shopper is on your site, an agent is working on their behalf in that browser, and your page can offer it real capabilities: search this catalog, price this payment, start this lead. Why this matters is context. The agent is not guessing what your site can do from the rendered HTML, and it is not clicking around a page it does not understand. It is calling functions you defined, on the page the shopper is actually looking at, with the shopper's session and preferences intact. It is early. Origin trial means Chrome is testing it with real sites before committing, and the specification is still moving. It is worth building for now precisely because it is early: this is the surface where being first is cheapest. ## schema.org and llms.txt: the readable floor The least exciting item on the list, and the one most businesses actually need first. schema.org is a shared vocabulary for describing things on a web page so machines understand them. For a business that means LocalBusiness, Service, Product and Offer types, embedded as JSON-LD, telling a machine what this is, what it includes, what it costs, who provides it, and whether it is actually available. llms.txt is a newer and simpler convention: a plain text file at a known location on your domain that tells an AI agent what this site is, what it offers, and where the authoritative information lives. The same spirit as robots.txt, aimed at a different reader. Neither is live and neither lets an agent do anything. They are how the crawl-and-index path works, which still matters enormously, because answer engines and AI search read the open web and because a model with no live connection to you falls back to whatever it can read. There is a related trap here. Cloudflare now gates AI crawlers by default. Perfect structured data does you no good if a default setting blocks the agents you want. Check that specifically. ## How they fit together The mental model that holds up: schema.org and llms.txt make you readable, MCP and ChatGPT apps make you answerable, WebMCP makes you operable, and the layer underneath all of them should be one authoritative model of your store rather than four independent copies. That last part is the thing to insist on when a vendor pitches you. If the ChatGPT app has its own catalog copy and the website has another, they will disagree, and they will disagree in public, in front of a buyer. One source of truth, many surfaces, is the only shape that survives the next protocol. ## What to ask a vendor Five questions that separate the real from the rehearsed. Is the data live at question time, or crawled on a schedule, and what is the freshness window. Which surfaces are actually deployed today for a real customer, with a URL you can check. Do all of the surfaces read from one source, and what happens when a unit sells. Which tools can the agent call, specifically, and can it complete a lead into my CRM. When the next surface appears, is that an adapter or a rebuild. That last question is the whole game. Two years ago none of these protocols existed in the form they exist in now. The specific acronyms will keep changing. What should not change is the truth about your store, held in one place, ready to speak whichever protocol shows up next. ### What agent-ready actually means: the five levels URL: https://parleon.ai/blog/what-agent-ready-means . Markdown: https://parleon.ai/blog/what-agent-ready-means.md . Published 2026-06-25. Category Fundamentals. 6 min read. Agent-ready is not a badge you either have or do not. It is a ladder, from a site a machine cannot parse to a store an AI can transact with. Here is what each of the five levels means in practice. Every few years the industry adopts a phrase faster than it agrees on a meaning. Mobile-first went that way. Omnichannel went that way. Agent-ready is going that way right now, and by the end of the year every vendor in the space will have it on a slide. So here is a definition specific enough to argue with. Agent-readiness is not binary. It is a ladder with five rungs, and each rung answers a different question about what an AI can do with your store. ## Level 1: Invisible At Level 1 a machine requesting your pages gets a shell. The product grid assembles in the browser, the specs live inside images, the offers are a PDF, and there is little or no structured data describing any individual product. Often the crawler policy blocks AI agents by default and nobody in the store knows. The important thing about Level 1 is that it is completely compatible with a great website. Fast, attractive, converting well, redesigned last year. Human experience and machine legibility are separate axes, and almost nobody was building for the second one until recently. This is where most businesses start when they first run the check, typically somewhere around 21 out of 100. ## Level 2: Readable At Level 2 a machine can establish the basics. There is valid schema.org markup identifying the business as a LocalBusiness of the right type, with a real address, hours and phone number. Some product data is present in a parseable form. The sitemap is clean and the robots policy does not accidentally exclude the agents you want. An assistant at this level can confirm you exist and roughly what you are. It cannot reliably answer a question about a specific product, because the product data is partial, inconsistent, or stale. In practice a Level 2 store gets mentioned but not recommended, because the model has nothing concrete enough to stand behind. ## Level 3: Understood Level 3 is where structured data becomes complete rather than decorative. Everything you sell carries proper Product, Service and Offer markup: what it is, what it includes, what it excludes, how long it takes, what it costs, whether it is available, photos, and a link that resolves to the right page. Detail is decoded into text rather than trapped in a PDF or an image. Prices and promotions are structured objects with conditions and expiry dates rather than a marketing graphic. Now an assistant can answer factual questions about your catalog: can you do this particular job under a certain price, what does that package actually include, how soon could it happen. This is a real threshold. It is the first level at which you can be the source of an answer instead of a footnote in someone else's. The limitation is freshness. Level 3 still depends on crawling, which means the assistant is working from a snapshot. If a unit sold this morning, the answer may be wrong this afternoon, and being confidently wrong about availability is its own kind of damage. ## Level 4: Answerable Level 4 replaces the snapshot with a connection. Instead of waiting to be crawled, your store exposes a live endpoint that assistants can query in the moment, in practice a Model Context Protocol server, a published ChatGPT app, or both. The difference is not subtle. At Level 3 the assistant recites what it read. At Level 4 it asks your systems a question and reports what came back, right now. Search by need and budget, compare two units, check whether something is still on the shelf, quote the current program. The answer is as current as your feed, which is the standard a shopper already expects from every other category they buy in. This is also the level at which you get a named presence rather than an incidental mention. A buyer can add your store inside the assistant and shop it directly. You are no longer hoping to be retrieved. You are connected. ## Level 5: Agent-Native At Level 5 the assistant stops describing and starts doing. It has tools, and the tools do the work your front desk does: price a real job from your real rates, check what is genuinely free rather than guessing, turn "sometime this week under 500" into an actual slot at an actual figure, answer a policy question the way you would answer it, and take the booking or drop a structured enquiry into your CRM without the customer ever leaving the conversation. It also means being present on more than one surface, because buyers are not all in the same place. The same underlying model of your store answers over MCP, inside a ChatGPT app, to an agent operating your own website in the browser through WebMCP, and to the answer engines that read the open web. This is the top of the checker's scale, 100 out of 100, and it is where the live Parleon tenants sit today. Not as a projection, as a number anyone can reproduce by running the same public check against the same live sites. ## Why the ladder matters more than the badge Two things follow from framing this as levels rather than a yes or no. The first is that you can locate yourself honestly. Most stores are not at zero. They have some markup, a decent sitemap, maybe a vendor who did a competent job on the basics. Knowing you are at Level 2 and not Level 4 tells you exactly which work remains, and it is usually less work than people fear. The second is that claims become checkable. When someone tells you their product makes you AI-ready, the useful follow-up is which level, measured how, verifiable where. A number produced by a public checker against a live URL is a different kind of assertion than a bullet on a slide. That is the entire reason we made the checker public even though anyone, including our competitors, can run it. Ladders are also honest about sequencing. You cannot skip to Level 5. Live tools built on top of catalog data that a machine cannot parse correctly will confidently produce wrong answers faster. The unglamorous work at Levels 2 and 3 is what makes the impressive work at Levels 4 and 5 trustworthy. Start by finding out which rung you are on. Everything else is a decision about how far up you want to go. ### Your business is invisible to ChatGPT (and how to check) URL: https://parleon.ai/blog/invisible-to-chatgpt . Markdown: https://parleon.ai/blog/invisible-to-chatgpt.md . Published 2026-06-11. Category Visibility. 5 min read. Most websites render beautifully for humans and return almost nothing useful to an AI assistant. Here is what an agent actually sees, and how to check yours in about a minute. There is a specific kind of bad news that never shows up in your analytics: the customer who never arrived. No session, no bounce, no abandoned form. They asked an assistant a question, got an answer that named a business, and drove there. If the business named was not yours, nothing in your reporting will ever tell you the conversation happened. This is the part of the AI shift that is easy to miss. It does not look like a traffic drop. It looks like nothing at all. ## What an assistant actually receives Open your product page and look at it. Now consider what arrives on the other end when a machine requests that same page. On a large share of sites, the answer is: a shell. The product grid is assembled in the browser by JavaScript after the page loads, so a fetch that does not execute scripts gets an empty container. The detail a customer reads off the spec sheet lives inside a JPEG, which is opaque to a text model. The price is calculated by a widget that runs client side. The current offers are a PDF, or worse, an image of a PDF. And the structured data, the machine-readable summary that says "this is what it is, this is what it includes, this is its price, this is who sells it", is either missing entirely or present in a thin, generic form that describes the business but not a single product. Then there is the quietest failure of all: the crawler policy. Cloudflare moved to gating AI crawlers by default, and plenty of sites now block AI user agents without anyone in the store having made a decision about it. You can have flawless structured data and still be unreachable because a default setting somewhere says no. Stack those together and the assistant is not being unfair to you. It genuinely cannot see what you have. ## Why it recommends someone else Assistants do not fail loudly. When a model lacks specific, current information about your store, it does not announce a gap. It answers the question with whatever it does have, which is usually one of three things. It falls back to a third party. Marketplaces and aggregators invest heavily in machine-readable catalog, so their version of your stock is often more legible than yours. The buyer gets an answer built on someone else's summary of your lot, complete with someone else's lead form. It falls back to a competitor. The store two exits down that happens to run a platform with clean structured data becomes the concrete, checkable recommendation. Concreteness wins. An assistant asked to name a business will name the one it can describe. Or it falls back to generalities. It tells the buyer to check local businesses, which is another way of saying it could not help, and the buyer goes back to searching. None of these outcomes generate a signal you can see. That is the whole problem. ## The check takes about a minute You do not have to take any of this on faith, and you should not. Run your own URL through the public checker at [isitagentready.com](https://isitagentready.com). It looks at your live site the way an agent does and scores what a machine can actually read, understand and act on, from zero to 100 across five levels. Most businesses who run it for the first time land somewhere around 21 out of 100. That is not a mark of a bad website. Plenty of stores scoring in the low twenties have genuinely excellent sites by every human measure: fast, attractive, converting well, recently redesigned. The score is measuring a different axis entirely, one that nobody was building for until very recently. If you want to sanity check it yourself before trusting any tool, here are three things you can do in the next ten minutes. Ask an assistant directly. Open ChatGPT or Claude and ask, in the voice of a real shopper in your market, which business has a specific kind of product in a specific payment range. See who gets named. See whether the details about your store are current, or invented, or absent. View the page source of a product page, not the rendered page. In your browser use view-source rather than inspect, since inspect shows you the DOM after JavaScript has run. Search that raw source for the item identifier and for `application/ld+json`. If the item identifier is not there and there is no JSON-LD block describing the product, a crawler that does not execute scripts is getting nothing. Check your robots and your AI bot policy. Look for `/robots.txt` and see what it says about AI user agents. Then ask whoever manages your CDN whether AI crawler blocking is on. A surprising number of stores find the answer is yes and nobody chose it. ## What fixing it actually means The remedy is not a redesign. Your website is not the problem, and rebuilding it will not move this number much on its own. What moves it is making the same catalog legible in a second form: complete schema.org markup for every product and every offer, a per-item identifier spec record that does not live inside an image, an llms.txt that tells an agent what you are and how to work with you, clean sitemaps, and a crawler policy that deliberately allows the agents you want to reach you. That is the readable floor. Above that floor sits the part that actually wins the recommendation: a live connection, so an assistant queries your real catalog in the moment rather than relying on whatever it crawled last week, and real tools so it can estimate a trade, run a payment and hand you a lead inside the conversation. The first step is just knowing. Run the check, get the number, and decide from there. Being invisible is a fixable condition. Not knowing you are invisible is the expensive part. ## Machine-readable endpoints - MCP (JSON-RPC 2.0): https://parleon.ai/api/ucp/mcp - MCP server card: https://parleon.ai/.well-known/mcp/server-card.json - A2A agent card: https://parleon.ai/.well-known/agent-card.json - UCP discovery: https://parleon.ai/.well-known/ucp - API catalog (RFC 9727): https://parleon.ai/.well-known/api-catalog - Agent skills index: https://parleon.ai/.well-known/agent-skills/index.json - Agent instructions: https://parleon.ai/agents.md - Auth policy: https://parleon.ai/auth.md - Structured feed: https://parleon.ai/data.json - Search index: https://parleon.ai/search-index.json - Sitemap: https://parleon.ai/sitemap.xml - Agentic discovery sitemap: https://parleon.ai/sitemap_agentic_discovery.xml ## Contact Email: hello@parleon.ai