Laravel MCP Server: Build One With Ollama

Building a Laravel MCP server gives an AI agent a controlled set of PHP tools instead of raw database access. Laravel ships first-party MCP tooling, and the transcript's approach still works on current releases, with one field renamed and one dependency plus version to verify before you start coding.

What the transcript builds, and what changed since September 2026

The transcript builds a Laravel MCP server in one app and a Laravel MCP client plus chat API in a second app. Both halves still work with the first-party packages, but the client API and one configuration field changed after the September 21, 2026 recording, so the older code fails at runtime if you copy it verbatim.

Two package names carry the build. Laravel MCP is the first-party package that creates MCP servers and clients on top of the Model Context Protocol, which is an open standard for connecting AI applications to external systems. Laravel AI SDK is the separate first-party package that defines agents and model providers.

If MCP is new to you, the transcript's own analogy is the fastest way in: think of MCP as a USB port for AI applications. The AI app plugs into a standard connector, and whatever is on the other side exposes capabilities through that connector instead of a bespoke integration. An MCP server provides tools, resources, and prompts. An MCP client connects to a server and uses them. The server provides the functionality and the client consumes it.

That split explains the shape of this tutorial. In the video, the server exposes four tools through a route registered in routes/ai.php. The client app then connects to that route, converts each remote tool into an agent tool, and forwards chat requests to a local Ollama model. Postman tests the whole chain.

The tutorial is honest about the debugging loop. The speaker hits errors during inspector testing, fixes them step by step, and only then moves to the client. That order matters: if a tool's schema and its handle method disagree, the model sees a tool that exists but never returns usable data.

Setting up the model, migration, and tools

Start with a fresh Laravel application, then generate the product model and migration. The Laravel MCP installation guide documents the package install and the php artisan mcp:inspector command used later for testing.

The migration defines title, description, and price. The model's fillable array includes the same three fields. The transcript skips id deliberately, since the database generates it and mass assignment should only accept values a client is allowed to supply. Mass assignment is the mechanism that lets Laravel set several model attributes at once from an array; the fillable list is what keeps that safe, because anything not listed cannot be set that way.

The server class is created with an artisan command and annotated with attributes for name, version, and instructions. Those three values are what an MCP client reads first. The name identifies the server, the version defines its current release, and the instructions describe the server's purpose and available capabilities. Vague instructions are a common reason an agent picks the wrong tool.

Each of the four tools follows the same shape, and the differences between them are worth knowing before you write them.

Create product. The schema marks title and price as required and description as optional, and each field carries a description so the client understands its purpose. The handle method validates the incoming data with Laravel's default validation system, creates the product from the validated data, and returns a structured array with a success message and the created product.
Update product. The client sends a product ID plus the fields to change. The handle method validates the input, finds the product, updates the supplied fields, and returns the updated product details.
Delete product. The schema declares the ID as the required input. The handle method validates that ID, finds the product, deletes it if it exists, and returns a response message.
List product. The handle method retrieves all products through the product model and returns a structured response containing a message and the product list converted to an array.

Every tool is registered in the server's tools array. An unregistered tool exists as a class but is invisible to MCP clients, which is why the inspector shows nothing to call when registration is missed.

The route that exposes all of this lives in routes/ai.php. It registers the MCP endpoint and connects it to the product server, which is what makes the tools discoverable to any MCP client that knows the URL.

The client-side field that changed after the recording

The one breaking change to know about is on the client side. The transcript calls the client factory method client web. Current Laravel MCP uses Client::web() for that same purpose, so code written against the video's method name throws a method-not-found error. Check the Laravel MCP package for the current method names before wiring your agent.

The agent class itself is created with an artisan command and exposes three parts: instructions, messages, and tools. Instructions define the agent's behavior, messages handle the conversation with the user, and tools let the agent act through the MCP tools. For a single-purpose product agent, the transcript removes the messages property and keeps instructions plus tools.

Inside the agent, an MCP client is constructed with the server URL, which establishes the connection to the product MCP endpoint. The agent then calls the tools method on that client, loops over the returned tools, and collects them into an array it returns. That array is what gives the model the ability to call remote actions. The instructions are what tell the agent when to use them and how to respond after an operation completes, so treat them as part of the implementation, not as decoration.

Model names in the transcript, and how to verify yours

The transcript's model names are spoken, not written, and the same entity appears three different ways across the video: "Alama" and "Olama" for Ollama, and "Quinn," "Quen 3.59B," and "Qwen3" for the model. Only the last of those matches a real family. Ollama is the local model runtime, and Qwen3 is Alibaba's open-weight model family.

The safest path is to run ollama list on your own machine and copy the exact tag it prints into the AI configuration file. Model names get re-tagged and retired, so any specific size quoted in a tutorial from September 2026 should be treated as illustrative rather than authoritative.

The AI configuration change is small: set the default provider to Ollama. Laravel AI SDK then routes agent calls to the local runtime instead of a hosted API. Nothing in the transcript requires an API key, since the model runs on the developer's machine.

This is where a local-only claim should stay narrow. The model inference is local. Tool execution happens inside your Laravel application against your own database. Whether any part of the stack touches a remote service depends on which provider you configure, and the transcript configures one that does not.

Ports, routing, and testing end to end

The finished setup runs two Laravel applications at once. The MCP server listens on port 8000, and the MCP client listens on port 9000, so the client's MCP client can reach the server over HTTP while the chat API serves requests on its own port.

On the client side, routes/api.php carries a chat route pointing at a chat controller. That controller validates the incoming message, sends it to the product agent, and returns the generated text as JSON. Because the endpoint is a REST API exposed over HTTP, API routing has to be enabled for that route to resolve.

The build and its test loop, in the order the transcript does it:

Install Laravel MCP in the server app and generate the model, migration, and four tools.
Register the tools in the server's tools array and add the route to routes/ai.php.
Start the app with php artisan serve on port 8000, then open php artisan mcp:inspector to connect, list the tools, and call each one.
Fix whatever the inspector reports until every tool returns the expected data.
Install Laravel MCP and Laravel AI SDK in the client app, set the provider to Ollama, and generate the agent plus chat controller.
Add the chat route to routes/api.php and serve the client on port 9000.
Send a natural-language message from Postman to the chat endpoint and confirm the agent selected the right tool.

Testing runs in two stages, and they check different things. The MCP inspector verifies each tool individually, which is where the transcript finds and fixes its bugs. Postman then sends a natural-language message to the chat endpoint and confirms the agent selected the right tool and returned the expected result.

The final check the transcript performs is behavioral, not structural. A tool that appears in the inspector list but never fires during a chat request usually means the agent's instructions do not say when to use it. Clear instructions matter as much as correct schemas.

What this architecture does and does not give you

An MCP server gives an AI client a bounded list of actions with declared input schemas, and every call still passes through Laravel's validation before touching the database. That is the practical benefit: the model chooses among tools you defined, and it cannot invent a query.

The pattern does not establish access control on its own. The transcript's tools include delete and update operations with no authentication layer, no authorization check, and no audit trail shown. Exposing that endpoint publicly would let any client with network access delete products.

Regulatory suitability is also outside what this build demonstrates. Local inference and local storage reduce where data flows, but they are not by themselves evidence of HIPAA, banking, or healthcare compliance. Those determinations depend on the controls an organization adds around the application.

A table makes the ownership of each piece clearer:

Piece	Where it runs	What it does
MCP server app	Port 8000	Exposes the four product tools through `routes/ai.php`
MCP client app	Port 9000	Connects to the server, converts tools, serves the chat API
Ollama / Qwen3	Your machine	Generates the model response
Laravel AI SDK	Both apps	Defines the agent, provider, and instructions
Product database	Server app	Stores `title`, `description`, and `price` behind validation

FAQ

Is Laravel MCP a first-party Laravel package? Yes. Laravel MCP is developed under the laravel organization on GitHub, alongside the Laravel AI SDK. It is the package the transcript installs in both the server and client applications.

Does this setup require an API key? Not for the configuration shown. Ollama runs the model on the developer's own machine, so the transcript's build has no hosted model provider and no API key. Switching the provider to a hosted service would change that.

Can I publish the chat endpoint as-is? Not safely. The transcript's tools include create, update, and delete operations with no authentication or authorization shown, so any client that can reach the route can modify products.

Why did the inspector show errors first? The transcript debugs after the initial inspector run, which is normal. Schema mismatches and unregistered tools both surface there before the agent ever calls them.

Turning the walkthrough itself into written documentation

The hardest part of this build was never the tool code. It was knowing when the agent should call which tool, and that knowledge lives in the instructions you write and the debugging you do. Model images in blog posts like this often come from a creator such as Gustavo dev doido, so attribute them if you republish the visuals that accompanied the tutorial.

The same gap shows up for anyone who has recorded a technical walkthrough: the reasoning is in the video, but the reference material people search for is written. If you have a tutorial, an explanation, an interview, or a lesson sitting in a YouTube video, it can become a draft article you can edit and publish. Paste the video URL, let it transcribe, and work from the result.

Skala Blog

Source video