What the MCP connector can’t see, even in full access
The instinct to be cautious about connecting any outside assistant to production data isn’t irrational. Scripts are confidential before release, and a production has real, specific reasons to be careful about who – or what – can see them. But that caution usually assumes a connected assistant can see everything once it’s switched on, and that’s not how the MCP connector works.
There’s a difference between what you’ve permitted and what’s simply never available, and the second category matters more than the first, because it isn’t a setting anyone could accidentally leave open.
What’s excluded, regardless of permission mode
Personal contact details, home addresses, agency information, cast measurements, and financial data are never returned by the connector – not in Read-only, not in Ask before each operation, and not in Full access. This isn’t a default that a project owner has to remember to configure. It’s a boundary built into what the connector is able to hand over in the first place, which means there’s no permission mode that opens it.
Why that distinction matters
A setting can be left too open by mistake. A structural exclusion can’t – there’s no misconfiguration that exposes a category of data the connector was never built to share. That’s a meaningfully different kind of guarantee from “we trust the assistant to behave,” and it’s the reason the excluded list is worth knowing specifically, rather than trusting the general idea of “permissions” to cover it.
Server-enforced, not requested
Permission modes themselves work the same way. Blocked, Read-only, Ask before each operation, and Full access aren’t preferences the assistant happens to respect – they’re enforced on the server the connector talks to. An assistant operating in Read-only mode isn’t choosing not to make changes. It structurally can’t, at the point where the request would need to go through.
Script content adds a further, separate layer: a project can withhold screenplay dialogue and action text from the connected assistant independently of whatever permission mode is set elsewhere, for the material that’s most sensitive before a release.
What full access does share
None of this means full access is empty. Deliberately opened up, a connection can read schedules, breakdowns, conflicts, and reports in real depth – that’s the actual value of connecting an assistant in the first place, and it’s a genuine, considered choice a project owner makes, not something that happens by default or by accident.
The alternative – not connecting an assistant at all – avoids the question entirely, but it doesn’t avoid the underlying problem the connector is solving. A 1st AD or line producer who wants a quick answer about tomorrow’s schedule either gets it from a connected assistant working within these boundaries, or opens the app and finds it manually, or asks a coordinator to look it up. Disconnecting removes one option. It doesn’t remove the sensitivity of the data itself, which was already sitting in the project either way.
The question worth asking
Not “can I trust an assistant with my production’s data,” which is too broad to answer usefully. The narrower, more useful question: what specifically has the system decided never to hand over, and does that list actually cover what would worry you if it leaked. For most of what makes a script or a cast list sensitive – who someone is, how to reach them, what they’re paid – the answer is that it was never on the table to begin with.
Related: How to connect Claude to your SceneItAll project, What a line producer and a 1st AD each ask their connected assistant