Why we're building Kuaray Oka
Static sites tell humans what you do. They tell agents nothing. So we're building Kuaray Oka.
Why we're building Kuaray Oka
Someone opens Claude and says "book me a haircut tomorrow afternoon near the office." Claude looks. The salon has a website, a Google Business listing, a calendar, a WhatsApp number. None of it is callable from an agent's perspective, so Claude does what every agent does today: hands the user a phone number and hopes for the best. Kuaray Oka is what we're building to fix that.
Quick context
MCP is about eighteen months old. In that window it's gone from an Anthropic proposal to the way frontier models actually talk to tools in production: Claude, ChatGPT, Gemini, the open-source agentic stacks, all of them ship MCP support. We wrote about that maturation back in March in MCP Is the TCP/IP of Agentic AI. The takeaway hasn't changed. If you're building anything where an agent does more than chat, MCP isn't optional anymore.
The economics that made it stick were obvious in enterprise. MCP solved the M×N integration problem: write one server per system, consume it from any compatible agent. That's why most of the obvious enterprise SaaS surfaces shipped MCP servers over the past year.
There's one layer where the calculus still falls apart, though: the long tail of bookable businesses. The clinic. The salon. The local accountant, the family restaurant, the yoga studio. They're not going to hire an engineer to build, host, version, monitor and rate-limit an MCP server, and they're exactly the businesses an agent on a user's behalf most often needs to talk to.
What an agent needs that a human doesn't
If a chunk of your traffic is already coming from agents (and on the trend lines, it is), then your website needs to do four things it never had to do before:
- A typed inventory of what you actually sell. Services, durations, prices, availability rules. Not marketing copy.
- An executable surface.
check_availability,quote,book,cancelas real tools with structured inputs and outputs. Not a contact form. - Identity and payment primitives the agent can hand off to without leaking credentials or PII into the model's context window.
- A versioned contract that doesn't shift every time someone redesigns the site.
A normal landing page does none of these. Neither do the popular site builders. Anyone who wants this has to build it themselves.
Why plugin stores aren't enough
A reasonable objection here: don't agent vendors already solve this with plugin stores?
They do, partly. But the model where each business builds its own ChatGPT app, Claude integration, Gemini extension, Perplexity action and WhatsApp agent isn't going to scale to a salon. MCP is what changes the math: one server, every MCP-compatible agent.
Except "one MCP server" is still one MCP server too many for most of these businesses. The runtime. The schema. The auth flow. The calendar wiring, rate-limiting, observability. None of that is in scope for a four-person clinic. The right shape for this layer isn't an MCP server you sell. It's a product that ships one as a byproduct of the things the business already buys: a landing page, a calendar, a phone number.
What Oka does
The product is three things glued together by one source of truth:
- One business definition produces both the human page and the agent-facing MCP server. You write down what you offer, your availability rules, your pricing, your booking policy. We render a marketing page for humans and a typed
.well-known/mcp.jsonfor agents. They can't drift apart because they're projections of the same source. - Real-world side effects are wired in. Two-way calendar sync, Stripe for deposits, WhatsApp Business as a first-class inbound channel, OAuth for the major CRMs on the roadmap. The agent itself never touches money or PII. It calls scoped tools that do.
- Every tool call is logged.
check_availability,book, the lot. Each event carries the agent identity, a tool-call ID, and a result. For the business owner, that's how you finally know which agents are actually bringing in customers.
The product page walks through the architecture in more depth. The verticals we're designing for in private beta are clinics, restaurants, professional services, and local SMBs.
Design positions worth taking
These aren't unique to Oka. They're the constraints we think separate the MCP integrations that survive real production traffic from the ones that quietly break.
Treat the MCP manifest like an API contract, not a config file. Version it. Diff it on every deploy. Reject schema-breaking changes the same way you'd reject a breaking REST change. Most "flaky LLM" failures in production are actually contract drift.
Don't put business logic in the model. Availability arithmetic, pricing rules, time-zone math, deposit policy. These are deterministic problems with well-understood solutions, and they belong in tools the agent calls. The "let the model figure it out" path produces compounding correctness bugs and an audit trail nobody wants to inherit.
Instrument tool calls from day one. Per-tool latency, per-agent success rates, per-tenant call volumes. You'll need this to price, to debug, and to convince any enterprise buyer there's actually a paper trail behind the protocol.
Project, don't translate. If your data model has to be converted between human-page content and machine tools, you've already lost. Build one source of truth and render it both ways.
Why this matters beyond Oka
The shape Oka takes is the same shape we think a lot of B2B and B2C software ends up converging on as the agentic share of traffic grows: operations exposed as typed, agent-callable surfaces, generated from one source of truth, instrumented end-to-end. Oka is that pattern right-sized for SMBs. The underlying ideas are the same ones we apply at larger scale.
If you're an engineering leader thinking about how your product should be addressable to agents, or you run a small business and you're not sure whether you need to do anything about this: yes, sooner than you think. We're happy to talk through what "ready" looks like.
Talk to Kuaray about an MCP-native architecture review. If you run a bookable business and want to see Oka in action, request early access.