Mcp Laravel Package

Product Decisions This Supports

• Build vs. buy for the "AI agent access" layer. If the roadmap includes letting ChatGPT/Claude/Copilot act on catalog data, this package is a ready-made MCP server rather than an internal engineering project. It ships 25 core tools, two transports, and an install command — the cost comparison is roughly "a sprint of platform work" vs. composer require unopim/mcp. v1.0.5 also cleans up the server-side instructions clients receive, so agents are steered to the right discovery tools from the first turn instead of being told to start from a schema dump or to use developer tooling that may not be enabled.
• Prioritizing AI-assisted catalog enrichment on the roadmap. The batch upsert_products / upsert_categories / upsert_attributes tools (max 50 per call, atomic) plus search_products map directly onto the highest-value PIM use cases: bulk attribute completion, description generation, taxonomy cleanup, and completeness-gap remediation driven by an agent. Agent onboarding now routes discovery through search_settings (channels and locales, with guidance to filter locales by status = 1 so agents don't reason over every locale the platform ships) and search_attributes for attribute definitions — a smaller, cheaper starting context than a full schema read, which matters when you're paying per token across a long enrichment session.
• Choosing UnoPim as the PIM. Native MCP support with ACL enforcement is a genuine differentiator in PIM selection against Akeneo and similar, and this package even ships a comparison doc. When it's down to two PIMs, "agents can operate it day one, under existing permissions" is a scoring criterion. The compatibility bet holds: the package tracks UnoPim 3 / Laravel 13, so the differentiator survives the platform's next major upgrade rather than being stranded on the current release.
• Sizing the investment in AI workflows. Dynamic Skills (SKILL.md dropped into .ai/skills/, auto-registered as a tool, cached) means repeatable merchandising workflows can be authored and versioned without shipping PHP. That decides whether AI operations need engineering headcount or just analyst time — a resourcing decision, not a technical one.
• Approving (or rejecting) a pilot with real catalog data. The differentiator versus a proof-of-concept script is governance: ACL mapping per tool via bouncer(), audit logging on every destructive call with user ID/IP/arguments, per-tool rate limiting, path jailing, and command whitelisting. That is the evidence pack you need to move from sandbox to a supervised pilot without a security exception. v1.0.5 tightens the story in three specific ways a reviewer will ask about: server instructions now only describe developer tools, diagnostics and dynamic skills when they are actually served (stdio, or HTTP with MCP_REMOTE_DEVELOPER_TOOLS enabled), so a locked-down deployment no longer advertises capability it doesn't have; remote HTTP responses use the authenticated admin's UI locale, so agents surface the same translated messages the admin panel does; and the new latest_execution payload is itself permission-gated.
• Internal engineering velocity for UnoPim extension work. The stdio transport targets Copilot/Cursor/Claude Code directly, and dev_tools (generate_plugin, generate_test, get_database_schema, read_logs, run_command) turns common platform chores into agent actions. This is a productivity decision for the platform team, funded separately from the merchandising pilot.
• Scoping the data-transfer / ops story. search_jobs now returns each job's latest_execution inline (id, state, started_at, completed_at, or null if it never ran), loaded in one query per page, with an id that feeds straight into get_job_execution. That turns "which imports failed this morning and why" into a two-call agent workflow instead of a paginated join the agent has to reconstruct — a support-cost reduction lever distinct from enrichment. Visibility is gated on the data_transfer.job_tracker permission, so you can pilot it with ops staff first.
• Deciding the "no" list. The config reserves media.allowed_extensions / allowed_mimes but media tools are not implemented, so any roadmap item about AI-driven asset management is explicitly post-adoption or out-of-scope. Similarly, the 100-per-page / 50-per-batch ceilings mean high-volume migrations stay a scripting job, not an agent job.

When to Consider This Package

Consider it when:

• You are running UnoPim 1.0+ (including UnoPim 3) on Laravel 11–13 / PHP 8.2+. The package explicitly supports Laravel 13 and UnoPim 3, so adoption is not penalized by a platform-upgrade deadline. This remains a hard prerequisite, not a preference — it is a package inside the UnoPim app (packages/Webkul/MCP), not a standalone service.
• You want agents to operate through your existing permission model rather than with a service account that bypasses it. The bouncer-based ACL mapping is the main reason to prefer this over a hand-rolled REST wrapper — and the newest release extends it rather than working around it (latest_execution is only returned to admins holding data_transfer.job_tracker).
• You need both remote assistants (HTTP SSE at POST /api/mcp/unopim, Passport-protected) and local coding agents (stdio), from one install. Two things now make the remote path credible for shift-long analyst workflows rather than demos: the earlier keepalive fix that keeps long SSE sessions alive, and locale-correct responses so translated tool output matches what the admin sees in the panel.
• You value time-to-first-result: one install command, a published config, and mcp:inspector for manual tool testing before committing. v1.0.5's instruction cleanup means the agent's first moves are correct out of the box, which shortens the "why is the agent asking for the wrong thing" debugging phase of a pilot.
• You are comfortable as an early adopter: 4 stars, 0 dependents, thin external validation, and vendor-concentrated maintenance. Acceptable for an internal, reversible pilot; treat a wider rollout as a bet on the UnoPim/Webkul ecosystem. Three patch releases in quick succession (v1.0.2 → v1.0.5, all fixes and small additive changes, no breaking changes observed) is a healthy sign of active maintenance but also confirms you are on a fast-moving cadence — pin a version and upgrade deliberately rather than tracking dev-main.
• You have the appetite to scope dev_tools deliberately. File writes, php artisan/composer execution, read-only SQL, and log tailing are powerful, and the stdio path bypasses ACL for local development by design. If your security posture forbids shell-adjacent agent access, adopt the catalog/settings/transfer tools only and verify per-tool enablement is granular enough to enforce that. v1.0.5 helps here: with developer tools off, the instructions no longer describe them at all, so a locked-down deployment is coherent to the agent rather than tempting it with unavailable capability.

Look elsewhere or defer when:

• You are not on UnoPim. For Akeneo or a custom PIM, this is not portable — evaluate that vendor's MCP offering or budget an internal build.
• You require vendor SLA, indemnification, or a named support contract. MIT plus a small OSS project does not provide it; you would be self-supporting with a fork option.
• Your first roadmap need is digital asset / media management via agents — not yet implemented.
• You need field-level or record-level permissions finer than the existing bouncer mappings, or multi-tenant isolation guarantees that have not been independently reviewed.
• You need volume beyond the documented caps (100 records/page, 50/batch, 60 req/min default). Workable with client-side chunking, but do not pitch it as an ETL replacement.
• You are in a regulated environment requiring third-party security audit artifacts; the multi-layer controls are well described and tested, but there is no external attestation here. Also validate SSE longevity under your own network conditions (proxies, load balancers, idle timeouts) before relying on it in a production-facing pilot — the keepalive fix predates this release and is not re-verified by it, and v1.0.5's instruction and locale changes are quality-of-life, not a stability guarantee for your network.

How to Pitch It (Stakeholders)

For executives — one paragraph. This is a small, MIT-licensed add-on that lets the AI assistants our team already uses — ChatGPT, Claude, Copilot, Cursor — read and update our product catalog directly, without building or buying anything new. It runs inside our existing PIM and inherits our existing permissions and audit trail, so a pilot carries low cost and low switching risk. The latest releases keep remote assistant sessions stable, keep the package compatible through the next UnoPim and Laravel major versions, and now give operations staff a one-call view of which data imports failed and why — surfaced only to people who already have job-tracker access. Recommended ask: a time-boxed pilot on a bounded category set, with a go/no-go on measured enrichment throughput rather than on the technology.

For engineering — the honest summary. composer require unopim/mcp plus php artisan mcp:install; config published under the mcp-config tag. Two transports from one codebase: an HTTP SSE endpoint behind auth:api (Passport, on by default via MCP_API_AUTH) and a stdio server via php artisan mcp:start unopim-dev. Tools are registered in a static ToolRegistry, proxied through PimCallTool where auth, rate limiting, ACL, and audit are applied. Search tools share a UnoPimQueryBuilder with a documented operator set; writes are atomic batches capped at 50. Extensibility is real, not aspirational: FileManagerInterface / SkillExecutorInterface contracts, a dynamic SKILL.md loader with caching, and 21 test files across unit and feature suites. Pin v1.0.5 or later; on Laravel 13 / UnoPim 3 it is the minimum supported line, not an optional upgrade. Changes since the v1.0.2 assessment, all non-breaking: server instructions are now composed conditionally on what is actually served (dev tools, diagnostics, dynamic skills appear only over stdio or with MCP_REMOTE_DEVELOPER_TOOLS enabled); discovery guidance was repointed from get_catalog_schema to search_settings / search_attributes, with an explicit status = 1 filter hint for locales; instructions are emitted without leading indentation so clients stop rendering them as a fenced code block; remote HTTP requests now resolve the authenticated admin's UI locale, falling back to the app default; and search_jobs gained an inline latest_execution object (id, state, started_at, completed_at, null when never run) loaded one query per page and returned only under data_transfer.job_tracker. get_job_execution gained an integer-range guard (1–2147483647) in both schema and validation, plus a translated not-found message — relevant if you're on PostgreSQL, where out-of-range ids previously produced a generic error. If you write tooling against the instructions text or depend on get_catalog_schema being the documented entry point, re-read the guidance before upgrading. Caveats to state up front: young project, low adoption, effectively single-vendor maintenance, no dependents to learn from, and a patch cadence fast enough that you should pin. Keep audit logging on, default rate limits in place, and review allowed_paths plus command whitelisting before exposing HTTP beyond localhost. Decide explicitly whether dev_tools is enabled in shared environments — it is the highest-leverage and highest-blast-radius surface in the package, and the stdio path bypasses ACL for local development by design.

Suggested pilot success criteria: number of SKUs enriched per analyst-hour vs. baseline, completeness-score delta on the target category, zero permission or audit anomalies, zero dropped remote sessions across a full working day, a documented answer on whether the 50-per-batch ceiling forced manual chunking in practice, and — for the ops slice — mean time from failed import to triage decision using search_jobs → get_job_execution versus the current admin-panel workflow.