How to connect Claude to your SceneItAll project

August 31, 2026 · updated August 31, 2026

Connecting Claude to a SceneItAll project isn’t a new feature living inside the product. It’s a bridge – the MCP connector – between an assistant you already use and the project data you already have, set up once and controlled the whole way through.

Find the MCP Server URL

In SceneItAll, open the AI Connector settings from the account menu and go to MCP Connection. Copy the MCP Server URL shown there. This URL is specific to your account – it’s how the connection gets tied back to your permissions, not a generic address shared across every user.

Add SceneItAll as a custom connector in Claude

In Claude, open Settings, then Connectors, then Add. Give it a name – SceneItAll is the obvious choice – and paste in the URL copied from the previous step. Claude treats this exactly like any other custom connector: it’s not a special integration living outside the normal connector system.

Authenticate properly, through your own account

When the connection is first used, it prompts for sign-in through SceneItAll itself. Sign in with your own account credentials there – never paste a password directly into Claude, and never share a login between team members to make this quicker. Each person who wants a connected assistant needs their own authenticated connection, tied to their own role and permissions.

Set the permission mode before asking anything else

Before the first real question, check which permission mode the connection is running in. Four modes exist: Full access, Ask before each operation, Read-only, and Blocked. Ask before each operation is the default, and it’s a reasonable place to start – the assistant proposes an action and waits for confirmation before doing anything, which is the easiest way to see exactly what it’s capable of before deciding how far to open things up. Full access removes that confirmation step for a connection you trust completely. Read-only allows lookups but nothing that changes data. Blocked switches the connection off without deleting it.

This isn’t a setting the assistant can talk its way around. It’s enforced on the server, which means the mode chosen is the actual limit, not a preference the assistant happens to respect.

Decide on script content separately

Withholding screenplay dialogue and action text from the connected assistant is a separate toggle from the permission mode above – a project can run in Full access for everything else while still keeping the script itself off-limits. Worth deciding deliberately rather than assuming one setting covers both.

Set context before the first real question

Once connected, tell the assistant which project to work in. If a persona applies to your role – first AD, line producer, and so on – mention it; the assistant uses that to prioritise what it surfaces, rather than treating every question as equally broad.

Start with something read-only

Before asking the connected assistant to do anything that changes data, ask it something simple that only requires reading – tomorrow’s call time, or how many scenes are still unscheduled. This confirms the connection is actually working, and shows what a response looks like, before any action is on the table.

What a first real session might look like

A reasonable first real question, once read-only access has confirmed the connection works: ask what’s scheduled for the next three shoot days, and whether anything is flagged as a conflict. This is exactly the kind of question the connector is built to answer well – it pulls straight from the schedule and conflict data, and a wrong or vague answer here is an early sign to double-check the project context before trusting it with anything more involved. A confident, specific answer is the sign it’s genuinely reading your project, not guessing from general knowledge of how productions usually work.

Revisit the settings as trust builds, not just once

Permission mode and script-content blocking aren’t locked in permanently at setup. Move from Ask before each operation to Full access once a pattern of accurate, useful answers has built real confidence – and move back to Blocked just as easily for a project that’s wrapped, or for a period when the assistant isn’t needed. Treat it as a setting that should track how much trust has actually been earned, not a one-time decision made on day one.

Common pitfalls

The most common mistake is treating Full access as the default because it’s the simplest to describe. Ask before each operation exists as the default for a reason: it’s the fastest way to learn what a connected assistant actually does before deciding how much rope to give it.

The second is forgetting that script-content blocking is independent of the permission mode. A project can be locked down everywhere else and still be leaking script text, or locked down on script text while wide open elsewhere – check both settings, not just one.

The third is sharing a login to save time setting up a second person’s connection. Each connection should trace back to one authenticated person, both for security and because permissions are supposed to reflect that person’s actual role on the project, not a generic shared account’s.