What does Yonatan Gross do?

Yonatan is an AI Platform Engineer & Backend Developer who designs and operates production AI systems solo — RAG pipelines, multi-agent architectures, MCP servers, and the infrastructure that runs them. He built a WhatsApp AI platform and created OrchestKit, an open-source Claude Code agent framework (111 skills, 37 agents, 211 hooks).

How can I reach Yonatan?

Book a free 15-minute intro call at https://cal.com/yonatan-hq, or email yonaigross@gmail.com.

Can an AI agent use the chat API on this site?

Yes. POST to https://yonyon.ai/api/chat with JSON body {"messages":[{"role":"user","content":"..."}]} (up to 20 messages, each up to 2000 chars). Public, no auth, rate-limited to 10 requests per IP per minute, backed by the claude-haiku-4-5 model, streaming a text/plain response. See also https://yonyon.ai/llms.txt and https://yonyon.ai/.well-known/agent-skills/index.json.

How much does it cost to work with Yonatan, and how do I get a quote?

Engagements are scoped per project, so there is no fixed price list — quotes depend on what you are building. The fastest path to a quote is to book a free 15-minute intro call at https://cal.com/yonatan-hq, describe the work, and get a scoped proposal. You can also email yonaigross@gmail.com.

Why choose Yonatan over an agency or a freelance marketplace?

You work directly with the engineer who designs, builds, and operates the system — no account managers, no hand-offs, no junior bench. Yonatan ships production AI end-to-end (RAG, multi-agent, MCP servers, and the infrastructure they run on) as a single accountable point of contact, and has done so in production (a WhatsApp AI platform) and in the open (OrchestKit). For teams that want senior, hands-on ownership rather than a staffing layer, that directness is the difference.

MCP Servers: The Missing Piece in AI Tooling

The Model Context Protocol gets described as "USB-C for AI" so often that the phrase has stopped meaning anything. Here is something concrete instead. yonyon.ai, the site you are reading, runs a production MCP server at /api/mcp, and I have built MCP servers into real products. This is what the protocol actually buys you and where the sharp edges are.

What MCP standardizes

The missing piece is a standard contract between a model and its tools, so neither side has to know how the other is built. Before MCP, every time you wanted a model to use a tool you wrote a bespoke integration: a function schema in one place, a dispatcher in another, a transport you invented. Do that for five tools across three apps and you have fifteen slightly different glue layers. MCP standardizes the contract between a model and a set of tools so the model side and the tool side can evolve independently. A tool is a name, a typed input schema, and a handler. The model gets the schema, never your code.

The anatomy of a server

An MCP server is small. It declares a set of tools (and optionally resources and prompts), speaks the protocol over a transport, and runs your handlers when the model asks. The handler is ordinary code: query a database, hit an API, run a calculation. The protocol carries the request and the typed result. That separation is the whole point. Your business logic does not know it is being driven by a model.

Tool definitions are the API surface

The tool definition is where care pays off. A good description and a tight input schema do more for tool-selection accuracy than any prompt engineering on the model side. Keep the schema typed and narrow, validate inputs at the boundary, and write the description for a reader who cannot see your code, because the model cannot. On this site the tool inputs are typed in TypeScript, so the schema the model sees and the handler signature stay in lockstep. An agent with many loosely-described tools picks the wrong one more often; cut the set down to a few precise ones and selection gets sharper.

Transports and where they fit

MCP runs over stdio for local processes and over HTTP for remote servers. Local stdio is the right default for a developer tool that lives next to the agent. Remote HTTP is what you want when the server is a shared service, which is the case for a site like this one: the same /api/mcp endpoint serves any agent, scope-gated, rate-limited, behind the same edge as the rest of the site. An MCP client like Claude Code points at that endpoint and gets the tool list without any per-tool wiring.

WebMCP and discovery

The newer move is WebMCP: exposing a site's capabilities to agents directly from the page, so an assistant browsing the site can call its tools without a separate integration. Paired with discovery surfaces (a well-known catalog, an llms.txt, typed JSON-LD), it means an agent can arrive cold, learn what the site can do, and use it. Discoverability is not decoration here; it is the difference between a tool an agent can find and one it cannot.

MCP inside the product

The mistake I see is treating MCP as a demo layer bolted on the side. The version that holds up reuses the service layer the rest of the product already has. The MCP tools on this site call the same functions the UI calls, behind the same auth and rate limits. That is why the server is small: it is a thin, typed, scope-gated front door onto code that already exists, not a parallel universe you have to keep in sync.

This is not theoretical for me. My platform ships its own MCP servers as packages in a monorepo, around ten of them, spanning knowledge, content, channels, commerce, calendar, media, and ops. The operations agents that run the platform bind directly to those servers instead of re-implementing each integration, which is the same pattern at a larger scale: one typed, scope-gated seam per domain, onto code that already runs. That is the whole value of MCP: a standard seam that lets the model side and the tool side ship on their own clocks.