Nova Mcp Laravel Package

Technical Evaluation

• Architecture fit: mdrbx/nova-mcp is an MCP adapter over Laravel Nova. The v0.2.0 write surface delegates to Nova’s native controllers and policies, which is the right architectural boundary: authorization remains in Nova rather than being reimplemented in the MCP layer. The package now supports controlled relationship mutations, child creation, restore/force-delete, replication-form discovery, and synchronous resource actions.
• Product leverage: TPMs can expose AI-assisted Nova administration for relationship maintenance and common synchronous actions without building a custom API. The excluded action types—queued, standalone, and pivot actions—keep the initial write scope narrower and easier to govern.
• Integration feasibility: Low code-integration effort for teams already on Nova: composer update mdrbx/nova-mcp, rebuild config cache after env changes, no migrations or frontend build. Compatibility is stated as PHP 8.3–8.5 and Laravel 12–13, so older Laravel/Nova stacks need validation.
• Technical risk: The main risk is authorization and blast radius, not installation. Writes remain enabled by default and require nova:write plus Nova authorization. Existing write-capable tokens, undefined policy methods, and incomplete policy coverage need explicit review before production use. NOVA_MCP_GUARDRAILS is client guidance only, not a security control.
• Key questions: Which existing tokens carry nova:write? Can tokens be scoped by resource/action? Are attach/detach, child create, restore/delete, and synchronous actions checked at the same policy granularity as the Nova UI? Are MCP writes audit-logged? Does NOVA_MCP_READ_ONLY=true reliably cover every mutation path? How are undefined policy methods resolved in our Nova version? What rate limits and timeouts apply to synchronous actions? Is the package’s Nova version support matrix confirmed?

Integration Approach

• Stack fit: Best suited to Laravel 12–13 applications using Nova and an MCP client. It fits existing Nova policy and token models and should be treated as a privileged integration surface rather than a read-only convenience.
• Migration path: Start with composer update, set NOVA_MCP_READ_ONLY=true, rebuild the config cache, and validate discovery and read behavior. Inventory tokens, confirm nova:write assignment, review Nova policies, update MCP client instructions via NOVA_MCP_GUARDRAILS, and verify the updated consent screen before enabling any writes.
• Compatibility checks: Confirm exact Nova version support, PHP 8.3–8.5 runtime, Laravel 12–13, config-cache behavior, and token issuance flow. Validate that existing read-only deployments stay read-only until explicitly changed.
• Sequencing: 1) policy and token inventory; 2) deploy read-only with config cache rebuild; 3) staging validation of relationship operations and synchronous actions; 4) audit/logging verification; 5) pilot nova:write tokens for a limited resource set; 6) production enablement by exception; 7) monitor and expand. No DB migration or frontend build is required, so the critical path is security review and staged enablement.

Operational Impact

• Maintenance: Pin the package version and watch pre-1.0 releases for behavior changes. The test/CI signal is positive—126 tests, 1,387 assertions, PHPStan level 6, Rector, Pint, and a PHP/Laravel matrix—but production assurance still depends on Nova policy coverage and audit controls.
• Support: Expect incidents around missing nova:write, policy denials, stale config cache after env changes, and confusion between guardrail text and server-side authorization. Runbooks should cover NOVA_MCP_READ_ONLY, token rotation, consent-screen expectations, and action-specific policy failures.
• Scaling: Load tracks MCP client activity and Nova/DB behavior. Synchronous actions can block and time out; relationship writes can create broad fan-out. Add rate limits, timeouts, and monitoring for write-heavy usage. The read-only flag is a useful global kill switch, including for existing write tokens.
• Failure modes: Accidental write enablement, overprivileged tokens, undefined policy methods, missing audit records, partial relationship/pivot failures, synchronous action timeouts, and config-cache drift after environment changes. Guardrail customization should not be treated as enforcement.
• Ramp-up: Moderate for Nova teams. Code rollout is simple, but security, support, and platform teams need alignment on token scopes, policy completeness, read-only defaults, and pilot criteria before broad write access is granted.