One set of prices, wherever you ask.
A website can describe one offer while an AI assistant reads an older one. I have had to solve that problem in byImprint’s own system. The important design choice is where the facts come from.
Several ways to read the same business.
People can read byImprint’s pricing page in a browser. Software can read a Markdown version or use the public MCP interface, which gives an assistant structured access to a small set of tools. Each route needs to describe the same current offer.
Maintaining separate copies makes drift easy: a price changes on the page and an old figure survives elsewhere. I keep the public pricing rows in shared content and use those rows in the browser page, the Markdown renderer and the guidance returned by the public tool.
The small system behind it.
The public interface is deliberately narrow. It explains when byImprint might fit and provides public routes. The working pieces are:
- Shared offer
- The current service names, starting prices and scope notes used by the website.
- Human page
- Readable pricing and scope, with the same terms a person sees before getting in touch.
- Machine reading
- Markdown and a public MCP tool response, using the shared pricing content.
- Comparison
- Check the rendered responses against the offer, including scope limits and currency.
The test is the returned answer.
A file in the repository does not show what an assistant receives. I inspect the browser pricing page, request its Markdown representation and call the public tool. I check the actual returned service names and amounts, and whether the scope language survives.
For this note, the check covers the three current ways to work together: a focused project from CA$2,500, an ongoing partnership from CA$3,000 per month and optional focused discovery at CA$750. These are starting points and scoped services; the pricing page carries the full terms.
Useful access has a boundary.
The public tools read public information. They cannot send messages, change an account, spend money or retrieve client records. That boundary is part of the product: a person can use an assistant to understand byImprint without granting it authority to act for the business.
For an internal business assistant, the same questions become more specific: which information may it read, where does the answer come from, and which actions still need a person? Those decisions belong in the working design.
What this demonstrates.
This is an example from byImprint’s own public website and AI interface. The September 2026 implementation checks the pricing information across the affected local responses. It demonstrates a shared-content approach and a bounded read-only tool.
It does not guarantee that an external assistant will retrieve, quote or recommend byImprint. Clear source material and working access make the information available; they do not control somebody else’s answer.
