Stunt Double

할 수 있는 일

이 서버는 아직 쉬운 말로 된 요약을 쓰지 못했어요. 아래는 레지스트리에서 읽어 온 사실이에요.

• 연결 방식: 클라우드에서 실행
• 전송 방식: Streamable HTTP
• 카테고리: 개발자 도구

설치

쓰고 있는 AI 앱을 고른 다음 설정을 복사하세요.

필요한 것

• 클라우드에서 실행설치할 것 없음. 인터넷으로 연결돼요

어떤 앱을 쓰세요?

https://app.stuntdouble.io/api/mcp

claude mcp add --transport http stuntdouble https://app.stuntdouble.io/api/mcp

{
  "mcpServers": {
    "stuntdouble": {
      "url": "https://app.stuntdouble.io/api/mcp"
    }
  }
}

{
  "servers": {
    "stuntdouble": {
      "type": "http",
      "url": "https://app.stuntdouble.io/api/mcp"
    }
  }
}

https://app.stuntdouble.io/api/mcp

선택한 앱은 이 기기의 쿠키에만 저장돼요. 계정은 필요 없어요.

이 설정은 제작자의 레지스트리 정보로 만들었어요. README와 다르면 README를 따르세요.

할 수 있는 일

도구 이름과 설명은 서버가 2026년 11월 6일에 알려 준 그대로예요. 우리가 아니라 제작자가 쓴 글이고, 일반 텍스트로만 보여 드려요.

• get_me

  Get the account this connection is acting as: id, email, name, timezone and where notifications reach them. Use `timezone` when creating a scheduled workflow rather than defaulting to UTC, and `id` to tell your own runs and feedback from a teammate's in lists that carry only user

• list_workspaces

  List the workspaces you belong to, with your role in each. Call this first: almost every other tool needs a workspace_id from here.

• get_workspace

  Get workspace details by ID or slug, including the admin-set controls that decide what runs in it may do. `settings` is a ceiling, never a grant: a network policy there applies on top of each worker's own, and a feature switched off there cannot be switched back on per project.

• list_workspace_members

  List the members of a workspace with their role, name and join date. Use it to resolve the user ids that runs, feedback and assignments carry.

• search

  Search everything in a workspace (projects, actors, checklists, interviews, automations, issues, goals, feedback, knowledge, insights, design reviews, resources, conversations) by name or content. Use it instead of listing and filtering, and before creating something that may alr

• list_projects

  List the live projects in a workspace, most recently opened first. Call this after list_workspaces and match a target URL or product name against these before creating anything new.

• get_project

  Get one project (the product tracked by checklists, workflows, interviews and feedback), including its URL, audience and product description. Archived projects read as not found.

• create_project

  Create a project (a product to track with checklists, workflows, interviews and feedback). Call list_projects first and reuse a matching project rather than creating a duplicate.

• list_project_mcp_servers

  List the third-party MCP servers attached to a project and the tools each allows. Configuration only: those tools are not callable here, but an actor in a run (checklist, interview, workflow) may call the allowed tools of servers whose in_force is true. Servers are registered and

• list_workspace_guidelines

  List the workspace's whole library of standing rules (design system, tone of voice, brand, compliance, accessibility, shared knowledge), with how many projects hold each one. Read this before writing a rule: attaching one that already exists with `set_project_guideline` beats typ

• add_workspace_guideline

  Add a standing rule to the workspace library. Call list_workspace_guidelines first so you do not add a near-duplicate. Attach it to the projects it applies to with `project_ids` here or `set_project_guideline` later, or set `apply_to_design_reviews` so every design review in the

• update_workspace_guideline

  Update a rule in the workspace library, or switch it off. Every project holding it is held to the new wording, so prefer editing the shared rule over adding a near-duplicate. Pass only the fields to change; at least one is required.

• remove_workspace_guideline

  Remove a rule from the workspace library permanently. This detaches it from every project holding it, so prefer `update_workspace_guideline` with `enabled: false` when the rule may come back.

• list_project_guidelines

  List the standing rules this project is held to: the workspace library rules it has attached. Read these before writing checks, interview guides or design feedback for the project, and assert them as observable checks rather than restating them. `attachment_id` is this project's

• add_project_guideline

  Add a standing rule and hold this project to it (a design-system rule, a tone-of-voice rule, a compliance obligation, or shared knowledge). Every checklist run, design review, interview and triage for the project is then held to it. The rule joins the workspace library, so check

• set_project_guideline

  Attach a library rule to a project, detach it, or switch it off for this project alone. Attaching is how one workspace rule comes to hold for several projects without being retyped. `enabled: false` keeps the attachment but stands the rule down here, leaving every other project u

• list_actors

  List active actors (persistent AI user personas) in a workspace, oldest first. Prefer reusing an existing actor over creating a new one; pass an id from here to get_actor, interviews and checklists.

• get_actor

  Get an actor's details: description, system prompt, capabilities, and status. list_actor_knowledge has the knowledge it carries into runs.

• create_actor

  Create an actor: a persistent AI user persona with its own browser, email inbox (for OTP and magic-link flows), and memory. The description shapes who the persona is, so describe a person (background, goals, tech comfort), not a job title. Call list_actors first and reuse a match

• update_actor

  Update an actor's name, description, system prompt, capabilities, or status. Only the fields you pass change; at least one is required. Set status to "archived" to soft-delete.

• list_actor_knowledge

  List what an actor knows, oldest first. Each entry has a kind: expertise and process entries are listed by title in every run and the actor reads one when the task calls for it; reference and account entries are found by search. Check here before add_actor_knowledge to avoid dupl

• add_actor_knowledge

  Add knowledge to an actor. Choose the kind: expertise for a skill or standard it judges by in every run (brand, tone of voice, design system, compliance, accessibility), process for steps it follows, reference for facts it looks up when relevant (product docs, FAQs, policies), ac

• remove_actor_knowledge

  Remove a knowledge entry from an actor permanently, so future runs no longer use it. Find the entry's id with list_actor_knowledge.

• list_conversations

  List chat conversations with actors in a workspace, most recently active first, optionally filtered to one actor. Excludes the workspace assistant's conversations. Pass an id to get_conversation to read the messages.

• get_conversation

  Get an actor conversation with its full message history, oldest message first. Find conversation ids with list_conversations.

• list_checklists

  List the checklists in a workspace, with their target URL, actor, check count and a recent run. Check here before creating a new checklist: re-running an existing one keeps its history as a regression signal. Use get_checklist for the checks themselves.

• get_checklist

  Get a checklist: its target URL, instructions, run settings, every check (with the `id` update_checklist needs to edit one in place) and its 10 most recent runs. Call get_checklist_run with a run id for per-check results and evidence.

• get_checklist_run

  Get a checklist run: per-check results with evidence, score, verdict and the change since the previous run. Poll after run_checklist every 30 to 60 seconds until `status` is terminal; `outcome` is the verdict on the experience. `comparison.changes` (what got better or worse) is u

• flag_check_verdict

  Correct a wrong passed or failed verdict on one check: pass the result_id from get_checklist_run and a note on what was actually true. Later runs use it as calibration and re-record any code-run script; the run's own score is unchanged. Set clear to withdraw a correction.

• run_checklist

  Run a checklist (async): the actor drives a real browser through the product and judges each check, and may use the project's attached MCP servers (list_project_mcp_servers). Returns a run_id; poll get_checklist_run (runs take a few minutes). Counts against the workspace's plan a

• create_checklist

  Create a browser checklist: an actor exercises the product at a URL and judges each check with evidence. Checks can verify flows ("a new user can complete signup") or assert standards ("headlines use sentence case"), for brand, compliance and design-system audits. Any reachable U

• update_checklist

  Update a checklist. Only the fields you pass change. Pass `checks` to replace the full set of checks, sending each existing check with the `id` from get_checklist so it keeps its run history. Changing the checks, instructions or url retires the recorded script, so the next run dr

• delete_checklist

  Delete a checklist and its checks and runs. This permanently discards run history; prefer update_checklist, or simply not running a checklist, unless the user asks for deletion.

• list_feedback

  List the comments stakeholders and users have left on a project through the feedback widget, newest first. Each one is pinned to a page position (often to a named element) and carries device info; filter by status "new" when triaging. Use summarise_feedback to turn a list of thes

• get_feedback

  Get one feedback widget comment with its full reply thread, its page location and version, and a signed screenshot URL when one was captured. Find the id with list_feedback.

• summarise_feedback

  Summarise a project's comments into themes ranked by severity, open questions, and a self-contained implementation brief for a coding agent. Read the brief before proposing changes instead of reasoning over raw comments. The brief leaves out work an open question holds up; `answe

• update_feedback_status

  Update a feedback widget comment's status: "reviewed" once assessed, "resolved" when confirmed fixed (ideally after a checklist run proves it), "dismissed" sparingly. The dashboard reflects the change immediately.

• list_workflows

  List workflows (multi-step automations) in a workspace, newest first, with their triggers, whether each is active, its step count and its last run. Call get_workflow on one for its steps and the order a run takes them.

• get_workflow

  Get a workflow with its steps, the edges connecting them, the order a run would reach them, and recent runs. Read this before editing steps: `execution_order` is what actually runs, and any id in `unreachable_step_ids` is a step no run will ever reach.

• run_workflow

  Trigger a workflow run now (async), whatever its trigger type: it executes the stored steps (see get_workflow), which can drive browsers, post PR comments and notify members. Returns a run ID; poll get_workflow_run. Refused over the plan limit or budget cap.

• get_workflow_run

  Get a workflow run with step-level details. Poll this after run_workflow until status is terminal (completed, failed or cancelled).

• create_workflow

  Create a workflow (multi-step automation) that runs checks without anyone asking. Triggers: manual, schedule (cron), webhook, or vercel_event / github_event / cursor_event / linear_event / slack_event / figma_event so checklists re-run on deploys, pull requests, or design updates

• update_workflow

  Update a workflow's name, description, or trigger. Only the fields you pass change. Syncs the Trigger.dev schedule when the cron or trigger type changes. The trigger fields edit the workflow's one trigger; a workflow with several triggers has them edited in the dashboard instead.

• toggle_workflow

  Activate or pause a workflow. Scheduled workflows have their Trigger.dev schedule activated/deactivated to match. Activating a workflow that runs on a schedule, webhook or event needs the mcp:run scope, since it then starts runs on its own; pausing never does. Pausing keeps the s

• delete_workflow

  Delete a workflow and its steps and runs, and remove its schedule. This discards run history; prefer toggle_workflow to pause unless the user asks for deletion.

• add_workflow_step

  Add a step to a workflow and connect it into the run. Only stores it: nothing executes until the workflow runs. Appends by default; `sort_order` splices it in at a position. In a run, run_checklist drives a real browser; notification emails or messages members on Slack; github_co

• update_workflow_step

  Change a step's type or config in place, leaving its connections alone (move it with reorder_workflow_steps). Only stores the change. Config shapes are as in add_workflow_step.

• remove_workflow_step

  Remove a step and close the gap: whatever led into it is repointed at whatever it led to, so the rest of the automation still runs.

• reorder_workflow_steps

  Set the order a workflow runs its steps in, as one linear sequence. Pass every step id: a list that leaves a step out is refused, since that step would be disconnected from the run (remove it with remove_workflow_step instead). This rewires the whole automation, so a branch built

• connect_workflow_steps

  Wire a step's output handle to another step, to build or repair a branch (adding and removing steps keeps the plain chain on their own). A condition's 'false' handle starts unconnected, so a failing condition ends the run. Connecting a connected handle replaces its edge; target_s

• comment_on_pr

  Post a comment on a GitHub pull request via the workspace GitHub connection. Use it to report checklist or interview results where engineers already look: a short verdict, then per-check outcomes with evidence highlights. Needs the Stunt Double GitHub App installed on the reposit

• list_pull_requests

  List pull requests for a GitHub repository via the workspace GitHub connection, most recently created first (up to 30). Use it to find the PR number to pass to get_pull_request or comment_on_pr.

• get_pull_request

  Get details for a GitHub pull request (title, description, author, branches, change stats) via the workspace GitHub connection. Read it before writing a checklist for the change, then report back with comment_on_pr.

• list_interviews

  List the user interviews in a workspace, newest first, optionally filtered to one project. Returns summary rows; call get_interview for the discussion guide and participants, or get_interview_report for the findings.

• get_interview

  Get an interview with its discussion guide (sections and their items, in order) and participants with their run status. Also useful for polling progress after launch_interview; call get_interview_report for the synthesised findings.

• create_interview

  Create a user interview: AI persona participants complete tasks and answer questions against target_url, and results are synthesised into a report. target_url can be any reachable URL, including prototypes (Figma Make publish links, Claude design artifacts, v0) and preview deploy

• update_interview

  Update an interview’s name, target_url, research brief, status or usability questionnaire. Only the fields you pass change; pass at least one. To start a round use launch_interview rather than setting status to running.

• add_interview_section

  Add a section to an interview’s discussion guide. Sections group related items (e.g. "First impressions", "Checkout"); add questions and tasks to it next with add_interview_item, using the returned id as section_id.

• add_interview_item

  Add a question or task to an interview section (create the section first with add_interview_section). Tasks are concrete jobs to attempt in the product ("Find the annual plan price and compare it with monthly"); questions probe comprehension and sentiment. Set expected_evidence o

• add_interview_participant

  Attach a participant to an interview. Provide either actor_id (existing actor) or persona_spec (ad-hoc persona: name, bio, traits), not both. Vary personas and devices across participants (expertise, motivation, scepticism, mobile vs desktop) for richer findings, and use behaviou

기본 점검i

누구나 볼 수 있는 정보를 점검했고, 코드는 읽지 않았어요. 해당하지 않는 항목은 개수에서 뺐어요. · 2026년 11월 6일 점검

• ✓ 통과

  제작자와 저장소 일치

  레지스트리 이름이 도메인 stuntdouble.io 기준으로 확인되었어요(레지스트리가 도메인 소유를 확인해요)

• … 아직 점검 안 함

  계속 관리되고 있음

  아직 GitHub에서 이 저장소를 읽어 오지 않았어요

• … 아직 점검 안 함

  라이선스 있음

  아직 GitHub에서 이 저장소를 읽어 오지 않았어요

• ✓ 통과

  엔드포인트 응답

  394ms 만에 응답(HTTP 200)

• – 해당 없음

  OAuth로 로그인

  로그인 필요 없음

• ✓ 통과

  도구 설명에 숨겨진 지시 없음

  도구 설명 60개를 읽었고, AI에게 보내는 숨겨진 지시는 없었어요

개발자 도구 카테고리의 다른 서버와 비교i

• 이 카테고리의 다른 서버 1389개 중 0%보다 스타가 많아요
• 이 카테고리의 다른 서버 1389개 중 96%보다 최근에 레지스트리에 공개됐어요
• 기본 점검 결과가 이 카테고리의 다른 서버 1389개 중 100%와 같거나 더 좋아요

레지스트리에서 이 카테고리의 활성 서버 전체와 비교했어요. 스타는 게시자가 저장소를 소유한 경우에만 세요.

대안

같은 카테고리에서 다른 제작자가 만든 서버예요. 스타 순으로 정렬했어요.

카드 보는 법:★ GitHub 스타i세 기둥: 리뷰 · 점검 · 사용 정도i업데이트 = 최신 버전을 레지스트리에 공개한 날i

제작자의 README

claude mcp add --transport http stuntdouble https://app.stuntdouble.io/api/mcp

claude plugin marketplace add stunt-double/stuntdouble-mcp

npx skills add stunt-double/stuntdouble-mcp                          # pick from the list

https://app.stuntdouble.io/api/mcp

https://app.stuntdouble.io/api/mcp

codex mcp add stuntdouble --url https://app.stuntdouble.io/api/mcp

[mcp_servers.stuntdouble]

gemini mcp add --transport http stuntdouble https://app.stuntdouble.io/api/mcp

{

code --add-mcp '{"name":"stuntdouble","type":"http","url":"https://app.stuntdouble.io/api/mcp"}'

{

{