An MCP Tool Schema Is Not an Authorization Check: A Laravel Design Pattern

The MCP tool schema alone does not provide authorization checks. While it aids in constructing a call by specifying input parameters like an invoice ID and reason, it does not determine who is permitted to perform the action, such as refunding a particular invoice. The responsibility lies with the server to handle input validation, access controls, rate limiting, and output sanitization.

Additionally, the specification recommends confirming sensitive operations within the chat interface, but this confirmation should not replace server-side enforcement. A layered security approach is advised, involving authentication and throttling at the HTTP level, followed by server-side validation of the arguments. After validating the invoice details, the server must authorize the action on the specific record by consulting policies.

Laravel's gates and policies are designed for such decisions. The flow includes steps like authenticating the caller, validating the input, loading the invoice in the appropriate tenant scope, authorizing the refund action, checking for idempotency and current state, executing one mutation, and recording relevant details. Tools should be designed with a read-only preview_refund endpoint, followed by a commit_refund endpoint that rechecks authorization and state.

The response should contain only necessary information for the assistant, like the operation ID, status, and a safe summary. Avoid leaking sensitive data or implementation details. Before exposing a write tool, ensure no unauthenticated caller can reach the endpoint, all arguments are validated on the server, a policy checks the actor against the specific record, retries are safe and observable, and the output does not reveal sensitive data.