Test members-only pages with an AI agent

You can verify protected pages from your AI assistant without turning protection off or switching to a password. To check the content, the Super MCP server's preview_site shows the saved page as the site owner, so no login is needed. To check that your tiers really let the right people in, give the assistant a test member and a real browser: it logs in once and sees the live page as a member, while Membership stays on.

Content: preview_site → Gate: logged out sees login → Tiers: test member logs in

Check the content: no login needed

This is enough when you only want to confirm what you published. Ask your assistant:

Use preview_site on {{path}} to check the saved page. Then use preview_site with source "live" on the same path and confirm it returns wall "membership". Keep the protection on.

The first call shows the page as the site owner sees it in the dashboard preview, with its real content. The second shows what a visitor meets on the published page. Neither proves that a member with the right tier gets in, so use the steps below for that.

Before you test as a member

A Super site on the Personal plan or higher with Super Memberships connected and at least one page protected by a tier.
Super connected to your assistant: see Connect your assistant.
A test member: a row in your Notion members database with an address you can read, for example you+test@yourdomain.com, holding the tier you want to test. Don't use a real member. For the "access denied" check, add a second test member with a different tier.
An assistant that drives a real browser. Plain web fetching is not enough: the body of a protected page is not in its HTML, it loads through JavaScript after the session is checked.

The member test prompt

Fill in the {{…}} values and paste it into your assistant, or add it to the evaluation step of your own skill.

‣

Prompt - paste into your AI assistant

You are testing members-only pages of my Super website (super.so) after publishing. Keep Membership protection on the whole time. Never remove protection, never switch a page to a password, and never make a page public to get around the login.

How Super Memberships works - keep to these facts:
- Members log in with a one-time link: valid 1 hour, works once. It signs in only when a real browser opens it and you click the "Confirm sign in" button. A plain HTTP request does not sign in.
- A successful login sets the cookie member-session (HttpOnly, 30 days, this domain only). Scripts on the page cannot read it, so stay in the same browser session between tests.
- The body of a protected page is not in its HTML. Judge the rendered page after it has loaded, not the page source. For a run without a browser, send the cookie to GET https://<site>/api/membership-data?page=<path without the leading slash>: {"success":true,"data":…} = allowed, {"success":false,"denied":true} = logged in without a matching tier, {"success":false} = not logged in.
- The login link and the member-session cookie both sign in as that member. Treat them like passwords: never print them in a report, a log or a chat.

My test:
- Site: {{domain}}
- Pages to test and the text each must show: {{path → expected text}}
- Test member with access: {{email}}
- Test member without access (optional): {{email}}
- Login: {{I will log in for you in your browser | I will paste a login link | use my login webhook endpoint}}

Steps:
1. With the Super MCP server (https://mcp.super.so/mcp): find_site, then list_pages. Report effectiveGate for each page and confirm that it is what I expect, including pages that inherit protection from a parent.
2. check_member with each test email. Stop and tell me if the member is missing or lacks the tier.
3. Logged out: preview_site with source "live" for each page. Every protected page must return wall "membership" and show the login screen, not its content.
4. Log in as the test member with access, in your own browser. If you need me, stop and ask: tell me exactly what to do, and wait. Open the login link in the browser you test with and click "Confirm sign in": that click uses the link up, and the session stays in that browser.
5. Logged in: open each page directly by its URL, wait for it to finish loading, confirm the expected text, and check that images and links work. Take a screenshot if you can. Then open a page that member's tier must not reach: it must show the access denied screen.
6. If I gave a test member without access, repeat step 5 in a clean session as that member: it must get the access denied screen on the protected pages.
7. Report one line per page: logged out, member, no access, each pass or fail with what you saw. If the login failed, get_membership_activity with the email shows what happened. Do not change anything to make a test pass.

How the assistant logs in

Pick the first option that works for your setup. All of them keep Membership on.

Option	How	Best for
You log in inside the assistant's browser	Let it open the page, take over the browser, enter the test email, open the emailed link in that same browser and click Confirm sign in.	Assistants with a built-in browser, such as ChatGPT agent mode
Copy a login link	Settings → Membership → View login log, then the copy icon on the test member's row. No email is sent. Paste the link to the assistant. The member needs a row in the log, so request a login once first.	Sandboxes and browser tools with no access to your inbox
Login webhook	Point Settings → Membership → Login webhook at your own endpoint, which passes the test member's link to the tester.	Unattended, repeated runs

After the first login the session lasts 30 days, so a tester that keeps its browser state, such as a saved Playwright storage state, doesn't need a new link every run. Whether a built-in browser keeps the session between runs depends on the assistant.

The login webhook receives a live link for every member who logs in, and its requests are not signed. Use a secret in the URL (?key=…), pass on only the test member's address, drop everything else, and don't log the links. The webhook works alongside the login email: leave Sign-in link sent by on Super so members keep getting their email. The webhook is set in the dashboard, not through the MCP.

What a good run looks like

Who	Protected page shows
Logged out	The login screen
Test member with the tier	The page content and a logout button
Test member without the tier	The access denied screen, not the login screen
Anyone, on a page set to Public (overrides parent)	The page content, no login

Good to know

Preview or member test? The preview is the owner's view of the saved site. The member test is the live page as a member sees it, so it also covers tiers, the login and page protection.
Why not a password for testing? It is a different gate: a page that passes with a password tells you nothing about your tiers, and you would have to remember to switch it back.
Link previews are safe. A chat app that unfurls a login link doesn't use it up, and neither does opening it: only the click on Confirm sign in does.
Removed a test member? A session that is already logged in keeps working for up to 24 hours. Reloading the tiers ends it straight away.
Clean up. Remove the test members when you stop testing, and treat a saved session like a password.

Still evolving. The Super MCP server, Notion and the AI assistants are all changing fast, so you may run into limits. Tell us in MCP feedback: we want to know, and if there is a workaround, we will help you with it.