@workos/mcp-docs-server 0.1.0 → 0.2.0

package/.docs/organized/docs/demo/definition-list.mdx

@@ -1,35 +0,0 @@
----
-title: Definition List
-description: Demo example of a definition list.
-originalPath: .tmp-workos-clone/packages/docs/content/demo/definition-list.mdx
----
-
-Not a definition item.
-
-Term 1
-: Definition 1
-
-Not a definition item.
-
-Term 2
-: Definition 2
-
-**Term 3**
-: _Definition_ 3
-
-**Term 4**
-: Definition 4
-
-Term 5
-: `Definition 5`
-
-Term 6
-: Definition `6`
-
-Term `7`
-: Definition 7
-
-: Not a definition item.
-
-Not a term
-:

package/.docs/organized/docs/demo/index.mdx

@@ -1,7 +0,0 @@
----
-title: Demo page
-description: This will be SEO description.
-originalPath: .tmp-workos-clone/packages/docs/content/demo/index.mdx
----
-
-These pages are for demo purposes only. They are not meant to be used in production.

package/.docs/organized/docs/demo/punctuation.mdx

@@ -1,37 +0,0 @@
----
-title: Punctionation
-description: This will be SEO description.
-originalPath: .tmp-workos-clone/packages/docs/content/demo/punctuation.mdx
----
-
-The punctuation should use proper typographic symbols, like dashes and curly quotes via [SmartyPants](https://daringfireball.net/projects/smartypants/).
-
-## Apostrophe and smart quotes
-
-"It'll be great" they said. Here's a sentence. "Great", he said. They said it'll be great. "We'll do that" they said. "You'll do that" he said. _They_ can't do that.
-
-`don't replace the apostrophe here`.
-
-`"string"`
-
-```plaintext
-Don't replace the "apostrophe" and "quotes" here too.
-```
-
-## Dashes
-
-One - a hyphen. Two – an en-dash. Three—an em dash.
-
-All should be transformed into en-dashes.
-
-Code should not be transformed:
-
-```plaintext
-One - a hyphen. Two – an en-dash. Three—an em dash.
-```
-
-`One - a hyphen. Two – an en-dash. Three—an em dash.`
-
-## Ellipsis
-
-Counting...

package/.docs/organized/docs/demo/replacements.mdx

@@ -1,26 +0,0 @@
----
-title: Code Block Replacements
-description: Test page for the code block replacements
-originalPath: .tmp-workos-clone/packages/docs/content/demo/replacements.mdx
----
-
-```js
-'foo@foo-corp.com foo-corp.com foo@foo-corp.com';
-```
-
-```js
-'foo-corp.com';
-```
-
-```js
-'afoo-corp.com';
-```
-
-```js
-'foo-corp.com foo-corp.com';
-```
-
-```js
-const api_key = 'sk_example_123456789';
-const client_id = 'client_123456789';
-```

package/.docs/organized/docs/demo/table.mdx

@@ -1,26 +0,0 @@
----
-title: Table
-description: Demo example of a table.
-originalPath: .tmp-workos-clone/packages/docs/content/demo/table.mdx
----
-
-## Default table
-
-| First Header | Second Header |
-| ------------ | ------------- |
-| Content Cell | Content Cell  |
-| Content Cell | Content Cell  |
-
-## Formatting with `inline code blocks`, `links`, and `text styles`
-
-| Command      | Description                                                              |
-| ------------ | ------------------------------------------------------------------------ |
-| `git status` | List all _new or modified_ files                                         |
-| `git diff`   | Show [file](https://workos.com) differences that **haven’t been** staged |
-
-## Text alignment
-
-| Left-aligned | Center-aligned | Right-aligned |
-| ------------ | -------------: | ------------: |
-| git status   |     git status |    git status |
-| git diff     |       git diff |      git diff |

package/.docs/organized/docs/demo/tabs.mdx

@@ -1,17 +0,0 @@
----
-title: Tabs
-description: Test page for the tabs component
-originalPath: .tmp-workos-clone/packages/docs/content/demo/tabs.mdx
----
-
-- | Directory User
-
-  Whether to parse strikethrough with a single tilde (boolean, default: true).
-
-- | List Directory
-
-  Get the details of an existing Directory User.
-
-- | Get Directory Group
-
-  <CodeBlock title="Example Code" file="webhook-endpoint" />

package/.docs/organized/docs/fga/identity-provider-sessions.mdx

@@ -1,68 +0,0 @@
----
-title: Identity Provider Sessions
-description: Learn how to configure FGA to use your identity provider's ID tokens.
-originalPath: .tmp-workos-clone/packages/docs/content/fga/identity-provider-sessions.mdx
----
-
-## Overview
-
-Fine-Grained Authorization (FGA) is commonly used to enforce detailed authorization on your application's backend. However, it can also be utilized on the frontend to perform access checks directly within your client application. FGA supports the use of ID tokens issued by identity providers, allowing you to make user-specific authorization decisions on the frontend. This not only improves the security of your application but also enables you to present a customized user interface and experience based on the access levels of different users.
-
-## Before getting started
-
-To get the most out of this guide, you’ll need:
-
-- A [WorkOS account](https://dashboard.workos.com/)
-- Your WorkOS [Client ID](/glossary/client-id)
-- The JSON Web Key Set (JWKS) endpoint of your identity provider. ([AuthKit](/reference/user-management/session-tokens/jwks))
-- A schema set up in a FGA environment. If you haven't done so, check out our [Quick Start](/fga/quick-start) to create one.
-
----
-
-## (1) Configure your JWKS URL
-
-A JWKS URL is an endpoint that contains the set of public keys used to verify any JSON Web Tokens (JWTs) issued by your provider. Currently, FGA only supports JWTs that are signed using the **RS256** signing algorithm.
-
-Common identity provider JWKS URLs:
-
-- **WorkOS User Management**: `https://api.workos.com/sso/jwks/{clientId}`
-- **Auth0**: `https://{yourDomain}/.well-known/jwks.json`
-- **Google/Firebase**: `https://www.googleapis.com/oauth2/v3/certs`
-
-You can set your JWKS URL in the _Configuration_ section of the [FGA Dashboard](https://fga.workos.com/configuration).
-
-![FGA JWKS Configuration](https://images.workoscdn.com/images/35f59a84-d1ad-4c78-8be4-210678a6c161.png?auto=format&fit=clip&q=50)
-
-## (2) Create a context for FGA
-
-Next, let's create a [context](https://react.dev/learn/passing-data-deeply-with-context) for FGA that will allow us to make checks from anywhere in our application.
-
-The FGA context will set and track the user's session token and expose a `check` method that we can access anywhere in our application where we need to make an access check before displaying a UI element or performing an action.
-
-<CodeBlock title="Create FGA context" file="jwks-create-fga-context" />
-<CodeBlock
-  title="Wrap your application with the created provider"
-  file="jwks-wrap-with-provider"
-/>
-
-## (3) Set the session token when a user logs in
-
-Before we begin making access checks in our application, we need to provide a server-generated session token and set it in our FGA context.
-
-<CodeBlock title="Set session token on login" file="jwks-set-session-token" />
-
-## (4) Make check requests from your app
-
-Now that we've created our FGA context and set the session token, we can start making check requests from our client application.
-
-The main difference here from regular check requests is that we don't need to provide a subject in our checks because all checks will be scoped to the user specified by the user ID in the session token.
-
-Let's make a check to see if the user has the `viewer` relation on `report:7` before displaying the report's data.
-
-<CodeBlock title="Make check request" file="jwks-component-check" />
-
----
-
-## Summary
-
-In this guide, we demonstrated how to perform authorization checks directly in a client application using ID tokens from our identity provider. We created a context to manage the user's session token upon login, which is then used for subsequent access checks. This approach allows us to deliver a secure and personalized experience to users within our application, leveraging FGA for fine-grained access control.

package/.docs/organized/docs/fga/local-development.mdx

@@ -1,155 +0,0 @@
----
-title: Local Development
-description: >-
-  Learn how to setup your local development environment with FGA using the FGA
-  Dev Docker image for isolated testing and schema development.
-originalPath: .tmp-workos-clone/packages/docs/content/fga/local-development.mdx
----
-
-## Overview
-
-When developing with FGA, you can either connect to a managed WorkOS FGA instance or run a local FGA instance using the [`fga-dev` Docker image](https://gallery.ecr.aws/workos/fga-dev). Each option has its own advantages depending on your workflow. This guide will help you choose the best approach and walk you through setting up a local instance if that fits your needs.
-
-### Managed FGA Instance
-
-Best for testing against production-like infrastructure and when you need persistent, shared data.
-
-| Pros                                                           | Cons                                                                |
-| -------------------------------------------------------------- | ------------------------------------------------------------------- |
-| Data persists and is accessible by multiple clients            | Data is shared (multiple consumers can overwrite each other's data) |
-| Uses production infrastructure for performance and reliability | Consumes operation credits                                          |
-
-### Local FGA Instance
-
-Best for isolated development and testing especially when you want to avoid using operation credits or need a clean environment for each run (such as in CI).
-
-| Pros                           | Cons                                       |
-| ------------------------------ | ------------------------------------------ |
-| Isolated test environment      | You must manage setup and teardown of data |
-| Does not use operation credits | Uses local resources and is not scalable   |
-
-The `fga-dev` Docker image provides a fully self-contained FGA environment using SQLite and local caching. This setup is **not intended for production** but is fine for local development, CI, and integration testing. It is less scalable than the managed instance because it cannot handle high concurrency, complex models, or large datasets.
-
-This guide will show you how to use the [`fga-dev` Docker image](https://gallery.ecr.aws/workos/fga-dev) to spin up an isolated FGA instance on your machine.
-
----
-
-## Prerequisites
-
-To start this guide, you'll need:
-
-- [Docker](https://www.docker.com/get-started) installed on your machine
-- A [WorkOS account](https://dashboard.workos.com/) (for API keys)
-- Your WorkOS [API Key](/glossary/api-key)
-
----
-
-## Running fga-dev Locally
-
-### Option 1: Using Docker Compose (Recommended)
-
-Create a `docker-compose.yaml`:
-
-```yaml title="docker-compose.yaml"
-version: '3.8'
-
-services:
-  fga-dev:
-    image: public.ecr.aws/workos/fga-dev:latest-arm64
-    user: root # Run as root to avoid permission issues with mounted volumes (non-production only)
-    volumes:
-      - fga-dev-volume:/data:rw,cached # Persist data between runs
-    ports:
-      - '8001:8001'
-    environment:
-      FGA_DEV_PORT: 8001
-      FGA_DEV_AUTH_API_KEY: <your_workos_api_key> # Your staging WorkOS API key to authenticate the dev image
-      FGA_DEV_TEST_API_KEY: test_key # A mock API key to authenticate FGA requests from your application
-
-volumes:
-  fga-dev-volume:
-```
-
-#### Usage
-
-1. **Start the server:**
-
-   ```shell
-   docker compose up -d
-   ```
-
-2. **Configure your app:**
-
-   - Point your application's WorkOS SDK or CLI to the proper host.
-   - Use `test_key` as the API key for FGA requests from your app.
-
-     | Environment                 | API Host                         |
-     | --------------------------- | -------------------------------- |
-     | Local machine               | http://localhost:8001            |
-     | Separate Docker container   | http://host.docker.internal:8001 |
-     | Same Docker Compose network | http://fga-dev:8001              |
-
-> If you’re using the WorkOS SDK, you can set the API Hostname option to point to your local FGA instance. Since each SDK instance supports only one API Host, you may need to create a separate SDK instance specifically for FGA when testing against the local service.
-
-3. **Develop:**
-
-   Apply schemas, create warrants, and test locally. All data persists in the Docker volume.
-
-   See [Schema Management](/fga/schema-management) for how to apply a schema to your local instance and test authorization checks.
-
-4. **Shut down:**
-
-   ```shell
-   docker compose down
-   ```
-
-5. **Clear all data (optional):**
-
-   ```shell
-   docker volume rm fga-dev-volume
-   ```
-
-> Tip: Add a secondary Docker Compose service to seed your local instance with test data on startup.
-
----
-
-### Option 2: Running a Docker Container
-
-You can also run the `fga-dev` image directly using `docker run` if you prefer not to use Docker Compose.
-
-```shell
-docker run -d \
-  --name fga-dev \
-  -p 8001:8001 \
-  -e FGA_DEV_PORT=8001 \
-  -e FGA_DEV_AUTH_API_KEY=<your_workos_api_key> \
-  -e FGA_DEV_TEST_API_KEY=test_key \
-  -v fga-dev-volume:/data:rw \
-  --user root \
-  public.ecr.aws/workos/fga-dev:latest-arm64
-```
-
-To stop and remove the container:
-
-```shell
-docker stop fga-dev && docker rm fga-dev
-```
-
-To remove the volume and reset all data:
-
-```shell
-docker volume rm fga-dev-volume
-```
-
----
-
-## Best Practices
-
-Consider the following best practices to ensure a smooth local development experience with FGA:
-
-- **Isolate test data**: Use unique resource IDs to avoid collisions which is especially critical when working with shared or managed instances.
-- **Automate environment setup**: Script the schema and warrant creation on first startup. This makes your development and CI pipelines more reliable and repeatable.
-- **Clean up regularly**: Tear down and reset your environment when needed to avoid stale data and hidden state, which can lead to confusing behavior.
-- **Choose the right environment**: Use a managed instance for shared, persistent testing; use the local fga-dev container for isolated development or CI.
-
----

package/.docs/organized/docs/fga/modeling/abac.mdx

@@ -1,107 +0,0 @@
----
-title: Attribute-Based Access Control (ABAC)
-description: >-
-  Learn how to use policies to implement a pure attribute-based access control
-  (ABAC) model in Fine-Grained Authorization (FGA).
-originalPath: .tmp-workos-clone/packages/docs/content/fga/modeling/abac.mdx
----
-
-> Explore the example from this guide [in the FGA Playground](https://explore.fga.workos.com/playground?example=abac), where you can interact with the schema, warrants, and access checks in real-time!
-
-Attribute-Based Access Control (ABAC) is an authorization model that grants access based on attributes of users, resources, environments, and other contextual factors.
-
-FGA allows you to implement a pure ABAC model, where permissions rely solely on attributes without requiring warrant data. By centralizing authorization policies, FGA eliminates hardcoded access logic, making your system more scalable and maintainable.
-
-> **Note**: Starting with a pure ABAC model can be an effective way to remove hardcoded authorization logic while keeping policies flexible. As your needs evolve, you can seamlessly integrate Relationship-Based Access Control (ReBAC) to support permissions based on user-resource relationships, such as team memberships, delegated roles, or hierarchical access.
-
-## When to Use Pure ABAC?
-
-ABAC is ideal when access rules are complex and depend on multiple dynamic factors such as:
-
-- **Entitlements**: feature access based on plan level.
-- **Feature flags**: enabling experimental features for specific groups.
-- **Domain-specific data**: security constraints based on specific resource data attributes.
-- **Role membership**: access based on user roles or attributes that are not strictly hierarchical.
-- **Temporal data**: granting temporary access based on time-based or location-based policies.
-
-## Schema
-
-```fga
-version 0.3
-
-type user
-
-type organization
-  relation view_financial_records []
-  inherit view_financial_records if
-    // Policies can be combined with inheritance rules
-    all_of
-      policy user_in_organization
-      policy is_finance_manager
-
-  relation view_research_data []
-  inherit view_research_data if
-    all_of
-      policy user_in_organization
-      policy is_assigned_researcher
-      policy is_within_working_hours
-
-type document
-  relation edit []
-  inherit edit if
-    policy edit_document
-
-policy user_in_organization(user_attributes map, organization_id string) {
-  user_attributes.organization_id == organization_id
-}
-
-policy is_finance_manager(user_attributes map) {
-  user_attributes.department == "finance" &&
-  "manager" in user_attributes.roles
-}
-
-policy is_assigned_researcher(user_attributes map, project_id string) {
-  user_attributes.role == "manager" &&
-  project_id in user_attributes.assigned_projects
-}
-
-policy is_within_working_hours(access_time_epoch_seconds integer) {
-    let second_since_midnight = access_time_epoch_seconds % 86400;
-
-    // 9 AM (32400s) to 5 PM (61200s)
-    second_since_midnight >= 32400 && second_since_midnight <= 61200
-}
-
-policy edit_document(user_attributes map, document_attributes map) {
-    let user_is_document_editor = "document_editor" in user_attributes.roles;
-
-    let draft_status = document_attributes.status == "draft";
-
-    let user_can_access_document = document_attributes.organization_id == user_attributes.organization_id;
-
-    user_is_document_editor && draft_status && user_can_access_document
-}
-
-```
-
-## Example
-
-### (1) Apply the schema
-
-Create a file called `schema.txt` containing the schema definition from above. Then use the CLI to apply this schema to your WorkOS FGA environment.
-
-> Note: make sure to select the correct environment with the [CLI](https://github.com/workos/workos-cli?tab=readme-ov-file#usage)
-
-```shell
-workos fga schema apply schema.txt
-```
-
----
-
-### (2) Check access
-
-With our environment setup, we can check the user's permissions.
-
-<CodeBlock title="Check user permissions" file="abac-check" />
-
----

package/.docs/organized/docs/fga/modeling/blocklist.mdx

@@ -1,84 +0,0 @@
----
-title: Blocklists
-description: >-
-  Blocklist users from accessing certain resources based on specific attributes
-  or warrants
-originalPath: .tmp-workos-clone/packages/docs/content/fga/modeling/blocklist.mdx
----
-
-> Explore the example from this guide [in the FGA Playground](https://explore.fga.workos.com/playground?example=blocklist), where you can interact with the schema, warrants, and access checks in real-time!
-
-A blocklist allows systems to deny access to specific users or sessions based on contextual data or warrants.
-
-## When to Use It?
-
-- A user IP address is associated with suspicious behavior
-- A user is flagged for abuse
-- A user is subject to temporary access restrictions (e.g., after multiple failed login attempts)
-
-This approach combines relationship-based access control (ReBAC) with attribute-based access control (ABAC), giving you fine-grained control without complicating your core permissions model.
-
-## Example Applications
-
-- **Content Moderation**: Block users from viewing or interacting with content based on their IP address.
-- **E-commerce Systems**: Block users from purchasing or viewing products based on behavior patterns.
-- **Banking and Finance**: Deny access based on fraud scores or geolocation mismatches.
-
-## Schema
-
-```fga
-version 0.3
-
-type user
-
-type store
-  relation member [user]
-
-type item
-  relation owner [store]
-  relation blocked [user]
-
-  relation view []
-  inherit view if
-    all_of
-      relation member on owner [store]
-      // Users are blocked either explicitly or with the ip_not_allowed policy
-      none_of
-        relation blocked
-        policy ip_not_allowed
-
-
-policy ip_not_allowed(ip_risk_score integer) {
-  ip_risk_score > 75
-}
-```
-
-## Example
-
-### (1) Apply the schema
-
-Create a file called `schema.txt` containing the schema definition from above. Then use the CLI to apply this schema to your WorkOS FGA environment.
-
-> Note: make sure to select the correct environment with the [CLI](https://github.com/workos/workos-cli?tab=readme-ov-file#usage)
-
-```shell
-workos fga schema apply schema.txt
-```
-
----
-
-### (2) Create warrants
-
-Create warrants that associate users, stores, and items. Add a blocked user to an item.
-
-<CodeBlock title="Create warrants" file="blocklist-create-warrants" />
-
----
-
-### (3) Check access
-
-With our environment setup, we can check the user's permission to view items.
-
-<CodeBlock title="Check if a user can view an item" file="blocklist-check" />
-
----

package/.docs/organized/docs/fga/modeling/conditional-roles.mdx

@@ -1,99 +0,0 @@
----
-title: Conditional Roles
-description: >-
-  Combine relationship-based access control (ReBAC) with attribute-based access
-  control (ABAC) to create conditional roles.
-originalPath: .tmp-workos-clone/packages/docs/content/fga/modeling/conditional-roles.mdx
----
-
-> Explore the example from this guide [in the FGA Playground](https://explore.fga.workos.com/playground?example=conditional_roles), where you can interact with the schema, warrants, and access checks in real-time!
-
-Use FGA to combine **Relationship-Based Access Control (ReBAC)** and **Attribute-Based Access Control (ABAC)**. Define roles that are bound to specific resources and change based on specific conditions. This allows for more granular control over who can do what, when, and under which circumstances.
-
-## When to Use It
-
-Use conditional roles when you cannot determine access by relationships alone. For example, a team member may be allowed to approve some expenses, but only if they are below a certain amount or belong to specific cost centers. As systems grow in complexity, pure ReBAC or ABAC models may become limiting. Conditional roles help bridge that gap with clear, composable rules.
-
-## Example Applications
-
-- **Expense Management**: Finance managers can approve expense reports only if the amount is below a defined threshold and aligned with their assigned cost centers.
-- **Procurement**: Department heads may approve purchase orders only after completing mandatory compliance or budget authorization training.
-- **Healthcare Systems**: Authorized clinicians can access sensitive health records only if the individual is assigned to their care team and the access occurs during regulated working hours.
-
-## Schema
-
-```fga
-version 0.3
-
-type user
-
-type team
-  relation finance_admin [user]
-  relation finance_manager [user]
-
-  inherit finance_manager if
-      relation finance_admin
-
-type expense
-  relation approval_team [team]
-  relation submitter [user]
-
-  relation approve []
-  inherit approve if
-    any_of
-      all_of
-        relation finance_manager on approval_team [team]
-        policy can_approve_amount
-      all_of
-        relation finance_admin on approval_team [team]
-        policy is_high_value_expense
-
-policy can_approve_amount(expense_attributes map, user_attributes map) {
-  let can_approve_cost_center = expense_attributes.cost_center in user_attributes.approved_cost_centers;
-  let can_approve_amount = expense_attributes.amount <= 1000;
-
-  can_approve_cost_center && can_approve_amount
-}
-
-policy is_high_value_expense(expense_attributes map) {
-  expense_attributes.amount > 1000
-}
-```
-
-## Example
-
-### (1) Apply the schema
-
-Create a file called `schema.txt` containing the schema definition from above. Then use the CLI to apply this schema to your WorkOS FGA environment.
-
-> Note: make sure to select the correct environment with the [CLI](https://github.com/workos/workos-cli?tab=readme-ov-file#usage)
-
-```shell
-workos fga schema apply schema.txt
-```
-
----
-
-### (2) Create warrants
-
-Create warrants that associate users, teams, and expenses. The example schema defines the following relationships:
-
-- users with teams (using the `finance_admin` or `finance_manager` roles)
-- teams with expenses (using the `approval_team` relation)
-
-Let's create a few warrants between team `finance-1`, expense `expense-1`, and user `user_2oDscjroNWtzxzYEnEzT9P7VYEe`:
-
-<CodeBlock title="Create warrants" file="conditional-roles-create-warrants" />
-
----
-
-### (3) Check access
-
-With our environment setup, we can check the user's permission to approve expenses.
-
-<CodeBlock
-  title="Check if a user can approve an expense"
-  file="conditional-roles-check"
-/>
-
----