Laravel Restify: One Repository Definition, JSON:API and MCP Outputs
Laravel API for Ai Agents and humans.
At a glance
- What is it?
- Laravel Restify generates JSON:API endpoints and MCP tool definitions from a single Eloquent-backed repository class. The pitch is one codebase serving humans and AI agents under the same policies. The catch is that MCP support depends on an external Laravel package and on you accepting generated tool schemas you do not hand-write.
- Who is it for?
- Adopt Laravel Restify if you already run Laravel, want JSON:API compliance without writing serializers, and have a concrete reason to expose the same models to an MCP client. Do not adopt it if you need plain REST conventions, if you cannot add laravel/mcp to your dependency tree, or if you are unwilling to review generated tool schemas before an agent can call them.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 44 days ago.
- What is it written in?
- Mainly PHP, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The duplication problem Restify targets
A Laravel application that serves both a frontend and an AI agent usually ends up with two descriptions of the same resource. The HTTP controller validates a title as required and at most 255 characters. The tool schema handed to a model describes the same field in prose, and the two drift the moment someone edits one and forgets the other. Authorization is worse: a policy check that guards a route is easy to forget on a second surface that reaches the same Eloquent model.
Restify's answer is to make the repository the single place where fields, validation rules, and matchable filters are declared, then derive both surfaces from it. The README frames this as "One Codebase. REST for Humans, MCP for AI Agents." The audience is Laravel teams that already have a policy layer and want an agent-facing interface without maintaining a parallel schema. It is not aimed at teams who want a thin router over Eloquent, and it is not a general MCP framework. The MCP side exists because the models and repositories already exist.
What a repository class actually declares
The unit of configuration is a class extending Binaryk\LaravelRestify\Repositories\Repository, tied to a model through the #[Model(Post::class)] attribute. Inside, a fields() method returns an array built from helper functions: field(), textarea(), datetime(). Each helper accepts chained calls such as rules('required', 'string', 'max:255'), nullable(), readonly(), and matchable().
That array is the whole contract. The README states that this single definition provides JSON:API CRUD endpoints with validation, MCP tools with the same validation, authorization policies applied to both interfaces, and search and filtering for all consumers. The field helpers are doing double duty: rules() feeds Laravel's validator on the HTTP path, and the same field list is what the MCP tool generator turns into an inputSchema. A field marked matchable() becomes a filterable parameter. In the README's generated example, title is described as accepting an exact match and negation with -title=value, and published_at appears as a date filter. Those descriptions are produced from the field declaration, not written by hand.
This is the design decision worth pausing on. You are not authoring an OpenAPI document or a tool manifest. You are authoring a PHP array, and the package decides how that array reads to a model. When a generated description is ambiguous, your only lever is the field definition itself.
Two endpoints from one class: JSON:API and MCP
On the human side the routes are conventional and namespaced under /api/restify: GET, POST, PUT and DELETE on /api/restify/posts and /api/restify/posts/1. Responses follow JSON:API, so a list response carries data with id, type and attributes, plus a links object with self and next for pagination. The README claims full JSON:API specification compliance. Treat that as the package's stated goal rather than a verified property; spec compliance is the kind of claim you confirm against the documentation and your own payloads, not from a README bullet.
On the agent side, MCP registration happens through Laravel's MCP facade. You add a block to config/ai.php that calls Mcp::web('restify', RestifyServer::class), attaches the auth:sanctum middleware, and names the route mcp.restify. The README then shows GET /mcp/restify returning a tools array. Each tool carries a name such as posts-index-tool, a natural-language description, and an inputSchema with properties for page, perPage, search, sort, and the matchable fields.
The data flow is therefore one-directional and generated: repository fields in, two serializations out. Nothing in the supplied material describes a bidirectional sync or a way to hand-edit the generated schema independently, so if the generated description is wrong your fix belongs in the repository class.
Install and wire-up commands
Installation is a single Composer require: composer require binaryk/laravel-restify. Setup runs php artisan restify:setup, which the README presents as the step that prepares the package. The README does not enumerate the files that command writes, so check the diff in your application before committing it.
Scaffolding a repository is one Artisan call: php artisan restify:repository PostRepository --all. The --all flag is shown in the quick start without an explanation of what it includes, which is a gap in the README worth resolving against the documentation site before you rely on it.
MCP is opt-in and separate. In config/ai.php you import Binaryk\LaravelRestify\MCP\RestifyServer and Laravel\Mcp\Facades\Mcp, then register Mcp::web('restify', RestifyServer::class)->middleware(['auth:sanctum'])->name('mcp.restify'). Two details follow from that snippet. The MCP surface is guarded by Sanctum, not by a separate token system, so an agent authenticates the way a first-party client would. And the namespace Binaryk\LaravelRestify\MCP, plus the Laravel\Mcp facade, indicate that the MCP transport comes from a Laravel package rather than from Restify itself. The README does not state that dependency explicitly, so confirm it in your composer.json after install.
The README also documents composer test for running the suite and points to a separate development companion, binarcode/laravel-restify-boost, installed with composer require --dev binarcode/laravel-restify-boost. That package is described as giving AI agents documentation access and repository generation assistance. It is a development tool, not part of the runtime API.
Where the single-definition model strains
The generated tool schema is the weakest point to inspect. In the README's own example, the inputSchema for posts-index-tool lists page, perPage, search, sort, title and published_at. There is no visible mechanism in the supplied material for constraining an agent's perPage to a sane maximum, or for expressing that a filter combination is unsupported. Validation runs on the HTTP path through Laravel's validator, but the README does not show a tool-level guard that stops an agent from issuing a wide query before the request reaches the controller. If your models are large, that is a cost you absorb at the database, not at the schema.
Authorization is the second thing to test rather than assume. The README states that Laravel policies protect both interfaces, and that is exactly the claim to verify with a failing case: create a policy that denies a user, then attempt the same operation through the MCP route. The two paths share a middleware stack in the README's configuration, which is a good sign, but shared middleware is not the same as a proven policy evaluation on the tool path.
The third strain is conceptual. JSON:API is a strict format with opinions about relationships, sparse fieldsets and error objects. If your consumers expect flat REST responses, Restify's human-facing output will look over-structured, and you will spend time explaining links and type members to frontend developers who wanted a bare array. Restify is the wrong tool when the human API is the only API.
How this differs from writing routes yourself
The obvious alternative for a Laravel team is hand-written routes and controllers, optionally with an MCP server defined separately. The difference is not effort on day one; it is where the duplication lives. With hand-written routes you own the request classes, the resources, the policy wiring, and the tool manifest, and each is edited on its own schedule. Restify collapses the field list into one array and regenerates both surfaces from it.
That trade cuts both ways. Hand-written controllers let you shape each endpoint precisely, return whatever payload fits, and keep validation and tool descriptions deliberately different when the audiences genuinely differ. Restify assumes they should not differ, which is a reasonable default and a constraint when it is wrong. A second alternative, API Platform, comes from the PHP ecosystem but outside Laravel and centers on a different resource-description model; adopting it in a Laravel application means giving up the Eloquent-native, policy-native integration that is Restify's main argument. The honest comparison is not feature lists but whether you want your resource definition to live in a Laravel repository class or somewhere else.
Versioning, licence and upkeep
The default branch is 10.x and the recent releases shown are 10.4.20, 10.4.19 and 10.4.18, dated within roughly ten days of each other in July 2026, with the repository last pushed in August 2026. That cadence tells you patch releases arrive often. It does not tell you whether a 10.x minor will change generated tool schemas, and the supplied material contains no upgrade guide or changelog, so pin the version in composer.json and read release notes before bumping if agents depend on specific tool names such as posts-index-tool.
Licence is MIT, which permits commercial use and modification. The repository is not archived. Those are the facts available; anything about support commitments or long-term governance is not stated and should not be assumed. Note also that the README links to Restify Templates at restifytemplates.com for starter kits with authentication, permissions and team management. That is a separate commercial offering, not part of the MIT package, and the README does not describe its pricing or licence. Keep the two distinct when you evaluate cost.
Editorial conclusion
Adopt Laravel Restify if you already run Laravel, want JSON:API compliance without writing serializers, and have a concrete reason to expose the same models to an MCP client. Do not adopt it if you need plain REST conventions, if you cannot add laravel/mcp to your dependency tree, or if you are unwilling to review generated tool schemas before an agent can call them. Before committing, verify three things in a scratch app: that restify:setup produces the expected config and migration files, that the MCP endpoint appears when you register RestifyServer in config/ai.php, and that a Laravel policy actually blocks a request through the MCP path the same way it blocks the JSON:API path.
Community notes