# OpenFGA (Fine-Grained Auth) MCP > OpenFGA (Fine-Grained Auth) connects your AI agent to an open-source system for Relationship-Based Access Control (ReBAC). Manage complex permissions, define access models, and check user rights against specific resources using natural conversation. It lets you program security policies without writing boilerplate API code. ## Overview - **Category:** developer-tools - **Price:** Free - **Tags:** authorization, rebac, access-control, permissions, security-policy, identity-management ## Description You can use this MCP to manage your application's most sensitive logic: who sees what. Instead of manually constructing authorization queries or clicking through multiple administrative dashboards, you talk to your AI agent and it handles the complexity for you. You define entire data stores, model relationships between users and objects, and track all permissions using plain conversation. For example, instead of writing a complex SQL join to check if 'User A' can view 'Document B' because they are part of 'Group C', you simply ask your agent to run the authorization check. The MCP handles reading those relationship tuples and instantly evaluating the result. By connecting this OpenFGA instance through Vinkius, you give your AI client direct, conversational control over your security layer. You can audit models, list all users with specific access rights, or even monitor the health of your entire authorization setup—all without leaving your chat interface. ## Tools ### check_relation Determines if an individual user has the right to access a specific object. ### create_store Sets up a brand new, isolated OpenFGA data store for your application. ### delete_store Permanently removes an existing OpenFGA data store. ### expand_relation Visualizes a complex permission by expanding it into a readable tree structure. ### get_authorization_model Retrieves the definition of a specific authorization model type used in your system. ### get_store Fetches detailed information about an existing OpenFGA store. ### health_check Quickly verifies the operational status of your entire OpenFGA instance. ### list_authorization_models Presents a list of all authorization models currently defined in your system. ### list_objects Retrieves a comprehensive list of every object that a user has access to. ### list_stores Lists all the different OpenFGA stores you have running. ### list_users Finds and lists every user who has been granted a relationship to an object. ### read_changes Reads records of changes made to the system's permission tuples over time. ### read_tuples Queries and retrieves stored relationship data directly from the database. ### write_authorization_model Writes or updates an authorization model definition in your system. ### write_tuples Adds new relationship tuples or removes existing ones to manage permissions. ### batch_check_relations Performs multiple user permission checks in a single request. ## Prompt Examples **Prompt:** ``` List all my OpenFGA stores. ``` **Response:** ``` I've retrieved your OpenFGA stores. You have 3 stores: 'Staging' (ID: 01H1...), 'Production' (ID: 01H2...), and 'Lab' (ID: 01H3...). ``` **Prompt:** ``` Check if user 'anne' has the 'viewer' relation to 'document:doc1' in store 01H1... ``` **Response:** ``` I checked the relation in store 01H1... and the result is 'allowed: true'. User 'anne' does have 'viewer' access to 'document:doc1'. ``` **Prompt:** ``` Create a new OpenFGA store named 'Security-Audit-Logs'. ``` **Response:** ``` The store 'Security-Audit-Logs' has been successfully created with ID: 01J9... ``` ## Capabilities ### Check user permissions Instantly verifies if a specified user has a defined relationship to a particular object. ### Manage data environments Create, list, and delete isolated stores to keep authorization data separate for different applications or testing phases. ### Model system rules Define and retrieve the complex types and relations that govern how your entire system's permissions work. ### Read access history Queries stored relationship tuples to see exactly which users have what rights to which objects. ### Audit object visibility Lists all the resources (objects) a particular user is allowed to interact with. ## Use Cases ### Auditing access after a security incident An engineer needs to know if three different users can view a specific sensitive document. Instead of running three separate manual checks, they prompt their agent: 'List all users who have the viewer relation to document:123.' The agent executes `list_users` and provides an instant list. ### Implementing a new feature with complex rights A backend developer needs to add a new type of permission. They use the MCP to run `get_authorization_model` to see existing patterns, then use `write_authorization_model` to define and test the new rules before committing any code. ### Preparing for multi-environment deployment A DevOps team needs to ensure that their staging environment is completely separate from production. They use the agent to `create_store` specifically named 'Staging' and another called 'Production', ensuring no data overlap. ### Reviewing historical permission changes A security manager wants to see if an admin accidentally granted access last week. They ask the agent to `read_changes` on a specific object, immediately retrieving a timeline of every relationship tuple modification. ## Benefits - You eliminate manual API calls. Instead of writing code to check if a user has permission, you tell your agent to run `check_relation`, and it handles the complex logic immediately. - It keeps your data clean. You can use `list_stores` to keep sensitive environments (like 'Production' vs. 'Staging') completely isolated within separate stores. - You gain full visibility into permissions. Running `read_tuples` lets you query stored relationship data, so you always know exactly who has access to what. - Development gets faster. Developers use the MCP to `write_authorization_model` and instantly test changes without deploying new code just for a policy tweak. - You get immediate health checks. The `health_check` tool lets SREs quickly verify system availability, minimizing downtime due to authorization issues. ## How It Works The bottom line is that you talk naturally about security policies, and the MCP translates those requests into secure, functional data checks. 1. Subscribe to this MCP and provide your OpenFGA API URL and any necessary authentication tokens. 2. Your AI client establishes a connection, allowing it to speak the language of relationship-based access control (ReBAC). 3. You ask your agent questions like, 'Does user X have view rights on object Y?' and get an immediate pass/fail answer. ## Frequently Asked Questions **How does the OpenFGA (Fine-Grained Auth) MCP work with different environments?** You use `list_stores` to see all your available stores. You then use `create_store` or reference an existing store ID when checking a relation, ensuring you're always testing against the correct data environment. **What if I need to check permissions for many users at once using OpenFGA (Fine-Grained Auth)?** Use the `batch_check_relations` tool. This lets you group multiple user and object pairs into one request, making your auditing process much faster than checking them individually. **Can I model a completely new type of permission in OpenFGA (Fine-Grained Auth)?** Yes. You use the MCP to `write_authorization_model` and define your custom types and relations, which makes the rule available for future checks. **Where do I find out what kind of access a specific user has?** You can run `list_objects`. This tool gathers all the objects that a user is entitled to access based on their current relationship tuples in the store. **Is OpenFGA (Fine-Grained Auth) MCP suitable for auditing past changes?** Yes. The `read_changes` tool allows you to query historical records, so you can track when and how a user's permissions were changed over time. **How can I check if a specific user has access to a resource?** You can use the `check_relation` tool. Provide the store ID and the relationship details (user, relation, and object) to get an immediate boolean response on whether the access is permitted. **Can I see the history of changes made to relationship tuples?** Yes, the `read_changes` tool allows you to retrieve the changelog of relationship tuples for a specific store, optionally filtered by object type. **How do I define a new authorization model?** Use the `write_authorization_model` tool. You will need to provide the store ID, the schema version, and a JSON array of type definitions that describe your relations.