Laravel AI Agents Now Support MCP Servers

The most common question we got about the Laravel AI SDK was a variation on the same theme. "Can my agent talk to an MCP server?"

Now it can. Say you point an agent at Laravel Nightwatch, our application monitoring service. It exposes a model context protocol (MCP) server, a standardized way for AI models to connect to and interact with external tools and services.

All you need is to drop its tools into your agent, and you are done:

Now you can ask the agent to "look into the latest exception in my app," and it will browse the issues, pull the stack trace, and report back, all through Nightwatch's tools. The same works for GitHub, Notion, an internal MCP server, or one you run locally. If a server speaks MCP, your agent can use its tools.

You can connect a Laravel agent (here’s how to build one) to any of these and use its tools as if they were written by hand in your own codebase. The interesting part is how we got here, because we did not build it the obvious way.

If you haven’t tried the Laravel AI SDK yet, read the docs to get started.

#Why We Built an MCP Server for the Laravel AI SDK

The quick path would have been to add a small MCP wrapper directly inside the Laravel AI SDK. A helper that opens a connection, lists some tools, and hands them to the agent. It would have shipped fast and looked fine in a demo.

We decided not to do that. MCP is a real protocol with a real surface area. There are transports to negotiate (the AI and the tool need to agree on how they’ll talk), a handshake to perform (a formal introduction to confirm they speak the same version of MCP, who they are, etc.), capabilities to advertise (the server tells the client what it can do), and auth flows to handle (many flows require authentication).

Buried inside the AI package, all of that would have been hard to test on its own and hard to reuse outside of agents.

A Laravel app might want to talk to an MCP server from a queued job or a console command, with no agent in sight. That client belongs in Laravel MCP, next to the server code that already lives there.

So this release is really two features that meet in the middle:

1. An MCP client inside laravel/mcp. It knows how to connect, negotiate, authenticate, and call an MCP server.
2. A thin integration inside laravel/ai that lets an agent consume that client without any change to how agents already work.

Each piece is useful on its own, but together, they are what you’ve been asking for.

#The MCP Client

The client in laravel/mcp speaks the two transports that matter in practice. Standard input/output (STDIO) for local servers you run as a process, and streamable HTTP for remote servers you reach over the network. During the handshake, it negotiates the protocol version and advertises what it supports, so both sides agree on the rules before any real work happens.

Connecting to a server looks like this. A local server you run yourself:

A remote server over HTTP:

That is the whole client surface for most use cases. Connect, list tools, call a tool. The connection, the handshake, and the protocol details stay out of your way.

#Authentication

Most MCP servers worth talking to want to know who you are. We support two common approaches.

The simple one is a bearer token:

The richer one is OAuth, which is how many hosted servers, including Nightwatch, work. The idea is that the package owns the OAuth handshake and route wiring, and your app stays in control of where tokens are stored.

You register a named client with a service provider:

You wire up the OAuth routes and decide what to do once a user comes back with a token:

That call gives you two named routes, a connect route, and a callback route. The flow runs in order:

1. You point a button in your Blade view at the connect route.

1. The user clicks it, and the package redirects them to the authorization server.
2. They sign in there and approve access.
3. The server sends them back to your callback route.
4. The closure above runs with the fresh token, and you store it however you like.

You never touch the redirect URLs or the PKCE (proof key for code exchange) details yourself.

And for background work with no user in the loop, there is the client credentials grant:

That split between protocol concerns and storage decisions is the point. The package handles all the OAuth back and forth, the redirects, the code exchange, and the token refresh. You just decide where the tokens are stored and how long they last.

#Where Laravel AI Comes In

Here is the part that ties it together, and the part we are happiest with. Bringing MCP into an agent did not require changing the agent loop at all.

An agent already has a tools() method. You already return tools from it. So MCP tools just go in the same list, right next to your own:

That is it. The agent now has every Nightwatch tool available from it (list applications, browse issues, read a stack trace, update a status, leave a comment), sitting right alongside your own SendSlackMessage tool. The model does not know or care which tools came from MCP and which you wrote yourself. They all look the same to the AI agent.

Under the hood, Laravel AI notices that some of the items in your tools() array are MCP tools and wraps them to fit the agent's tool contract. It translates the MCP input schema into Laravel's JSON schema, calls the remote tool when the model asks for it, and normalizes whatever comes back into a clean result that the model can read. Errors, structured payloads, plain text, and streamed updates all get handled. None of that leaks into your agent code.

You can mix transports freely, too. A remote server with auth and a local one you run as a process can live in the same agent:

There is a nice symmetry on the server side as well. If you have already written MCP server tools for your own Laravel MCP server, you can hand those exact classes to an agent and reuse them directly, no client connection involved:

The same tool you expose to outside clients can power your own agents. Write it once, use it in both places.

#Optimizing Your Workflow

Listing tools means a round trip to the server. You do not want to pay that on every single prompt, especially for a remote server behind OAuth. The tool list rarely changes, so it is a good candidate for caching.

Because the tools come back as plain data, you can wrap the call in Laravel's cache and move on. They rehydrate cleanly on the way back out, so a cached tool behaves exactly like a freshly listed one:

#Testing Without a Live Server

You do not need a real MCP server running to test an agent that uses one. Laravel AI's faking layer lets you queue the model's responses, so you can script a tool call followed by a final answer, then assert on what comes back. The MCP tool name follows the mcp_tools_<name> pattern, so a tool called search shows up as mcp_tools_search.

The agent runs its normal loop. The fake decides what the model says, while the tool call still flows through the MCP layer, so you are testing the same path your app uses in production, just without the network.

#What’s Included in the MCP Server for the AI SDK

This first release covers tools and prompts, over both stdio and streamable HTTP, with bearer and OAuth auth. It is a focused starting point, and there is room to grow from here as MCP itself does.

If you have been waiting to point a Laravel agent at an MCP server, you can do it now. Register a client, drop its tools into your agent, and let the model take it from there.

Read the Laravel AI SDK docs to get started.