Ranetrace Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy for agent-facing observability. The vendor now hosts 31 MCP tools itself over Streamable HTTP rather than shipping a local server. That removes "we'd have to build and maintain an MCP bridge to our error data" from the build column — the buy option now covers both the telemetry backend and the agent interface, with no in-app component to own.
• Whether to put production telemetry behind an AI agent at all. Adoption is now a client-side, per-developer decision (create a token on the site's /mcp page, add a server entry). This is a governance/security call before it is an engineering one: which roles get tokens, whether production error data may leave your infrastructure to a vendor endpoint, and whether bearer tokens live in individual developer configs or a managed setup.
• Roadmap sequencing for AI-assisted engineering workflows. Because tool names, parameters and output are unchanged, existing agent prompts and playbooks carry over. If agent-assisted debugging is on the roadmap, this is a low-cost pilot — no instrumentation work, no app changes, and reversible by removing one client entry.
• Operational-risk posture on vendor dependency. Error/event ingestion (the five batch methods and the batch worker) is untouched, so the monitoring core is unaffected. But the agent surface is now a hard external dependency on api.ranetrace.com — availability, latency and rate limits become vendor SLAs rather than your uptime. Decide explicitly whether agent tooling is "nice to have during incidents" or "part of the on-call path"; only the latter needs a fallback plan.
• Dependency and secret hygiene as a standing policy. The package no longer requires laravel/mcp and no longer reads RANETRACE_MCP_ENABLED / RANETRACE_MCP_TOKEN. This is a net reduction in your app's attack surface and dependency tree — a supporting argument for consolidating observability vendors rather than stitching point tools.
• Vendor-management and version-pinning policy. A promised next-major removal shipped in a patch release, justified by the maintainer as "the package's only consumer." That is a real signal about release discipline: treat version constraints as load-bearing, watch the changelog before composer update, and factor maintainer responsiveness into renewal decisions. It does not change the product's capability, but it changes how you consume it.

When to Consider This Package

Adopt when:

• You are on Laravel and want error/event telemetry with a batched ingestion path you don't have to build, and the ingest/worker behavior is stable across this release.
• You want agent-accessible telemetry without running infrastructure — no local server, no extra process, no laravel/mcp dependency, no secrets in .env. The migration is two steps, entirely in the MCP client.
• Your team already uses MCP-capable clients (Claude, Cursor, VS Code). The config is a single mcpServers entry with "type": "http", one URL and one bearer header.
• You are piloting AI-assisted triage: read-oriented debugging and incident investigation where a developer's agent can query the same data the dashboard shows, with tool contracts that are stable across this release.

Look elsewhere or hold when:

• Data residency or egress rules prohibit production error payloads reaching a third-party HTTP endpoint, or your security review treats per-site bearer tokens in developer config files as unacceptable. The local server previously kept this in-network; that option is gone.
• You need the agent surface to work during a vendor or network outage, or you require self-hosted MCP for air-gapped or regulated environments. There is no local fallback in v1.1.1.
• You depend on the removed diagnostics surfaces — MCP rows in the diagnostics dashboard, ranetrace:status, ranetrace:test — as part of runbook verification. Those signals no longer exist; you'll need an alternative health check for the agent path (and note the app-side health checks no longer cover it at all).
• Strict semver is a procurement requirement. A breaking removal in a patch release means you should pin exact versions and gate upgrades through review, or choose a vendor with a published deprecation policy you can point at.
• You are not on Laravel, or you need telemetry features beyond what the 31 tools and the batch ingest expose.

How to Pitch It (Stakeholders)

To executives: This release makes our error-tracking vendor's AI-agent integration a hosted service instead of something that runs inside our application. Net effect for us: less code and one fewer dependency in our app, no new secrets to manage, and the same 31 capabilities our agents would use. It is a consolidation play — the vendor now owns the agent interface the way they already own the telemetry backend. The cost is that AI-assisted debugging now depends on their endpoint being up, so it's a convenience layer, not a system we should put on the critical on-call path without a fallback.

To engineering: Upgrade is small and mostly deletions. Remove RANETRACE_MCP_ENABLED and RANETRACE_MCP_TOKEN from .env, delete the ranetrace.mcp config block, and drop laravel/mcp from composer.json if nothing else needs it. Point your MCP client at https://api.ranetrace.com/mcp with an HTTP transport and a bearer token from your site's /mcp page; tool names, parameters and output are unchanged, so existing prompts keep working. Ingestion is untouched — the five batch methods and the batch worker are unchanged, so monitoring continuity is not at risk. Two cautions: this shipped as a patch release with breaking config changes, so pin versions and read the changelog before composer update; and the MCP rows in diagnostics, ranetrace:status and ranetrace:test no longer report on the agent path, so add a manual check (a single tool call against the hosted endpoint) if you were relying on those.

To security/legal: The agent surface now sends telemetry queries to a vendor endpoint authenticated by a per-site bearer token. Review token issuance and rotation on the /mcp page, decide whether tokens may sit in individual developer client configs, and confirm that querying production error data from a developer's agent is within our data-handling posture. The upside is that nothing runs in our application and no MCP credentials live in our environment anymore.