Commercial and Entity Discovery

An agent needs to establish what you sell, who operates it, when it fits a task, and what it costs. These facts should agree across visible pages, structured data, Markdown, repositories, and listings.

Pricing and task guidance

Publish /pricing.md when prices or plans affect a buying decision. Include currency, billing unit, taxes and shipping treatment, minimum quantities, regional restrictions, included usage, overages, renewal/cancellation terms, and a date or canonical source. For variable catalog pricing, link to current product offers rather than inventing one universal price. State “quote required” when that is the real contract.

Maintain the Markdown representation from the same source as the visible price. Check an actual product or plan against both representations and the purchase flow. A readable pricing file that is stale is worse than a clear link to authoritative live pricing. Use this representation when it helps a supported client retrieve pricing; retain the same authoritative terms across representations.

For llms.txt, split large product families into section-level indexes only when that improves retrieval. Link those indexes from the root; use descriptive Markdown links, stable URLs, and a concise “when to use” summary with limitations. Verify every link, media type, canonical redirect, and relevant regional variant. See llms.txt and content negotiation.

Product-page structured data for shopping agents

Product and Offer structured data, merchant feeds, and catalog APIs for shopping agents now live in Product Data for Shopping Agents, part of the Agentic Commerce section. This page covers organisation and entity identity; see that section for anything a shopping agent reads before or during checkout.

Keep the purchase surface itself discoverable: a stable /pricing page (see above) and Offer data that points at the actual buy page, not a marketing page. The payment link relation (rel="payment") is registered in the IANA link relations registry under RFC 8288 as "a resource where payment is accepted." It predates agentic commerce, is not required by UCP, AP2, ACP, or x402 (see Payments), and sees little real-world use - treat it as an optional, documented signal rather than something to implement for agent readiness.

Entity identity and independent coverage

Use stable Organization identifiers and JSON-LD. Add sameAs only for pages representing the same entity; a press article mentioning a company is not necessarily an equivalent identity. Keep names, official URLs, real contact details, and ownership consistent. Publish useful About, Contact, and Privacy pages; do not add fictional addresses, ratings, or testimonials to broaden schema coverage.

Status page and agent terms of use

Two more trust signals have no formal spec behind them but real practical value once an agent starts operating unattended.

A public status page (a dedicated /status path or a third-party status service) tells an agent whether an API failure is your problem or theirs before it decides to retry, back off, or give up. Link it from your API Catalog entry and from error responses where practical, not just from a marketing footer.

Agent terms of use - a published policy stating what automated or agentic use of the product is actually permitted (which endpoints may be called unattended, whether scraping the marketing site is fine but reselling scraped data isn't, what counts as abuse) - has no IETF or W3C standard behind it. It's a legal-practice recommendation, not a spec-backed check. Publish it as its own page (not buried inside general Terms of Service) and link it from llms.txt and your API docs so an agent - or the person operating it - can find the actual rules instead of guessing from robots.txt alone, which only ever states a crawl preference, not a usage licence.

Wikipedia requires significant independent, reliable coverage for organizations. Wikidata has separate eligibility rules; a Wikipedia article is not its only possible qualification. Check both policies before drafting. If an eligible Wikidata entity exists, verify it is the right entity and use P856 for its official website. Do not create duplicates or promotional articles for score improvement. Sources: Wikipedia organization notability, Wikidata notability, P856.

Search visibility and distribution

Measure brand-name results separately from category or use-case results. Record exact queries, language, region, date, engine, returned URLs, and mistaken identity. Repeat a fixed query set before comparing changes. Citation share and ranking are observations, not guaranteed consequences of markup or directory membership.

When you distribute an SDK, skill, plugin, MCP server, or ChatGPT app, verify the official listing, publisher, installation instructions, and working artifact. Link it from your domain and confirm the listing links back. Use the platform's actual manifest and submission rules. A repository with a file named plugin.json does not establish compatibility with every agent platform. A storefront need not publish a coding repository or become a ChatGPT app to serve ordinary customers.

For a retail task, verify price visibility, product identity, availability, delivery restrictions, return terms, and the transition to cart or checkout. For a service integration, verify quotas, billing units, supported operations, and credential requirements. Choose distribution channels and payment integrations according to those tasks and their intended clients.

Agent plugins and official packages

Package related skills and MCP connections as a plugin only for supported hosts. The Agent Plugins specification describes its manifest and packaging contract; other platforms can have different requirements. Validate the declared schema, resolve every referenced artifact, and perform an installation in the intended host. Keep publisher identity, permissions, configuration, and update behavior explicit.

For SDKs, select the language ecosystems your customers use. Check the published package's homepage and repository links, installation command, supported API version, authentication example, and error behavior. Generating a package from a schema is a starting point; execute a representative operation from the distributed artifact before calling it supported.

Directory and registry listings

Agents that discover a product or tool through a registry expect the same identity and freshness checks as any other listing.

Keep display name, icon, and description current on every listing; an entry that predates a rename or carries a dead icon reads as abandoned. Ora's catalog checks these as mcp-registry-listed (which also credits entries on community registries such as Smithery and mcp.so), skills-sh-listed, chatgpt-app-listed, and registry-branding; see Ora's checks catalog.

Revalidate before commitment

Search indexes, feeds, and cached representations can lag behind the source. Include provenance and meaningful update times where supported. Recheck volatile facts such as stock, price, delivery eligibility, and quotas before an operation commits the user. If they have changed, return the updated terms for review rather than silently substituting another offer.

A useful test follows one resource through search, detail, selection, and confirmation. Retain its stable identifier, compare the source facts at each step, and verify that the final record reflects the choice the user authorized. See Evaluating Product Journeys.