Every few months the industry rediscovers that LLMs are more useful when they can do things: query a database, open a ticket, fetch a document. Then the question returns: do you speak a standard protocol like Model Context Protocol (MCP), or do you wire custom tools into your own stack?
We care about this because Rayaxis ships practical AI inside real products — Laravel APIs, React UIs, Python workers — not demos that die in a slide deck. Protocol choice is a product decision dressed as infrastructure.
What MCP is buying you
MCP standardizes how hosts (IDEs, agent runtimes) discover and call tools. One server can expose resources and tools; multiple clients can reuse them. That is genuinely valuable when:
- Several agent UIs need the same capabilities (local CLI, cloud agent, internal ops console)
- Tool definitions change often and you do not want to re-embed schemas in every app
- You want a clean boundary between "model host" and "side-effectful code"
For studio workflows — drafting blog posts, inspecting repo state, talking to Supabase with a service role — a shared MCP-shaped surface can reduce glue code across agents.
What custom tooling is buying you
Custom tools (provider function calling, your own JSON schemas, a thin Python or Laravel service) buy you proximity:
- One hop. The model calls your API; your API talks to Postgres. No extra process to start, auth, and keep warm.
- Domain-shaped errors. You return the exact validation messages your Form Request already knows.
- Auth that matches the product. Sanctum sessions, API tokens, and row-level rules stay in the same place the rest of the app trusts.
- Latency you can budget. A customer-facing "summarize this invoice" button cannot afford a cold MCP server plus a round trip through an IDE-oriented transport.
When we add AI to a client portal, custom tools almost always win the first version. The model needs three verbs: fetch record, draft reply, create draft note. Those verbs already exist as Laravel actions. Wrapping them in a protocol layer before the product has users is premature abstraction.
The latency question, without mysticism
Latency is not only network milliseconds. It is:
- Process startup (stdio MCP servers spun per session)
- Schema negotiation and tool list refresh
- Serialization across an extra boundary
- Human time debugging "which server has the stale tool definition"
In an IDE agent loop, that cost is often acceptable. In a React modal waiting on a Python worker, it is not. Measure the path the user waits on, not the path that looks elegant in a diagram.
A useful rule of thumb we use internally:
- Operator / developer agents → lean toward MCP or another shared protocol
- End-user product features → lean toward custom tools colocated with the domain
- Both → keep domain logic in one library; expose MCP and HTTP adapters, do not duplicate business rules
Auth and blast radius
Standard protocols encourage powerful tools. Powerful tools need boring security.
MCP servers that can run SQL or touch production secrets should never be the same process you casually plug into a marketing demo. Same lesson as giving an agent a service-role key: scope hard, log harder, prefer read-only tools until a human approves writes.
For client apps we prefer:
- Tools that call the same policies as the human UI
- Explicit allow-lists of models and tools per environment
- No "god tool" that shells out with the deploy user's privileges
Protocol vs. custom does not change that. It only changes where the allow-list lives.
A practical decision matrix
| Situation | Lean | | --- | --- | | Internal coding agents sharing repo + docs tools | MCP / shared servers | | Laravel portal with three AI actions | Custom function tools | | Python RAG helper used by one Next.js route | Custom; extract later if a second host appears | | Multiple products need the same CMS search tool | MCP or a small internal tools API | | Latency budget under ~1s user-visible | Custom, keep hot path short |
What we actually do
We are not religious. MCP is worth the overhead when portability is the product. Custom tooling is worth the maintenance when the product is the latency and the auth model.
For Rayaxis client work, most AI features start custom: a Laravel (or Python) endpoint, structured outputs, a React UI that shows drafts before anything commits. If a second agent host needs the same capabilities, we extract an adapter — sometimes MCP, sometimes a plain internal API — around the same domain functions.
Standardized agent protocols are real progress. They are not free. Pay the latency and operational tax when many hosts need one toolbox. Skip the tax when one product needs three sharp tools.