Backoffice Mcp Laravel Package

Product Decisions This Supports

• Feature scoping for agent-facing surfaces. The $description field on a server is product-level metadata, not just config: it is the first thing the agent reads. Deciding what goes in it forces the team to articulate, per server, what data exists and who it is for — the same question you answer when scoping a feature.
• Roadmap: "agent-readiness" as a trackable capability. The package now spans two distinct layers — context (a hand-written $description first, then generic instructions that send the agent to the application code) and connection (OAuth discovery plus dynamic client registration for remote agent clients, hardened in 0.3.1). That is a roadmap-relevant stance on two fronts: the package bets on code as the source of truth for meaning, and on self-hosted OAuth for access. Both are opinionated defaults you are inheriting.
• Build vs. buy — now with an identity dimension. Before 0.3.x the buy decision was about prompt/context plumbing. With OAuth discovery and dynamic client registration in the box, the decision also covers running a small authorization server: do we own that surface, or federate to an existing IdP? Buying gets you a working remote-agent handshake cheaply; it also means you now operate auth endpoints you did not previously operate.
• Operational defaults are being chosen for you. 0.3.1 throttles discovery and client registration to 30 requests/minute per IP because registration is unauthenticated and writes a database row. That is the right instinct — it closes a trivial abuse and storage-exhaustion vector — but it is a product-level throttle you should consciously accept or override.
• Multi-tenant and network-shape decisions. Per-IP throttling is a proxy for "per client," and proxies fail: corporate NAT, CI egress pools, and containerised agents can share an IP. If you expect many agents behind one address, that is a product constraint to design around (tenant-aware limits, allowlists), not a bug to file later.
• Use cases it unlocks. Internal copilots and support/ops agents reasoning over Laravel domain data; onboarding a coding agent to an unfamiliar codebase; per-domain "servers" (billing, catalog, accounts) so an agent can route correctly; and — new in this line — remote/hosted agent clients that need a standard OAuth handshake rather than a bespoke token-sharing arrangement.
• Prioritisation signal. Descriptions remain cheap to author and centrally located, so agent support can still ship domain-by-domain. The auth surface is the opposite: a single, cross-cutting piece of work with a security review attached. Budget it as a platform item, not a feature item.

When to Consider This Package

Adopt when:

• You are on Laravel/PHP and are committed to LLM-driven agents that consume your application's data, including clients you do not control (remote/hosted agents) that expect OAuth discovery and dynamic registration.
• Your domains are distinguishable enough that per-server descriptions genuinely reduce ambiguity (multiple bounded contexts, not one monolithic dataset).
• You are comfortable with code as the contract — the release delegates meaning-discovery to the agent reading your application code, which only works if your code is legible and reasonably conventional.
• You accept running a modest auth surface: unauthenticated registration, a database table of clients, and a shipped rate limit. Low lock-in and small surface area — config plus prose, plus endpoints — with no additional infrastructure to stand up.
• You can live with, or configure around, a fixed per-IP throttle. Verify on 0.3.1 whether the 30/min limit is configurable — if it is hard-coded, large tenants behind shared egress will hit it and see registration failures as an outage.

Look elsewhere when:

• You need machine-checkable schema contracts (typed fields, versioned APIs) rather than natural-language descriptions — prose drifts silently as code changes.
• You require hard data-governance guarantees (PII boundaries, row-level auth, audit trails) at the context layer; a description field is not an access-control mechanism, and a rate limiter is not an authorisation policy.
• You need enterprise identity expectations — SSO, per-tenant policy, consented scopes, revocation workflows — that a lightweight embedded authorization server will not satisfy. That is an IdP integration, not a config flag.
• You are not on Laravel, or you need a hosted/managed context service with SLAs.
• Your team cannot sustain documentation discipline: an inaccurate $description is worse than none, because it now precedes and colours everything the agent infers.

Caveats for evaluation:

• 0.2.0's notes were thin; 0.3.1 tells us the package has grown a network-reachable, unauthenticated write path. Treat the auth surface as new scope requiring a security review, registration-table growth/retention planning, and monitoring on the registration endpoint — none of which is a product feature, all of which is product cost.
• Confirm empirically how much the description-first ordering improves agent accuracy before making roadmap dependency explicit.

How to Pitch It (Stakeholders)

For executives: A small, low-cost capability that makes our application legible to AI agents. We attach a short, human-written description to each data domain that the agent reads before anything else, and we deliberately avoid maintaining a second copy of our data model — the code stays the source of truth. The package now also handles how remote agent clients connect, using standard OAuth, and the latest patch rate-limits the unauthenticated registration step. Cheap to adopt, no new infrastructure, but it is a security-relevant surface we would own rather than outsource.

For engineering: Two parts. Context: each server gains a $description injected ahead of the generic instructions, which then direct the agent to the application code — an explicit bet on code readability over maintained schemas, so descriptions must stay honest and code conventional. Connection: OAuth discovery and dynamic client registration are now in scope; 0.3.1 caps discovery and registration at 30 requests/minute per IP because registration is unauthenticated and inserts a row each time. Verify whether that limit is configurable, plan for client-row cleanup, and watch for false positives from shared egress IPs.

Ask: Timeboxed pilot on one domain to measure agent accuracy with and without a tuned $description, plus a short security and config review of the OAuth endpoints (throttle configurability, row retention, monitoring) before we commit to broader rollout.