- How do I install heihallo/mcp-kit in a Laravel app?
- Install it with composer require heihallo/mcp-kit, then register the service provider if your Laravel version does not auto-discover it. Publish the package config, declare your first abilities, and point an MCP client such as Claude Desktop, Claude Code, or Cursor at the endpoint or process. A read-only ability is the safest first integration test.
- Which Laravel and PHP versions does mcp-kit support?
- The package is positioned for Laravel 10 and 11 on PHP 8.1 and 8.2 or newer, but you should confirm the exact Composer constraints for the version you pin. If you use the Laravel 11 slim skeleton, verify that service provider auto-discovery and middleware alias registration behave as documented. Lock the package version and test against your actual application skeleton.
- How do I declare abilities in mcp-kit's ability catalogue?
- The ability catalogue is Laravel-native and maps onto the Gate and Policy vocabulary your application already uses. The exact declaration style, whether a config array, PHP attribute, or interface, should be confirmed against the README and source for your pinned version because the schema may still change before 1.0. Add tests that fail when the MCP catalogue drifts from your actual Gate definitions.
- Does mcp-kit support preview and confirm for write actions?
- Yes, preview and confirm writes are a headline feature intended to make agent-driven mutations easier to defend. Before exposing real mutations, verify whether confirmation is stateful, what prevents replay, how a client could bypass the confirm turn, and what the timeout behavior is. Start with low-blast-radius writes and expand only after audit coverage is verified end to end.
- What should mcp-kit's audit middleware capture?
- At minimum, expect the audit trail to capture actor, token, tool name, arguments, result, and latency. Confirm where events are sunk, whether records are tamper-evident, and how they can be forwarded to your SIEM or log pipeline. Audit coverage is the main control that makes agent tool invocation defensible in staff tooling.
- How do per-person tokens work in mcp-kit?
- Per-person tokens follow the same mental model as Sanctum or Passport tokens: each staff member gets a credential tied to their identity and permissions. You should verify the full lifecycle for your version, including issuance, scoping, rotation, revocation, and storage at rest. Prefer hashed storage and short-lived, narrowly scoped tokens for production use.
- Which MCP transports and spec revisions does mcp-kit support?
- MCP clients commonly use stdio, SSE, or streamable HTTP, but the package's exact transport support and tracked spec revision must be confirmed in its documentation and source. MCP is still changing, so pin protocol expectations and test with your real client rather than relying only on the README. Ask the maintainer how quickly spec updates are tracked.
- Is mcp-kit production-ready for staff tooling?
- Treat it as promising but early-stage: the package has little external validation, a single-maintainer profile, and likely a pre-1.0 ability schema. The design is sensible, but the security model around tool invocation and confirm-gated writes has not had broad ecosystem scrutiny. Sequence adoption as a spike, a small internal pilot with read-only abilities, then hardening before enabling writes.
- How does mcp-kit handle per-user assistant memory and PII?
- The package includes per-user assistant memory, so scoping must be guaranteed through the authenticated token or user identity rather than client-supplied identifiers. Define what PII may be stored, how long it is retained, and whether a single user's memory can be deleted on request. Verify these controls in code and document them before onboarding staff.
- How should I test mcp-kit before rolling it out?
- Start with a spike: install the package, expose one read-only ability, attach a real MCP client, and confirm the audit log records actor, tool, and arguments. Then run a pilot with three to five internal staff, five to ten read abilities, and at most one or two confirm-gated writes. Harden token rotation, memory retention, and audit forwarding before expanding the ability catalogue.