Askmydocs Mcp Pack Laravel Package

Product Decisions This Supports

• Build vs. buy for an MCP surface. If the roadmap includes exposing your product's documentation or knowledge base to AI clients (Claude, IDE agents, internal copilots) over the Model Context Protocol, this package is a candidate to buy/adopt rather than hand-rolling an MCP server, transport handling and schema conformance in-house.
• Time-to-market for an "AI-integrated" feature. The release notes show maintained MCP 2026-07-28 conformance fixtures, meaning the protocol-version churn is being absorbed by the maintainer. That converts a spec-tracking maintenance burden into a Composer constraint.
• Platform-upgrade sequencing. Runtime support for Laravel 11, 12 and 13 on PHP 8.3–8.5 lets you adopt it without pinning your framework upgrade path — a relevant input when planning the next Laravel major.
• Dependency-footprint risk on shared HTTP clients. v2.0.1 relaxes guzzlehttp/guzzle to ^7.8.2|^8.0. This directly removes a real adoption blocker: under v2.0.0 a host already on Guzzle 8 would have been forced to downgrade Guzzle (8.3 → 7.16), PSR-7 (3.2 → 2.13) and Promises (3.1 → 2.6). For any product with other Guzzle-dependent integrations (payments, webhooks, third-party APIs), that downgrade was a cross-team risk, not a local one.
• Scoping the integration. The Guzzle dependency implies outbound HTTP calls to an external service, and the OpenAPI/static-analysis CI steps suggest generated or spec-driven client surfaces. Treat this as an integration with an upstream docs/knowledge source, not a self-contained library — budget for credentials, egress, rate limits and data-residency review.

When to Consider This Package

Consider adoption when:

• An MCP endpoint is an explicit roadmap item, or an existing manual/undocumented MCP implementation is a maintenance drag.
• Your stack is Laravel 11+ on PHP 8.3+, matching the declared support matrix (CI covers PHP 8.3–8.5 × Laravel 11/12/13 at lowest and latest constraints).
• You are already on Guzzle 8, or plan to be — v2.0.1 is the minimum version to evaluate; v2.0.0 should be treated as unusable for Guzzle-8 hosts.
• You value spec conformance being tested in CI over bespoke protocol code, and you can accept a third-party release cadence for MCP version bumps.

Look elsewhere or defer when:

• You need evidence beyond CI green. The release diff touches only composer.json, CI and CHANGELOG.md — no src/ changes. That is good hygiene for a patch, but it means this release tells you nothing new about functional fitness, performance or API stability. If a capability review is outstanding, it remains outstanding.
• You need an LTS/stable-contract guarantee. The 2.x line is young enough that a patch was required to fix an overly tight dependency pin; treat the API as stabilizing rather than settled.
• You cannot take an external HTTP dependency. Guzzle at the core means network egress to a docs backend; if the feature must work air-gapped or fully in-process, this is the wrong shape.
• Your PHP floor is below 8.3 — not supported.
• You need vendor support/SLA. Nothing here indicates commercial backing; the pitch rests on a single-maintainer-style release history (individual PR authors, PR-based changelog).

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost integration that puts our product's documentation inside AI assistants and coding agents via the emerging MCP standard, without us owning protocol maintenance. The latest release is a maintenance patch — no new features, no code changes in the library itself — that removes a dependency conflict which would otherwise have forced a downgrade of the HTTP library three other services rely on. Net effect: adoption is now lower-risk than it was a week ago, and the vendor is tracking the protocol spec and testing against it in CI. The ask is a time-boxed spike, not a platform commitment.

To engineering: v2.0.1 is a dependency-only patch: guzzlehttp/guzzle widened to ^7.8.2|^8.0 with the Guzzle 7 floor unchanged; no src/ diff versus v2.0.0. Testbench dev floors were bumped to compatible patch lines. Runtime support holds at PHP 8.3–8.5 and Laravel 11/12/13, verified in CI at both lowest and latest constraints, plus static analysis, OpenAPI checks and MCP 2026-07-28 conformance fixtures. Practical guidance: pin ^2.0.1 as the floor so Guzzle-8 hosts are not silently downgraded; verify our resolver on a branch before merging; and route the outbound docs calls through our existing HTTP client conventions (timeouts, retries, logging) rather than letting the package own retry policy. The absence of source changes means we still owe ourselves a functional review — CI passing is not the same as the integration behaving correctly against our documentation corpus.