Orientelectric

Orient Electric Documentation Audit

Orient Electric ships a full agent-facing surface — llms.txt, llms-full.txt, agents.md, a UCP/MCP commerce profile, and an agentic-discovery sitemap — but the surfaces name three different hosts (and the profile even contradicts itself), the one documented MCP call returns 422, the recommended browse path is blocked by robots.txt, and two of the four advertised policy pages render empty.

1. Agent docs, the UCP profile, and robots.txt name three different hosts — and the profile contradicts itself (critical)

Location: /llms-full.txt and /agents.md (Commerce Protocol section) vs /.well-known/ucp vs /robots.txt

Problem: Both agent docs state the two endpoints "to know" are GET https://orientelectric.com/.well-known/ucp for discovery and POST https://orientelectric.com/api/ucp/mcp for MCP. But the live merchant profile returned by that discovery endpoint points every service at a different host: "endpoint":"https://orientelectric.myshopify.com/api/ucp/mcp", and both version profiles resolve to https://orientelectric.myshopify.com/.well-known/ucp/2026-04-08 (and …/2026-01-23). The MCP error response leaks "continue_url":"https://orientelectric.myshopify.com/". The profile also disagrees with itself: the Google Pay block carries "merchant_origin":"orientelectric.com" while every service endpoint and version URL in the same document says myshopify.com. And robots.txt advertises a third host — Sitemap: https://shop.orientelectric.com/sitemap.xml (which 301-redirects back to orientelectric.com/sitemap.xml).

Consequence: An agent that trusts the prose docs sends MCP traffic to orientelectric.com/api/ucp/mcp, while the machine-readable profile it's told to honor says the real host is orientelectric.myshopify.com — and the profile can't even keep its own merchant_origin consistent with its endpoints. The two authoritative sources disagree on the single most important value in the whole protocol — the host you transact against — and a third host appears in the sitemap directive. Agents that pin to one host silently diverge from agents that pin to another.

The fix: Pick one canonical host and make the prose docs, the .well-known/ucp services/supported_versions URLs, the merchant_origin field, the error continue_url, and the robots.txt Sitemap: line all agree. If orientelectric.com is the intended public host, rewrite the profile to emit it everywhere; if myshopify.com is canonical, correct llms-full.txt/agents.md.

2. The documented "Typical Agent Flow" first call returns HTTP 422 (critical)

Location: /llms-full.txt and /agents.md ("Typical Agent Flow" → "Use the MCP tools/list method to discover available tools") vs POST /api/ucp/mcp

Problem: Following the docs verbatim — POST to the MCP endpoint with {"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}} and Content-Type: application/json — returns HTTP 422 with {"error":{"code":-32001,"message":"UCP discovery failed","data":{"code":"invalid_profile_url","content":"Unable to fetch agent profile: Missing profile uri"}}}. The same call to the profile's own host (orientelectric.myshopify.com) returns the identical 422. The docs never mention that an agent-profile / profile uri handshake is required before tools/list will work.

Consequence: The very first protocol call a new agent makes, exactly as documented, fails. Worse, because tools/list cannot complete, none of the five tool names the docs promise (search_catalog, create_cart, create_checkout, update_checkout, complete_checkout) can be discovered through the documented path — an agent has no way to confirm those tools exist or learn their schemas.

The fix: Document the required profile handshake: what a profile uri is, how an agent supplies it, and a complete working tools/list request that returns 200. Until that's documented, the entire "Typical Agent Flow" is non-executable.

3. robots.txt blocks the recommended GET /search read-only method (significant)

Location: /llms-full.txt and /agents.md ("Read-Only Browsing" → Search: GET /search?q={query}&type=product) vs /robots.txt

Problem: The agent docs recommend GET /search?q={query}&type=product as a no-auth way to read store data. But robots.txt contains Disallow: /search for User-agent: *. The docs offer search as a read-only browsing primitive while the crawl directive tells every well-behaved agent not to fetch it. (Disallow: /search is Shopify's default robots directive, so this is degraded discovery rather than a hard outage — the docs themselves provide a usable fallback in the collection JSON endpoints.)

Consequence: A compliant agent that respects robots.txt (most crawlers and many shopping agents do) will refuse to call the one search endpoint the docs hand it, falling back to scraping /collections/all or guessing product handles. An agent that ignores robots.txt to follow the docs is being pushed into non-compliant behavior by the store's own instructions.

The fix: Decide whether /search is an approved agent surface. If yes, carve out an Allow for it; if no, drop the GET /search recommendation from the agent docs and point agents explicitly to the collection JSON endpoints instead.

4. Terms of Service and Shipping Policy pages render empty at the URLs the agent docs advertise (critical)

Location: /policies/terms-of-service and /policies/shipping-policy (both linked from /llms-full.txt and /agents.md under "Store Policies", "Full policies available at the URLs above")

Problem: The agent docs link four policy URLs and promise full text behind them. Two of those URLs return no policy content at all — only the cart/cookie shell and a leaked placeholder: "ssdcsdc has been added to your cart." The same raw fetch returned full text for /policies/refund-policy and /policies/privacy-policy, so this is an empty/unconfigured page, not a render artifact. /pages/shipping-policy additionally returns HTTP 404 page_not_found, so there is no populated shipping policy anywhere except a sub-section buried inside /pages/return-refund-policy.

Consequence: An agent (or human) following the documented links to confirm terms before transacting finds nothing — no governing terms of service exist at the advertised URL, and shipping terms cannot be discovered from the link the docs provide. For an agent-driven checkout flow, "what are the terms I'm agreeing to" is unanswerable from the canonical source.

The fix: Populate /policies/terms-of-service and /policies/shipping-policy with real content (Shopify's policy editor renders these), or correct the agent docs to link the actual locations. Either way, no advertised policy URL should render the cart shell.

5. robots.txt blocks /policies/ — the entire path the agent docs link for policies (significant)

Location: /robots.txt (Disallow: /policies/) vs /llms-full.txt and /agents.md (all four policy links under /policies/*)

Problem: Every policy URL the agent docs hand out lives under /policies/ — privacy, terms, refund, shipping. robots.txt contains Disallow: /policies/ for all user-agents, blocking crawlers from precisely those pages.

Consequence: A robots.txt-respecting agent is told by the docs to read policy pages it is simultaneously told not to fetch. Combined with finding #4 (two of those pages are empty anyway), an agent has no compliant, documented way to retrieve the store's terms.

The fix: If policies are meant to be agent-readable, Allow: /policies/ (or surface the policy text inside agents.md/llms-full.txt directly). If not, stop linking /policies/* from the agent docs.

6. Two divergent refund policies; the agent-facing one omits how to act on its own 24-hour deadline (significant)

Location: /policies/refund-policy (linked by agent docs) vs /pages/return-refund-policy (linked by the warranty page)

Problem: The agent-facing /policies/refund-policy is materially thinner than the human-facing /pages/return-refund-policy. It states a product "will not be refunded" if there is "Physical damage not notified within 24 hours of receiving the product" — but never says how or where to notify. The actual procedure (email customer.connect@orientelectric.com within 24 hours with the invoice and mandatory images) exists only in the /pages/ version, which also adds an entire Cancellation Policy, Product Pricing, Security, Out-of-Stock, and Delivery (7–10 business days) — none present in the agent-facing copy.

Consequence: An agent reading the documented refund policy learns it must report damage within 24 hours to preserve a refund, but the doc gives it no action to take, no email, and no mention that images are mandatory to start the claim. The buyer misses the window because the binding deadline and its procedure live in two different documents, only one of which agents are pointed at.

The fix: Make the agent-linked /policies/refund-policy the single source of truth and merge in the reporting procedure (email, 24-hour window, mandatory images), cancellation, delivery, and out-of-stock handling — or point the agent docs at /pages/return-refund-policy and retire the thin duplicate.

7. The agentic-discovery sitemap lists only agents.md; three near-duplicate agent docs invite silent drift (significant)

Location: /sitemap_agentic_discovery.xml, /agents.md, /llms-full.txt, /llms.txt

Problem: agents.md declares itself "the canonical agent-facing description of the store," and llms-full.txt says it "mirrors that content" — so both files name agents.md as authoritative; they do not disagree about which wins. The structural defect is elsewhere: the dedicated /sitemap_agentic_discovery.xml lists only /agents.md and references neither /llms.txt nor /llms-full.txt, so an agent that discovers the store through the agentic sitemap is never pointed to the llms*.txt surfaces at all. Meanwhile the same content is hand-maintained across three near-duplicate files that already differ (the self-reference line differs between agents.md and llms-full.txt; llms.txt omits policy URLs the others carry — see #8), so future edits to one will quietly diverge from the others.

Consequence: An agent's picture of the store depends on which surface it discovered first. The agentic sitemap excludes two of the three documents, and with three hand-maintained copies, drift between them is a matter of when, not if — and there is no machine-checkable signal that they have diverged.

The fix: List all agent docs in sitemap_agentic_discovery.xml (or collapse to the single canonical file), and have the non-canonical docs explicitly point at agents.md as the source so any divergence is detectable rather than silent.

8. llms.txt omits policy URLs that agents.md advertises, and routes franchise info to an unguessable slug (significant)

Location: /llms.txt ("Important Pages") vs /agents.md ("Store Policies") and /pages/warranty-registration

Problem: llms.txt lists "Important Pages" but includes neither the privacy-policy nor the return/refund-policy URL, so it disagrees with agents.md (which uses /policies/*) and the warranty page (which uses /pages/*) about where the store's policies even live. It also routes "Franchise Information" to /pages/overview — a slug an agent could never guess from the stated Page URL pattern. It additionally publishes support hours ("Mon–Fri 09:30 AM–05:30 PM IST") that no other documented surface repeats.

Consequence: An agent reconciling the three docs gets three different maps of the store: policy URLs depend on which file you read, the franchise destination can't be derived from any documented convention, and the support hours can't be cross-checked, so an agent can't tell whether they're current.

The fix: Unify the page/policy inventory across llms.txt, agents.md, and llms-full.txt. Document non-obvious slugs like /pages/overview explicitly, and keep support hours in one canonical place.

9. Production pages leak the ssdcsdc test placeholder, and key pages are JS-only with no warning to agents (significant)

Location: /policies/shipping-policy, /policies/terms-of-service, /pages/contact-us, /pages/warranty-registration, /pages/codes-policies (raw HTML)

Problem: A developer test string renders in live page text site-wide: "ssdcsdc has been added to your cart." / "ssdcsdc has been removed from cart.". Separately, the warranty-registration and codes-policies pages return only the cart shell in static HTML — their real content (the warranty form; the investor policy list) is entirely JS-rendered. The agent docs never warn that any content requires JS execution.

Consequence: Non-JS agents and crawlers (a large share of shopping/indexing agents) fetch these pages and get a cart shell plus a leftover test token — no warranty form, no codes list — with no signal that content was withheld pending JS. The ssdcsdc strings also pollute any text an agent extracts, and signal unfinished/test content shipped to production.

The fix: Remove the ssdcsdc placeholder strings from production. Server-render (or provide a no-JS fallback / structured data for) the warranty and policy content, and have the agent docs state which surfaces require JS.

10. Warranty registration silently excludes most of the catalog (significant)

Location: /pages/warranty-registration (JS-rendered content)

Problem: The page states "Registration is only applicable for Fans, Water Heaters & Air Coolers." The homepage and llms.txt show the store also sells Lighting, Switchgears, Small Appliances (irons, kettles), and Room Heaters. The page documents no warranty-registration path for any of those product lines, and review takes "within the next 3-5 working days."

Consequence: A buyer (or an agent registering on a buyer's behalf) who purchased a light, a switch, or a room heater has no documented way to register warranty and no statement of what warranty process applies instead. The exclusion is buried in JS-only content, so non-JS agents never even see the limitation.

The fix: Document the warranty path for every product category sold, or explicitly state on the page (and in agents.md) which categories have no online registration and what the alternative is.

11. Support contacts are fragmented across at least seven identifiers with no canonical directory (minor)

Location: /llms.txt, /pages/return-refund-policy, /policies/privacy-policy, /pages/warranty-registration, /pages/contact-us

Problem: Contact channels are scattered and role-specific with no single map: emails customer.connect@orientelectric.com (orders/damage), ecommerce@orientelectric.com (security vulnerabilities), privacy.officer@orientelectric.com (privacy/grievance), marcom@orientelectric.com (marketing opt-out); phones +91 9667121111 and +91 8826313838 (WhatsApp); plus grievance line 011-40507000. The OTP-gated "Talk to Agent" voice assistant is scoped to "product installation and service requests only" and routes "anything else" back to a circular "contact us here" link.

Consequence: An agent or buyer trying to route an issue (a return vs. a security report vs. a privacy request) has to read five different pages to find the right address, and the voice channel offers no documented fallback, hours, or escalation for out-of-scope requests.

The fix: Publish one canonical contact directory (channel → purpose → hours → SLA) and reference it from llms.txt/agents.md. Give the voice assistant a documented fallback for out-of-scope requests instead of a self-referential link.

12. Shared privacy-policy defects: placeholder text, a typo, mismatched jurisdiction, and a duplicate page (minor)

Location: /policies/privacy-policy and /pages/privacy-policy

Problem: Two parallel privacy policies exist at different URLs (agent docs link /policies/, the warranty page links /pages/). Both share an unfilled template placeholder — "Other companies or programs of our Company Name affiliates" — a typo, "hotograph of individuals" (should be "Photograph"), and the statement "Our Company's websites do not honor web browsers' Do-Not-Track signals." Both lean heavily on GDPR/EU-EEA framing on an India-only (₹/GST) storefront, and the /pages/ version duplicates its entire intro paragraph under two headings.

Consequence: An agent extracting privacy terms ingests an unresolved Company Name placeholder and a duplicated paragraph as if they were authoritative, can't tell which of the two policies governs, and reads EU-centric language that may not reflect the store's actual (Indian) legal basis.

The fix: Consolidate to one privacy policy, fill the Company Name placeholder, fix the "Photograph" typo and the duplicated intro, and align the jurisdictional framing (DPDP Act / IT Act 2000) with the store's actual market.

13. /pages/codes-policies is labeled for shoppers but delivers investor-relations PDFs (minor)

Location: /pages/codes-policies

Problem: The page is surfaced as "Codes & Policies" — a label a shopper or agent reads as consumer commerce terms — but its actual (JS-only) content is a corporate-governance list: Equal Opportunity Policy, Human Rights Policy, Anti-Bribery Anti-Corruption Policy, Code of Conduct for Suppliers, POSH Policy, Grievance Redressal Policy, ESOP Scheme, Related Party Policy, and so on — zero shopping, returns, or warranty policy.

Consequence: An agent or shopper following a "Codes & Policies" link expecting commerce terms lands on investor-relations governance PDFs, and finds none of the returns/shipping/warranty terms the name implies.

The fix: Retitle the investor page to reflect its governance content, and host consumer commerce policies under a clearly named shopping-policies page that the agent docs link.

14. Homepage price block renders a single price five times and surfaces inconsistent founding claims (minor)

Location: / (homepage)

Problem: Each product repeats one price five times — Sale price From ₹4,159 ₹4,159 ₹4,159 ₹4,159 ₹4,159 — alongside a separate struck-through MRP and EOSS price, consistent with an unrendered template loop. The page also asserts unsourced marketing claims ("20+ Crore Happy Customers", "Expertise of 65+ years"); the "65+ years" figure is internally inconsistent with llms.txt's own timeline (Founded 1939 / Fans Division 1954 / Rebranded as Orient Electric 2014), which yields no clean 65-year figure.

Consequence: An agent scraping price from the homepage DOM sees the same value five times and a separate MRP/EOSS pair, making it ambiguous which field is the authoritative sale price. The conflicting heritage figures undercut any agent trying to extract a single factual "years in business" claim.

The fix: Fix the price template so each price field renders once with an unambiguous label (regular / MRP / EOSS sale), and reconcile the "65+ years" claim against a stated founding date.

What they do well

• They actually invested in an agent surface. A UCP/MCP commerce profile, agents.md, llms.txt, llms-full.txt, and a dedicated sitemap_agentic_discovery.xml put Orient Electric ahead of most retail sites on agent-readiness — the bones of agent commerce are present.
• Company identity is crisp and machine-parseable. llms.txt cleanly states parent group, founding dates, stock codes, manufacturing sites, URL patterns, and minimum checkout value (₹500) — genuinely useful structured context for an agent.
• Read-only browsing primitives are well chosen. Documenting /products/{handle}.json and /collections/{handle}/products.json gives agents real machine-readable catalog access independent of the MCP flow.

Top 3 recommendations

1. Pick one host and make the first MCP call work. Reconcile orientelectric.com, orientelectric.myshopify.com, and shop.orientelectric.com across the prose docs, the .well-known/ucp profile (including its own merchant_origin field), the error continue_url, and the robots.txt sitemap line — then document the profile uri handshake so the documented tools/list call returns 200 instead of 422.
2. Fix the policy layer end-to-end. Populate the empty /policies/terms-of-service and /policies/shipping-policy, collapse the duplicate refund and privacy policies to one source each (carrying the 24-hour damage procedure into the agent-facing copy), and stop blocking /policies/ and /search in robots.txt if agents are meant to read them.
3. Ship clean production pages. Remove the ssdcsdc test placeholder site-wide, server-render or provide structured fallbacks for the JS-only warranty and policy pages, fix the homepage price-template loop, and consolidate the seven scattered support contacts into one canonical directory referenced from the agent docs.