# Reqres MCP > Reqres gives your AI agent a sandbox API to run against. Stop building backends just for testing. This server lets you mock user creation, manage project records (CRUD), simulate logins, and pull real-world resource data—all without setting up a single database. It's the industry standard for front-end prototyping and advanced agent development. ## Overview - **Category:** developer-tools - **Price:** Free - **Tags:** api-testing, mock-data, prototyping, user-management, rest-api ## Description Reqres gives your agent a sandbox API it can run against. Stop building backends just for testing—you'll spend too much time on stuff that doesn't matter. This server lets you mock user creation, manage project records (CRUD), simulate logins, and pull real-world resource data without setting up a single database or worrying about actual persistence. It’s the standard toolkit for front-end prototyping and advanced agent development. **User Management:** You can run through full identity flows by simulating new registrations using `register_demo` or running a login via `login_demo`, both of which return an access token you need. If you're testing user linking, use `request_magic_link` to kick off the magic link process for an app user, and then verify that link with `verify_magic_link` to get the session token. To check a specific person’s profile, call `get_user` with their unique ID; if you just need details on who's running the tool, use `get_me`. You can list users across the whole system using `list_users`, or grab a paginated list of them with `agent_users`. For single-handedly managing records, you've got `create_user` to simulate making a demo user account, and `delete_user` removes that specified profile from the Demo API environment. To update a user’s details partially, call `patch_user`; if you need to change every bit of their info, use `update_user`. **Project Record Management:** When it comes to data collections—your project records—you can handle the full lifecycle. You'll start by generating and saving a new record into any project collection using `create_record`. If you need to build out a user-specific record, use `create_app_record` which saves it within an application collection scoped to the current user. To pull data for one specific item, call `get_record` with its details; otherwise, you can fetch all records belonging to the current user by using `list_app_records`. If you need a comprehensive list of all items in a project collection, `list_records` gives you paginated results, and you can get multiple users' data by calling `agent_orders` which retrieves orders along with related info. To update an existing record, you have two options: use `patch_record` to change only specific fields (a partial update), or call `update_record` if you need to replace the entire record with new data (full replacement). When a record is done and needs clearing out, `delete_record` removes it from any defined project collection. **Flow Testing & Utilities:** You can simulate system failures for robust testing by calling `trigger_scenario`, forcing the agent sandbox into a specific error state. To check if your agent's connection is stable, run `agent_health`; this verifies the health and rate limit status of the Agent Sandbox. If you need to know what failure states are available, `agent_scenarios` lists all available scenarios within the environment. For validating external data types, like Pantone colors, `list_colors` retrieves a list of resource colors from the Demo API. When working with applications, you can see every record belonging to your current user by running `list_app_records`, and you can also check how many users are available using `list_users`. The system also supports checking if there's an issue when listing records through `agent_orders`. *It's basically a complete mock environment for testing everything from identity to data persistence.* ## Tools ### agent_health Checks the health and rate limit status for the Agent Sandbox. ### agent_orders Retrieves orders, including related data, from the Agent Sandbox. ### agent_scenarios Lists all available failure scenarios within the Agent Sandbox environment. ### agent_users Gets a paginated list of users, supporting cursor-based pagination in the Agent Sandbox. ### create_app_record Creates and saves a new user-scoped record within an application collection. ### create_record Generates and saves a new record into a specified project collection. ### create_user Simulates the creation of a demo user account, echoing the data back to confirm the operation. ### delete_record Removes an existing record from any defined project collection. ### delete_user Deletes a specified user profile in the Demo API environment. ### get_me Retrieves information about the current application user running the tool call. ### get_record Fetches data for one specific record from a project collection using its details. ### get_user Gets the full profile of a single user by their unique ID in the Demo API. ### list_app_records Lists all records within an application collection that belong to the current user. ### list_colors Retrieves a list of resource colors, such as Pantone data, from the Demo API. ### list_records Fetches a paginated list of all records within a project collection. ### list_users Lists multiple users in the Demo API, supporting pagination for large datasets. ### login_demo Simulates user login using fixture credentials and returns an access token. ### patch_record Updates only specific fields of a record in a project collection (partial update). ### patch_user Allows for partial updates to a demo user's profile, confirming the changes. ### register_demo Simulates new user registration using fixture credentials and returns an ID/token. ### request_magic_link Initiates a magic link request for a specified App User to complete login. ### trigger_scenario Forces the Agent Sandbox into a specific failure state to test error handling. ### update_record Replaces an entire record in a project collection with new data (full replacement). ### update_user Updates all details of a demo user's profile, confirming the complete change. ### verify_magic_link Validates a received magic link token and issues a session access token. ## Prompt Examples **Prompt:** ``` List the users on the second page of the demo API. ``` **Response:** ``` I've retrieved the users from page 2. You have users like Michael Lawson (ID: 7) and Lindsay Ferguson (ID: 8). Would you like the details for a specific user ID? ``` **Prompt:** ``` Create a new user named 'Alice' with the job 'Senior Developer'. ``` **Response:** ``` User 'Alice' has been successfully created (simulated). The API returned ID 452 with a creation timestamp of today. The job is set to 'Senior Developer'. ``` **Prompt:** ``` Fetch all records from the 'inventory' collection slug. ``` **Response:** ``` Querying the 'inventory' collection... I found 3 records. They include 'Item A', 'Item B', and 'Item C'. Would you like to see the full JSON data for any of these? ``` ## Capabilities ### Manage User Data Create, read, update, and delete demo users. You can fetch paginated lists of users or get specific details for one user. ### Perform Project Record CRUD Handle full data lifecycle management on custom project collections. This includes creating new records (`create_record`) and updating them partially (`patch_record`). ### Simulate Authentication Flows Run mock login, registration, and magic link requests that return valid tokens or user IDs for agent testing. ### Validate External Resources Fetch structured data from dummy resources, such as Pantone colors, to validate how your application handles external API payloads. ## Use Cases ### The New User Onboarding Flow A user signs up. Instead of relying on a flaky backend, the agent uses `register_demo` to create the initial account. Next, it calls `request_magic_link`, and finally `verify_magic_link` to simulate the full sign-in sequence and get a working session token for subsequent actions. ### Updating Project Scope A project manager needs to change key details. The agent first runs `get_record` to pull existing data, then uses `patch_record` on the specific fields that changed (e.g., slug or status), and finally calls `list_records` to confirm the update worked across the whole collection. ### Testing Data Integrity After Deletion A QA engineer needs to test cascading delete logic. They first call `get_user` to find a target ID, then use `delete_record` on an associated project file, and finally verify the deletion by attempting another `get_record` which should now fail. ### Validating User Permissions The agent needs to check if a user can access specific data. It first runs `list_users` to get all IDs, then uses `get_user` on the target ID, and checks the returned structure against expected permission flags. ## Benefits - **Test Authentication:** Use `login_demo` and `register_demo` to simulate user sign-ups and logins, getting valid tokens back every time. You don't need a real auth service running. - **Validate Complex Workflows:** Chain calls like fetching users (`list_users`) then updating one (`patch_user`) allows you to test multi-step data pipelines reliably for your agent. - **Isolate Front-End Logic:** The `get_record` and `create_record` tools let you focus purely on UI rendering and form validation. You don't worry if the actual database is available yet. - **Control Failure States:** Use `trigger_scenario` to force your agent or front end into known failure modes (e.g., rate limits, bad data). This makes testing robust. - **Handle Resources:** The `list_colors` tool gives you a repeatable source of external data (like Pantone) so you can test how your UI handles non-user/project content. ## How It Works The bottom line is this: You treat Reqres like a live API endpoint, letting your agent perform real database operations and user lookups without ever touching production infrastructure. 1. Subscribe to the Reqres server on Vinkius and obtain your API Key or Session Token (if required for advanced tools). 2. Tell your AI client (Claude, Cursor, etc.) exactly what data you need. For example: 'Use `list_users` to fetch all users.' 3. Your agent executes the tool call. The server returns structured mock JSON data that your application can immediately use. ## Frequently Asked Questions **How do I list all users using the `list_users` tool?** The `list_users` tool lists paginated user data from the Demo API. If your dataset is large, you'll need to check the response for pagination tokens and call the tool again until there are no more results. **Can I use `get_record` with my own custom project slugs?** Yes, `get_record` fetches a single record from a specified project collection. You must provide the unique slug and other identifiers for it to find the correct data in the mock database. **`patch_user` is better than `update_user` for my agent?** Yes, generally. `patch_user` only updates what you give it; `update_user` replaces all fields. Use `patch_user` when you want to change one detail (like an email) without risking data loss. **What if I need to test a failure condition? Should I use the `trigger_scenario` tool?** Yes, that's the right way. Use `trigger_scenario` to force specific failures in the Agent Sandbox. This allows you to prove your agent handles errors gracefully instead of just assuming success. **How do I simulate a user logging in and getting a token using the `login_demo` tool?** It returns a valid session token immediately. You use this token to authenticate subsequent calls, simulating a real user login flow. This is perfect for testing how your agent handles authenticated requests. **What information does the `agent_health` tool provide regarding rate limits?** The `agent_health` endpoint gives you the current sandbox status and any active rate-limit quotas. This lets you write code that gracefully handles throttling errors without failing unexpectedly. **When should I use `list_app_records` instead of `list_records`?** `list_app_records` fetches data scoped to the current user, mimicking a private app collection. Meanwhile, `list_records` pulls from a general project collection that isn't tied to specific user permissions. **Is `patch_record` safer than `update_record` when I only want to change a few fields?** Yes, it is. Using `patch_record` allows you to send partial data—you only specify what needs changing. If you use `update_record`, you must provide the full record structure, risking overwriting necessary data. **How can I see the list of available demo users?** You can use the `list_users` tool. It supports pagination, so you can specify which `page` you want to retrieve from the demo database. **Can I test authentication flows like login and registration?** Yes! Use `login_demo` or `register_demo` with fixture emails (like 'eve.holt@reqres.in') to simulate successful authentication and receive a token. **How do I manage custom data for my specific project?** Use the Project API tools like `list_records` and `create_record`. You just need to provide a `slug` to identify your collection and the JSON data payload.