Skip to main content
Muveya’s Model Context Protocol server lets a compatible AI assistant read authorized information about your dental clinic. It uses the same data and permission checks as Console and the /v1 API.

​
How authorization works

An MCP client first receives 401 with a WWW-Authenticate pointer to Muveya’s protected resource metadata. The client discovers the Stytch authorization server and opens the browser. Muveya Console asks you to sign in if needed, then shows the application, clinic and permissions for your decision. After you select Authorize, the client receives an access token and sends it with each MCP request. Muveya validates that the token was issued for this MCP resource, that the Connected App grant still exists, and that your membership is active. Each tool receives only the intersection of the delegated OAuth scopes and your current permissions and site access. An API key for /v1 cannot authenticate /mcp.

​
What the server can read

The server lists ten tools and four resources. Current OAuth scopes can authorize catalog, stock, order and management reads. Some listed tools need approvals.decide or fulfillment.pick, which are outside the current read-only OAuth scope set, so those calls return common.forbidden. See tools and resources for the exact contract. Sensitive fields are removed on the server when you lack their permission. The connection cannot expand its access by naming another clinic or by asking the assistant to ignore a rule. Every tool and resource call is recorded with the person, scope and outcome, without the full request or a patient reference. Connect a client to start the sign-in and authorization flow.