MCP Server

The MCP server lives at a single URL:

https://fluotest.com/api/mcp

It uses the Streamable HTTP transport. Every request must be authenticated — unauthenticated requests get a 401 response that tells MCP clients where to start the OAuth flow.

There are two ways to authenticate. Both act as your user account: the assistant can only see and create what you can.

• OAuth 2.1 (recommended): Supported by Claude's custom connectors and other MCP clients with OAuth support. You sign in to FluoTest in the browser and approve access on a consent screen — no keys to copy, and you stay in control of what's connected.
• API key: For MCP clients that take custom headers (like Claude Code) or your own scripts. Generate a key in Settings → Security → API keys and send it as "Authorization: Bearer fluo_…" — treat it like a password.

Full API reference: keys, headers & curl examples →

In Claude, go to Settings → Connectors → Add custom connector and fill in:

1. Name: FluoTest
2. Remote MCP server URL: https://fluotest.com/api/mcp
3. Click Add, then Connect — you'll be sent to fluotest.com to sign in and approve access.

No client ID or secret to copy — the connector registers itself automatically as a public OAuth client (PKCE, no secret needed) the first time you connect.

For clients where the OAuth flow isn't available:

1. In FluoTest, open Settings → Security → API keys.
2. Enter a name (e.g. "Claude Code") and click Generate key.
3. Copy the fluo_… key immediately — it's shown only once.
4. Add it to your MCP client as an Authorization header.

Generic MCP configuration (for mcp.json-style clients):

{
  "mcpServers": {
    "fluotest": {
      "type": "http",
      "url": "https://fluotest.com/api/mcp",
      "headers": {
        "Authorization": "Bearer fluo_YOUR_API_KEY"
      }
    }
  }
}

Claude Code (CLI)

claude mcp add --transport http fluotest https://fluotest.com/api/mcp \
  --header "Authorization: Bearer fluo_YOUR_API_KEY"

Full API reference: keys, headers & curl examples →

The server exposes eight tools that cover a quiz's full lifecycle. Every tool takes a quiz by title, slug, or ID — an assistant never needs you to paste a UUID.

• list_quizzes: Lists your quizzes: title, ID, slug, draft/published status, submission count, and created date. An assistant calls this first to resolve a quiz you mention by name, like "my wellness quiz".
• create_quiz: Creates a draft quiz owned by you: a title, an optional description, and questions — yes_no (with points for "yes"), multiple_choice / multi_select (with a score per option), or open for unscored text — either as a flat list for a single-section quiz, or grouped into named sections for a multi-section quiz. Score tiers and the custom outcomes engine are optional too. Returns the quiz ID and a dashboard link; the quiz stays unpublished until you publish it.
• get_quiz_questions: Takes a quiz by title or ID and returns its questions grouped by section, in order — each section's title, and within it each question's text, type, options with scores (or points for yes_no), and which ones disqualify a respondent. Useful for reviewing what a quiz actually asks, or as a check before update_quiz.
• get_quiz_settings: Takes a quiz by title or ID and returns its welcome/thank-you page text, results email configuration, UX toggles (time limit, response cap, celebration animation, hide score, show intro, show benchmark), and which integrations are connected — webhook, Brevo, Meta Pixel, GTM — as true/false, never the underlying URL or IDs.
• update_quiz: Edits an existing quiz: title, description, questions, score tiers, custom outcomes, welcome/thank-you pages, results email, and UX settings like time limit or hide score — every field optional, only what you pass changes. Questions can be edited three ways (pick at most one per call): replace the whole flat list, replace the entire section structure with a new set of named sections, or apply surgical add/edit/move operations to individual questions on a multi-section quiz without touching the rest. Editing a quiz that's already published needs an extra confirm_edit_published: true — the first attempt is refused and shows you the submission count instead, so an assistant can't change a live quiz out from under you without you seeing that first.
• publish_quiz: Publishes a draft quiz, by title or ID, making it live at its public URL. This never happens automatically — publishing is always a separate, deliberate step from create_quiz, taken only when you ask for it.
• get_results: Takes a quiz by title or ID and returns the submission count, disqualified count, average / lowest / highest score percent, and — when the quiz has score tiers configured — how many respondents landed in each tier.
• delete_quiz: Permanently deletes a quiz and its submissions, by title or ID. The first call never deletes anything — it returns the quiz's title and submission count so you can review before confirming; a second call with confirm: true actually executes it.

Example create_quiz arguments

{
  "title": "Marketing readiness check",
  "description": "Score how ready a business is to run paid ads.",
  "questions": [
    { "text": "Do you have a documented strategy?", "type": "yes_no", "points": 2 },
    {
      "text": "How often do you review results?",
      "type": "multiple_choice",
      "options": [
        { "label": "Monthly", "score": 3 },
        { "label": "Yearly", "score": 1 },
        { "label": "Never", "score": 0 }
      ]
    },
    { "text": "Anything else we should know?", "type": "open" }
  ]
}

MCP clients discover these automatically from the server's 401 response and the discovery document — you only need them if a client asks for endpoints explicitly. Try the OIDC discovery URL first; it resolves the rest.