data
OpenFGA MCP, CLI, and Lua Integration for AI Agents
OpenFGA integration docs for AI agents: MCP gateway setup, OpenFGA CLI commands, Lua API reference, credentials, and function schemas.OpenFGA for agents
Credentials can be configured manually in web or CLI hosts.
Use this integration from Lua code mode, the headless integrations CLI, or the KosmoKrator MCP gateway. The same package metadata powers all three surfaces.
Agent Surfaces
Machine-Readable Metadata
Function Catalog
| Function | Type | Parameters | Description |
|---|---|---|---|
openfga.openfga_get_configuration | Read read | 0 | [Experimental] The GetConfiguration API returns metadata about the Policy Decision Point (PDP) including its name, version, supported endpoints, and capabilities. This endpoint follows the AuthZEN specification for PDP discovery. Following the AuthZEN spec's m |
openfga.openfga_list_stores | Read read | 0 | Returns a paginated list of OpenFGA stores and a continuation token to get additional stores. The continuation token will be empty if there are no more stores. Official OpenFGA endpoint: GET /stores. |
openfga.openfga_create_store | Write write | 0 | Create a unique OpenFGA store which will be used to store authorization models and relationship tuples. Official OpenFGA endpoint: POST /stores. |
openfga.openfga_get_store | Read read | 0 | Returns an OpenFGA store by its identifier Official OpenFGA endpoint: GET /stores/{store_id}. |
openfga.openfga_delete_store | Write write | 0 | Delete an OpenFGA store. This does not delete the data associated with the store, like tuples or authorization models. Official OpenFGA endpoint: DELETE /stores/{store_id}. |
openfga.openfga_evaluation | Write write | 0 | [Experimental] The Evaluation API determines whether a subject is authorized to perform an action on a resource. This endpoint implements the AuthZEN Access Evaluation API specification. ## Request Structure The request requires three components: - **subject** |
openfga.openfga_evaluations | Write write | 0 | [Experimental] The Evaluations API allows batch authorization checks in a single request. It supports request-level defaults for subject, action, resource, and context that can be overridden per evaluation item. ## Evaluation Semantics The `options.evaluations |
openfga.openfga_action_search | Write write | 0 | [Experimental] The ActionSearch API returns all actions (relations) that a subject can perform on a specific resource. This is useful for answering questions like "What can Anne do with this document?" or building dynamic UIs that show only the actions a user |
openfga.openfga_resource_search | Write write | 0 | [Experimental] The ResourceSearch API returns all resources of a given type that a subject has a specific action (relation) on. This is useful for answering questions like "What documents can Anne read?" or "What folders can Bob administer?" The resource type |
openfga.openfga_subject_search | Write write | 0 | [Experimental] The SubjectSearch API returns all subjects that have a specific action (relation) on a given resource. This is useful for answering questions like "Who can read this document?" or "Who can administer this folder?" Results can be filtered by subj |
openfga.openfga_read_assertions | Read read | 0 | The ReadAssertions API will return, for a given authorization model id, all the assertions stored for it. Official OpenFGA endpoint: GET /stores/{store_id}/assertions/{authorization_model_id}. |
openfga.openfga_write_assertions | Write write | 0 | The WriteAssertions API will upsert new assertions for an authorization model id, or overwrite the existing ones. An assertion is an object that contains a tuple key, the expectation of whether a call to the Check API of that tuple key will return true or fals |
openfga.openfga_read_authorization_models | Read read | 0 | The ReadAuthorizationModels API will return all the authorization models for a certain store. OpenFGA's response will contain an array of all authorization models, sorted in descending order of creation. ## Example Assume that a store's authorization model has |
openfga.openfga_write_authorization_model | Write write | 0 | The WriteAuthorizationModel API will add a new authorization model to a store. Each item in the `type_definitions` array is a type definition as specified in the field `type_definition`. The response will return the authorization model's ID in the `id` field. |
openfga.openfga_read_authorization_model | Read read | 0 | The ReadAuthorizationModel API returns an authorization model by its identifier. The response will return the authorization model for the particular version. ## Example To retrieve the authorization model with ID `01G5JAVJ41T49E9TT3SKVS7X1J` for the store, cal |
openfga.openfga_batch_check | Write write | 0 | The `BatchCheck` API functions nearly identically to `Check`, but instead of checking a single user-object relationship BatchCheck accepts a list of relationships to check and returns a map containing `BatchCheckItem` response for each check it received. An as |
openfga.openfga_read_changes | Read read | 0 | The ReadChanges API will return a paginated list of tuple changes (additions and deletions) that occurred in a given store, sorted by ascending time. The response will include a continuation token that is used to get the next set of changes. If there are no ch |
openfga.openfga_check | Write write | 0 | The Check API returns whether a given user has a relationship with a given object in a given store. The `user` field of the request can be a specific target, such as `user:anne`, or a userset (set of users) such as `group:marketing#member` or a type-bound publ |
openfga.openfga_expand | Write write | 0 | The Expand API will return all users and usersets that have certain relationship with an object in a certain store. This is different from the `/stores/{store_id}/read` API in that both users and computed usersets are returned. Body parameters `tuple_key.objec |
openfga.openfga_list_objects | Write write | 0 | The ListObjects API returns a list of all the objects of the given type that the user has a relation with. To arrive at a result, the API uses: an authorization model, explicit tuples written through the Write API, contextual tuples present in the request, and |
openfga.openfga_list_users | Write write | 0 | The ListUsers API returns a list of all the users of a specific type that have a relation to a given object. To arrive at a result, the API uses: an authorization model, explicit tuples written through the Write API, contextual tuples present in the request, a |
openfga.openfga_read | Write write | 0 | The Read API will return the tuples for a certain store that match a query filter specified in the body of the request. The API doesn't guarantee order by any field. It is different from the `/stores/{store_id}/expand` API in that it only returns relationship |
openfga.openfga_streamed_list_objects | Write write | 0 | The Streamed ListObjects API is very similar to the the ListObjects API, with two differences: 1. Instead of collecting all objects before returning a response, it streams them to the client as they are collected. 2. The number of results returned is only limi |
openfga.openfga_write | Write write | 0 | The Write API will transactionally update the tuples for a certain store. Tuples and type definitions allow OpenFGA to determine whether a relationship exists between an object and an user. In the body, `writes` adds new tuples and `deletes` removes existing t |