Mcp Adapter Laravel Package

Technical Evaluation

Identity check (blocking clarification). The artifact under review is not a Laravel/PHP package — it is the WordPress/mcp-adapter WordPress plugin (v0.7.1), which exposes WordPress "abilities" to AI clients over MCP (JSON-RPC 2.0, session-based HTTP transport). It has no composer.json-driven Laravel service provider, no publishable config, and no framework-agnostic bootstrapping. Any assessment framed as "Laravel package adoption" is measuring the wrong artifact. This assessment is written for the actual artifact (WordPress plugin), with Laravel implications called out explicitly.

• Architecture fit: Strong fit for a WordPress site acting as an MCP server (headless WP, content ops, editorial automation). Weak fit for a Laravel application — the coupling is to WordPress core APIs (abilities registry, Application Passwords, plugin load order), not to PSR/Composer conventions. If the target is Laravel, the correct decision is to evaluate a native Laravel MCP server package instead and treat this as out of scope.
• Integration feasibility: High within WordPress — install as a plugin, create an Application Password, point an MCP-capable client at the endpoint. Low within Laravel — would require running WordPress alongside (or a shim), which is an architecture decision, not an integration task.
• Technical risk:
  • Pre-1.0 API instability. 0.7.x means minor releases may change wire-level contracts. v0.7.1 itself changes an error code (ability_not_public_mcp → ability_not_found) — proof that a patch-level release can break consumers.
  • Security fix implies prior exposure. Unbounded session init params could cause repeated DB failures and excessive logging (availability/log-flooding class). Anyone on ≤0.7.0 and internet-facing should treat this as a patch-now item.
  • Forced client reconnects. Oversized stored session data is auto-cleared; affected clients must reconnect once. Plan for a transient error window post-deploy.
  • Reduced observability. Non-exposed and unknown abilities now return an identical ability_not_found response. That is a deliberate information-disclosure tradeoff, but it makes "typo" vs "ability not exposed via MCP" indistinguishable from the client side — expect longer triage.
  • Bundled-copy load ordering. The #366 fix confirms double-loading (installed plugin + older bundled copy) is a real failure mode. If we vendor this inside another plugin/theme, we own that risk.
• Key questions:
  1. Which runtime are we actually integrating — WordPress or Laravel? (Determines whether this assessment proceeds at all.)
  2. Do we consume or alert on ability_not_public_mcp anywhere (monitoring, client error handling, dashboards)?
  3. Do our MCP clients send large clientInfo payloads (inline base64 icons)? They will now be silently dropped.
  4. Do we bundle this plugin inside another package? If yes, verify load order post-upgrade.
  5. What backs session storage, and what is the retention/GC policy?
  6. Is the endpoint internet-facing or internal-only? Sets upgrade urgency.

Integration Approach

• Stack fit: WordPress (Application Passwords require HTTPS and WP ≥5.6), plus an MCP-capable AI client speaking JSON-RPC over HTTP. Laravel: no direct fit — do not attempt to composer require this as a library; it is distributed as a WordPress.org plugin.
• Migration path (baseline — no prior assessment):
  • Establish 0.7.1 as the floor, not a ceiling, and pin the exact version. Do not float 0.7.x.
  • If currently on ≤0.7.0: treat as a security patch, prioritize over feature work.
  • If greenfield: adopt 0.7.1 directly; document that 1.0 has not shipped and API stability is not guaranteed.
  • Composer-managed WordPress (Bedrock/wpackagist) should pin via composer/installers; classic installs should pin in the deployment manifest rather than relying on admin UI updates.
• Compatibility:
  • Wire contract changes to absorb: -32602 Invalid params on oversized (>4 KiB) session init; clientInfo.icons no longer retained across requests; ability_not_found replaces ability_not_public_mcp.
  • Behavioral: one-time session invalidation for oversized sessions → client reconnect required.
  • Release hygiene: sub-0.7.0 builds can no longer deploy to WordPress.org — confirms the vendor is enforcing a version floor; align our pinning with theirs.
• Sequencing:
  1. Confirm runtime decision (WP vs Laravel) — gate for everything below.
  2. Grep/audit codebase and dashboards for ability_not_public_mcp; update handlers and alerts.
  3. Verify client behavior with oversized clientInfo and oversized init payloads in staging.
  4. If bundled: validate autoloader/version-selection ordering after upgrade (per #366).
  5. Deploy to staging with session-failure logging enabled; measure failure rate.
  6. Production deploy in a low-traffic window; pre-notify client owners of possible one-time reconnect.
  7. Publish internal runbook; link the new site-owner setup guide (#375) as the L1 self-service path.

Operational Impact

• Maintenance: Pre-1.0 with a high release cadence (0.7.1 lands immediately after 0.7.0, including a security fix). Budget recurring upgrade effort, not a one-time install. Positive signal: CI includes PHPStan and stub updates (#372), indicating a real static-analysis quality bar; contributor list is small but active, with first-time contributor onboarding — healthy but bus-factor risk.
• Support: The new site-owner setup guide (connection, Application Password creation, testing, troubleshooting) is the single highest-value operational change here — it converts a class of "can't connect" tickets into self-service. Improved unknown-ability error messages (suggesting valid abilities / pointing to discovery) further reduce escalations. Residual support themes: Application Password/HTTPS misconfiguration, and ambiguous ability_not_found triage.
• Scaling: The 4 KiB session-init cap is a capacity protection, not just a security fix — it bounds per-session DB write amplification and log volume. Watch: session table growth and GC cadence, discovery-response payload size as ability count grows, and connection churn if clients reconnect aggressively after the session wipe.
• Failure modes:
  • Oversized init → hard -32602 failure (client-side fix required; not self-healing).
  • Mass reconnect after deploy → transient spike in session creates and auth attempts.
  • Bundled-copy version conflict → wrong code path loads; symptom is subtle, not a crash.
  • Non-exposed ability requested → indistinguishable from typo; misconfiguration presents as client error, delaying root cause.
  • Loss of clientInfo.icons → degraded client UI/attribution, may surface as a cosmetic bug report.
• Ramp-up: A PHP developer with WordPress experience should reach productive contribution in ~1–2 days; a Laravel-only team should assume 1–2 weeks for the WordPress domain concepts (abilities API, Application Passwords, plugin load order, hook lifecycle) — or should not be the owning team at all. Recommend the WordPress platform owner holds operational accountability regardless of who writes the AI-client integration.