Beyond llms.txt: Structuring Business Data So Agents Do Not Hallucinate Your Hours and Prices

Most people searching for how to format business data for agents reach for llms.txt. It is worth being precise about what that file is. By its own description, llms.txt is "a proposal to standardise on using an /llms.txt file to provide information to help LLMs use a website at inference time." It was authored by Jeremy Howard and published on 2024-09-03. It remains an open proposal, not a ratified standard.

Its status matters less than its shape. The format is a markdown file whose only required section is an H1 with the site name, plus an optional blockquote summary and H2 link lists. It exists to point a language model at brief background and detailed markdown documentation. It does not carry typed commerce facts. There is no field in llms.txt for "opens at 09:00, closes at 17:30, Monday through Friday," and none for "price range two dollar signs." You would be writing prose and hoping the model parses it correctly, which is exactly the ambiguity you set out to remove.

Adoption is low. No major model provider has committed to honouring it, and figures at Google have publicly questioned the proposal. None of that makes llms.txt useless. It is a reasonable way to hand a model a curated map of your documentation. It is simply the wrong instrument for hours and prices.

Schema.org has carried the answer for over a decade. The OpeningHoursSpecification type is "a structured value providing information about the opening hours of a place or a certain service inside a place." Its typed properties are dayOfWeek, opens, closes, plus validFrom and validThrough for temporary changes like a holiday schedule. These are not free text. They are machine-typed values an agent can resolve without guessing.

For commercial terms, LocalBusiness defines openingHours, openingHoursSpecification, priceRange (a categorical text value such as $$$), currenciesAccepted, and paymentAccepted. Note one real limit: there is no exact-price-amount property at the LocalBusiness level. priceRange is categorical by design. When you need to publish an exact figure, you model the thing as a Product or Offer and use Offer.price, which is standard practice once an entity is modeled that way.

Google's guidance is concrete. Its Local Business documentation recommends JSON-LD and the most specific LocalBusiness sub-type. It specifies opens and closes in hh:mm:ss format, represents 24-hour operation as opens 00:00 and closes 23:59, and caps priceRange at under 100 characters. The only strictly required properties are name and address. openingHoursSpecification and priceRange are recommended, not mandatory. This is a solved data-modeling problem.

Here is the part that reframes the whole question. An agent that tells a customer you close at 6pm when you close at 5pm is almost never confused by a missing standard. It is reading a number that was once true. Your JSON-LD says 6pm because someone set it eighteen months ago. Your visible page now says 5pm because a manager updated the website copy. Nobody reconciled the two.

Google treats this drift as a policy violation, not a cosmetic flaw. The structured data guidelines state plainly that "your structured data must be a true representation of the page content" and "don't mark up content that is not visible to readers of the page." Violations can trigger manual actions that strip your rich-result eligibility. So the discipline that protects your search appearance is the same discipline that keeps an agent honest. The typed data and the human-readable page must say the same thing, and both must be current.

That is why the real work is operational, not notational. You need a single source of truth for your hours and prices. You need both the page and the JSON-LD generated from it. And you need that pipeline to run whenever the underlying fact changes. A new file format does nothing for a sync problem.

Typed, consistent data is the foundation. The layer above it governs how an agent actually reaches in and uses it. Here the relevant standard is the Model Context Protocol (MCP), "an open protocol that enables seamless integration between LLM applications and external data sources and tools." MCP runs on JSON-RPC 2.0 across Hosts, Clients, and Servers, and exposes Resources, Prompts, and Tools. Its current specification revision is dated 2025-11-25.

MCP matters because consent is built in. Its security principles require explicit user approval before invoking any tool, and they state that tool behavior descriptions "should be considered untrusted, unless obtained from a trusted server." That is the line between a model passively reading your published facts and an agent taking an action against your business with a human in the loop.

These layers are converging on schema.org rather than replacing it. Microsoft's open-source NLWeb natively supports MCP, positions itself as "to MCP/A2A what HTML is to HTTP," and deliberately reuses existing schema.org markup. NLWeb argues that schema.org and semi-structured formats, which it says are used by over 100 million websites, have become "a semantic layer for the web," and every NLWeb instance runs as an MCP server with an ask method. The direction of travel is clear. The data stays in schema.org. The access and consent layer is MCP.

One more distinction keeps two different decisions from collapsing into one. Marking your facts up for agents to read is not the same as consenting to have your content train a model. Those are governed separately. Google's Google-Extended is "a standalone product token that web publishers can use to manage whether content Google crawls from their sites may be used for training future generations of Gemini models." You set it through the Google-Extended user-agent token in robots.txt. It governs Gemini Apps, the Vertex AI API for Gemini, and grounding features, and it does not affect your inclusion or ranking in Google Search.

The practical posture has three moves. Publish typed, accurate JSON-LD so agents quote your hours and prices correctly. Expose action through a consented protocol like MCP. Use training-control tokens to make a deliberate, separate choice about model training. Three layers, three decisions, all governable.

Origin Pi builds the governed business layer that sits underneath all of this. The thesis is simple. An agent is only as trustworthy as the business facts it reads, so those facts have to be typed, consistent with what humans see, and continuously synced from one source of truth. Our work on agent readiness treats your structured data as a maintained system rather than a one-time markup task. Our marketing AI practice keeps the facts that agents quote, including hours and prices, aligned with the live business behind them. The standard already exists. The discipline is the deliverable.

• llms.txt is a proposal authored by Jeremy Howard, published 2024-09-03, open for community input, and is a markdown file built to point LLMs at documentation rather than carry typed commerce facts.
• OpeningHoursSpecification is a structured value with typed properties dayOfWeek, opens, closes, validFrom, and validThrough.
• LocalBusiness defines openingHours, openingHoursSpecification, priceRange (categorical text), currenciesAccepted, and paymentAccepted, with no exact-price property at the LocalBusiness level.
• Google recommends JSON-LD and the most specific LocalBusiness sub-type; opens/closes use hh:mm:ss, 24-hour operation is 00:00 to 23:59, priceRange must be under 100 characters, and name and address are the only required properties.
• Google's structured data policies require markup to be a true representation of the page content and prohibit marking up content not visible to readers; violations can trigger manual actions.
• MCP is an open protocol connecting LLM applications to external data and tools via JSON-RPC 2.0, current specification revision 2025-11-25, requiring explicit user consent before invoking tools and treating tool descriptions as untrusted unless from a trusted server.
• Microsoft NLWeb natively supports MCP, reuses schema.org markup, positions itself as to MCP/A2A what HTML is to HTTP, claims schema.org is used by over 100 million websites, and runs each instance as an MCP server with an ask method.
• Google-Extended is a robots.txt product token that controls whether Google may use crawled content to train future Gemini models, governing Gemini Apps, the Vertex AI API for Gemini, and grounding, without affecting Search inclusion or ranking.