Mcp Laravel Package

Product Decisions This Supports

• Roadmap: is "AI access to the ERP" a Now, Next, or Later item? This package is the cheapest credible way to test that question. It converts an abstract roadmap line ("expose ERP to AI assistants") into a bounded spike: install package, install one plugin, confirm its tools activate, run a real query from an MCP client, measure whether anyone changes their workflow.
• Build vs. buy on protocol plumbing. MCP is a moving specification. Implementing schema discovery, tool/resource exposure, and client compatibility in-house is undifferentiated work that will need maintenance against a shifting spec. Buying (i.e., adopting) the bridge lets the team spend its engineering budget on the part that is actually differentiating: which ERP actions are worth exposing and under what permissions.
• Scope decision: which ERP domains go first. Because exposure is plugin-gated, the rollout surface is naturally sliceable — one plugin, one domain (e.g., orders, inventory, contacts), one internal pilot group. That gives a genuine phased roadmap with kill points rather than a big-bang "AI integration" launch.
• Ecosystem and extensibility strategy. Extensible handlers plus a plugin installation boundary mean third-party or internal module authors can ship their own MCP tools without the core team becoming a bottleneck. That is a platform decision, not a feature decision: it determines whether you become a marketplace or stay a monolith.
• Governance and control posture. The v1.0.3 change — tools activate only when their plugin is installed — is a product feature in disguise. It gives you an install-time switch for what the AI can see and do, which is the story you want when security or compliance asks "how do you turn this off?"
• Competitive positioning and demos. "Your ERP is queryable by Claude/Cursor/whatever MCP client your team already uses" is a materially stronger demo than another dashboard. Useful for sales enablement, partner conversations, and internal stakeholder buy-in.
• Make-vs-integrate for each AI client. By standardizing on MCP you avoid one-off connectors per assistant vendor. That is a durable architectural commitment worth recording as an ADR.

When to Consider This Package

Consider it when most of the following hold:

• You are already on AureusERP, or on a Laravel application whose extension model is fundamentally plugin/package-based with installation state you can observe centrally.
• You have a concrete near-term use case — an internal assistant, an ops copilot, a data-lookup agent — rather than a speculative "we should do AI."
• Your team is comfortable with Laravel package mechanics: Composer, service providers, config publishing, config cache, migrations.
• You want a low-cost pilot and are willing to pin versions and read release notes closely; you accept early-stage churn in exchange for speed.
• You can sequence deployment: install plugin → then allow tool activation. If your release process cannot guarantee that ordering, expect flaky "tool missing" incidents.
• You need discoverable schemas so an AI client can reliably call the right action without bespoke prompt engineering per integration.

Look elsewhere — or wait — when:

• You are not on Laravel/AureusERP. The value is inseparable from that stack.
• The feature is revenue-critical or customer-facing this quarter. At v1.0.3 with a tiny star count and a patch release that changed activation semantics, this is pilot-grade, not production-critical-grade.
• You need vendor SLA, security attestation, or audited access control. Nothing in the supplied material demonstrates per-tool authorization, audit logging, rate limiting, or data-scoping. In an ERP context that is the gap that matters most; assume you must build it around the package.
• Multi-tenant or multi-node consistency is core. Plugin-state visibility across nodes, tenants, and environments is an unsolved operational burden here.
• You need write actions on financial or inventory records immediately. Start read-only; the package does not appear to arbitrate action risk.
• You need uninstall/rollback semantics you can trust. Stale activation records and orphaned state are explicit failure modes.

How to Pitch It (Stakeholders)

To executives: This is a small, reversible bet that makes our ERP legible to AI assistants through an emerging industry standard (MCP) instead of a series of one-off vendor integrations. Cost is low and contained — a Composer package, not a platform rebuild. It also gives us a clean control surface: AI capabilities are switched on per installed module, so we can pilot on one business domain, measure, and switch off just as cleanly. Recommendation: fund a time-boxed pilot with one plugin and one internal user group, with explicit success criteria and a decision date, not an open-ended commitment.

To engineering: Adopt as the MCP transport/adapter layer; do not rebuild the protocol. The v1.0.3 behavior — tools activate only when the corresponding plugin is installed — is the invariant to design around: treat plugin installation as the single source of truth, sequence plugin install before tool activation in deployment runbooks, clear config cache after installs, and add a smoke test that installs a plugin and asserts its tools activate. Three open questions gate wider rollout: how "plugin installation" is actually detected, whether existing activations are reconciled when a plugin disappears, and what authorization/audit exists between an AI client and an ERP action. Until those are answered, treat every exposed tool as read-only and least-privilege, pin the version, and read every release note — patch releases here have changed activation semantics.