Fady Mondy's blog

Ship a Laravel Admin Panel in a Day with Filament 5 and TomatoPHP

Fady Mondy — Mon, 12 Oct 2026 11:22:07 GMT

Every Laravel admin panel I've built starts with the same list: users and roles, app settings, English and Arabic, a media library, menus, some content pages, and sooner or later invoices. None of it is your product, but all of it has to work before anyone sees your product. I maintain TomatoPHP, 68 MIT-licensed Filament plugins, and this is the exact order I install them in on Filament 5 when I want that part done in a day. (This post first appeared on tomatophp.com.)

Filament gives you the panel. TomatoPHP gives you those modules as plain composer packages. There are 68 TomatoPHP Filament plugins, all MIT-licensed and released for Filament 5, Laravel 12–13 and PHP 8.2+. Each one registers itself with your panel in one line.

What you end up with

You need	Plugin	Package
Users and roles	User Manager	`tomatophp/filament-users`
App settings (site name, logo, colours, social links)	Settings Hub	`tomatophp/filament-settings-hub`
English + Arabic UI, translated from the panel	Translation Manager + Language Switcher	`tomatophp/filament-translations`, `tomatophp/filament-language-switcher`
Files and images	Media Manager	`tomatophp/filament-media-manager`
Navigation menus	Menu Builder	`tomatophp/filament-menus`
Posts, categories and pages	CMS Builder	`tomatophp/filament-cms`
Invoices and payments	Invoice Manager	`tomatophp/filament-invoices`
Installable app on phones	PWA	`tomatophp/filament-pwa`

Try before you install: demo.tomatophp.com runs 31 TomatoPHP plugins together on Filament 5, with a prefilled demo account. The data resets every hour, so click anything.

Before you start

Start from a fresh Laravel app with a Filament 5 panel:

composer require filament/filament:"^5.0"
php artisan filament:install --panels

Every plugin below follows the same three steps: composer require, run its install command, then add ->plugin(...) to app/Providers/Filament/AdminPanelProvider.php. Some also publish a migration. Each plugin page links to its README with the exact steps, so keep it open while you go.

Morning: the foundation

Users. One package gives you the user resource. If you need roles, the README shows how to pair it with Filament Shield.

composer require tomatophp/filament-users

Settings. Settings Hub stores site settings in the database and gives you a settings page in the panel. Several other TomatoPHP plugins (PWA, invoices) add their own pages to it, so install it early.

composer require tomatophp/filament-settings-hub
php artisan filament-settings-hub:install

Two languages. The Translation Manager scans your code for trans() and __(), stores the strings in the database with a cache, and lets you translate them from the panel. The Language Switcher adds the toggle. English and Arabic work out of the box, including RTL.

composer require tomatophp/filament-translations tomatophp/filament-language-switcher
php artisan filament-translations:install
php artisan filament-language-switcher:install
php artisan filament-translations:import

Midday: content

Media. Media Manager puts a GUI on top of Spatie Media Library: folders, uploads, and a picker you can use in your own forms.

composer require tomatophp/filament-media-manager
php artisan vendor:publish --provider="Spatie\MediaLibrary\MediaLibraryServiceProvider" --tag="medialibrary-migrations"
php artisan filament-media-manager:install

Menus and pages. The Menu Builder stores navigation in the database, so you can render it in the panel or in a Livewire component. The CMS Builder adds posts and categories. Both are translatable, so register lara-zeus/spatie-translatable next to them.

composer require tomatophp/filament-menus tomatophp/filament-cms
php artisan filament-menus:install
php artisan filament-cms:install

One warning from the README: the CMS creates categories and posts tables. If your app already has those, rename yours first.

Afternoon: money

Invoices. The Invoice Manager handles invoices and payments with multiple currencies and invoice types. Call ->useSettingsHub() and its settings appear next to everything else.

composer require tomatophp/filament-invoices
php artisan filament-invoices:install

Before the first invoice, tell it which models invoices are from and for (for example your company and your customers). The README shows the facade call to put in a service provider.

Register everything

With those installed, the panel provider looks roughly like this (check each README for the options you want):

use Filament\Panel;

public function panel(Panel $panel): Panel
{
    return $panel
        // ...
        ->plugin(\TomatoPHP\FilamentUsers\FilamentUsersPlugin::make())
        ->plugin(\TomatoPHP\FilamentSettingsHub\FilamentSettingsHubPlugin::make()
            ->allowSiteSettings()
            ->allowSocialMenuSettings())
        ->plugin(\TomatoPHP\FilamentTranslations\FilamentTranslationsPlugin::make())
        ->plugin(\TomatoPHP\FilamentLanguageSwitcher\FilamentLanguageSwitcherPlugin::make())
        ->plugin(\TomatoPHP\FilamentMediaManager\FilamentMediaManagerPlugin::make())
        ->plugin(\LaraZeus\SpatieTranslatable\SpatieTranslatablePlugin::make()
            ->defaultLocales(['en', 'ar']))
        ->plugin(\TomatoPHP\FilamentMenus\FilamentMenusPlugin::make())
        ->plugin(\TomatoPHP\FilamentCms\FilamentCMSPlugin::make()
            ->useCategory()
            ->usePost())
        ->plugin(\TomatoPHP\FilamentInvoices\FilamentInvoicesPlugin::make()
            ->useSettingsHub());
}

Run php artisan migrate, sign in, and you have a bilingual admin panel with users, settings, media, menus, content and invoices. That is the part every client expects and nobody pays extra for.

What this won't do for you

It won't design your domain. The plugins cover the generic modules. Your orders, bookings or patients are still your code, and that's where the day you saved should go.
Read the README of each plugin. Some publish migrations or need a companion package. The compatibility table at the top tells you which major version matches your Filament.
Not every repo is a finished plugin. The TomatoPHP organisation has more repos than the 68 released Filament plugins. Use what's listed on the plugins page, which is the maintained set.

How the plugins are maintained

During the Filament 5 upgrade, every plugin went through the same release gate before it was tagged: open issues fixed and community PRs merged with credit, a green Pest suite with a regression test for each fix, and then a real install in a sandbox Laravel 13 + Filament 5 app where a smoke test renders every panel page with zero skipped. The same pass found and fixed real security bugs, for example unescaped user HTML in the docs, blog and notes plugins, and payment gateway secrets that were reaching the browser.

The packages have more than 1.7 million installs on Packagist, and the source is on GitHub.

Next steps: browse all plugins · read the docs · try the live demo

Originally published on tomatophp.com.

How to Ship an Official MCP Server for Your SaaS in 2 Weeks

Fady Mondy — Sun, 11 Oct 2026 13:00:12 GMT

Originally published at fadymondy.com.

Your customers are starting to ask a new question in sales calls and support tickets: "Does it work with Claude?" Sometimes it is ChatGPT or Cursor instead, but the request is the same. They want to ask their AI assistant to do real work inside your product, without copying data between tabs.

The standard way to make that happen is an MCP server. The Model Context Protocol is the open protocol AI assistants use to discover and call tools in other products. If you already have a decent API, an official MCP server is a small, well-bounded project. Here is how I plan and ship one in about two weeks, and what to decide before anyone writes code.

What an MCP server actually is (for a SaaS team)

An MCP server is a thin layer that sits beside your product and talks to your existing API. It exposes a short list of tools, each with a name, a plain-language description and a typed input schema. The assistant reads those descriptions, decides which tool fits the user's request, and calls it.

Three things follow from that:

Your backend doesn't change. The server is a client of your API, like your web app is.
Your language doesn't matter. I usually build in TypeScript or Go, or PHP for Laravel products, whatever your team can maintain.
Tool design matters more than code volume. Most of the work is deciding what the assistant should be able to do, and describing it so the model picks the right tool.

There are two common ways to run one: remote (a hosted HTTP endpoint your cloud customers connect to with OAuth) and local (a package the user runs on their machine, which suits self-hosted installs). Many SaaS products start with remote.

Why "official" matters

If you don't ship one, someone else might. Community MCP servers for popular products appear quickly, and they usually ask users to paste a full-access API key into a config file. Your customers then run unvetted code with their production credentials, and you get the support tickets.

An official server lets you control three things: which actions are exposed, how authentication works, and how your product is described to the assistant.

The 2-week plan

Two weeks is realistic when the API exists and is documented, and the first version focuses on the 10–20 actions people actually ask for. Here is the sequence I use.

Step 0: a one-page tool spec (before any commitment)

Before building, I read your API docs and write a one-page spec. It lists the proposed tools, what each one does, its inputs, whether it reads or writes, and which auth scope it needs. It is the cheapest way for both sides to see whether the project makes sense.

A good spec answers:

What are the five things a user will ask the assistant to do on day one?
Which of those are read-only and which change data?
Which actions are destructive or expensive and need a clear warning?
What does the assistant need to find things (search, filters, IDs)?

Days 1–3: tool design and scaffolding

Turn the spec into tool definitions. Keep the list short and the names obvious. Don't mirror every endpoint. An assistant does better with find_customer and create_invoice than with forty CRUD endpoints that differ by one field.

Write the descriptions as instructions to the model: when to use the tool, what it returns, and what not to use it for. In my experience this is the work that most changes how well the server performs.

On my own servers, tools live in a registry: one list the protocol layer reads. Adding a tool later means adding one entry, not touching the transport or auth plumbing. It keeps the server easy to grow after handover.

Days 4–7: authentication and permissions

This is where an official server earns its name.

OAuth for remote servers. The MCP authorization spec is built on OAuth 2.1. On Zekra's remote MCP endpoint I implemented the full flow: PKCE (S256), dynamic client registration and per-brain consent, with access re-checked against current membership on every call.
Scoped API keys as a fallback. In Moharrik, keys are read-only by default and expire after 90 days.
Read and write separated. Mark read-only tools as read-only (MCP tool annotations support readOnlyHint and destructiveHint). On Zekra, adding read-only annotations let AI coding agents and other MCP clients run recall and list tools without an approval prompt, while writes still ask.
Make agent actions traceable. When an assistant writes data, record that it was an agent. On my issue tracker, comments created over MCP are stored with author_kind = 'agent', so a human can always tell them apart.

Days 8–10: test against real assistants

Unit tests aren't enough. Connect the server to Claude, ChatGPT and Cursor and run the prompts from the spec. Watch for:

the assistant picking the wrong tool (fix the description, not the model);
tools returning too much data (paginate and trim; context is not free);
vague errors (return messages the assistant can act on, like "customer not found, try search_customers").

Days 11–14: docs, listing and handover

Setup guides for each assistant: one page each, with the exact config.
A permissions page that explains in plain language what each scope allows. In Moharrik this explainer is generated from the tool registry, so it can't drift from the code.
Listings in the main MCP directories, so users can find the official server.
Handover. The repository, deployment notes and a short walkthrough. The code ships under your name and licence.

What stretches past two weeks

Be honest about scope up front. These usually add time:

no public API yet, or an API that can't do what users ask;
complex multi-tenant permissions that aren't modelled in the API;
long-running jobs that need progress reporting or webhooks;
a self-hosted package and a remote endpoint in the first release.

None of them blocks a project. They belong in the spec so the plan and the price stay fixed.

Checklist before you start

Your API is documented and stable enough to build against.
You have listed the top 5 user requests the assistant should handle.
You know which actions must never run without a confirmation.
You have decided on remote, local or both.
Someone on your team will own the server after handover.

Proof, not promises

I build MCP servers for my own products, and they run in production:

Orchestra MCP: an AI-agentic IDE framework with a plugin-host architecture.
Zekra: shared memory for AI agents, served over a remote MCP endpoint with OAuth 2.1.
Moharrik: a CRM with inbox and WhatsApp that is fully operable over MCP.
Nasaq UI: an open-source design system with its own MCP server.

If you want the same for your product, see MCP server development. The process starts with a free one-page tool spec.