MCP Connection Readiness · Implementation Pack
You’ve decided on the third door—wire AI into the repository you already have instead of rebuilding or ripping-and-replacing. It’s the best of both worlds: your control, without the eighteen-month build. This one-pager is the bill that comes with it—seven checks to run before you connect, and the questions to ask your vendor before you trust one. Grounded in the research, not the hype.
Read the companion essay: Access Is Not Rigor.
Run these before you connect
Scope — did you narrow it, or just open it?
Connected one curated project, read-only, with the exposed tool count kept under ~10–15.
Why: Tool-selection accuracy slips past 10–15 tools—a fast model was right about 91 percent at 10 tools, down to 87 percent at 15 (Rodrigues & Vas, 2026). Every extra tool is also extra attack surface (see check 2).
Read/write gating — are destructive actions locked behind a human?
Sorted every tool into read-only vs write/modify/send, and put a human confirmation in front of anything irreversible.
Why: MCP measurably widens the attack surface—compromise rates rose from 26.4 to 52.8 percent versus non-MCP setups, and worse across chained servers (Maloyan & Namiot, 2026). Write access you didn't scope is write access an attacker inherits.
Traceability — can every insight point back to the transcript?
Confirmed the connection returns immutable source identifiers, so each synthesized insight cites the exact, timestamped source—and you can spot-check it fast.
Why: Stakeholders lose trust in AI-assisted findings the moment provenance is obscured. A cited answer is checkable; a confident summary isn't.
Tool clarity — does the description match the behavior?
Read the server's actual tool list and confirmed it does only what it says—no undocumented write, delete, send, or network tools.
Why: Studies of real-world MCP servers find a meaningful share whose behavior doesn't match their descriptions (Shi et al., 2026). The description is a claim, not a guarantee.
Consent & PII — is the data allowed to flow at all?
Confirmed PII handling and a valid lawful basis for sending this data to a model provider, with redaction and permissioning enforced in the MCP layer—paying special attention to older records.
Why: Connecting sends your content to the model (HeyMarvin, 2026). MCP carries no participant-consent concept; under GDPR you need a lawful basis, and consent for one purpose doesn't stretch to a new one (purpose limitation)—which is why two-year-old transcripts are the trap. (Not legal advice—loop in your privacy or legal people.)
Access logging — can you scope a breach?
Confirmed every MCP tool call is logged with user attribution, timestamp, and parameters—and that you can reach those logs yourself during an incident, not file a support ticket for them.
Why: Traceability (check 3) tells you whether to trust a finding; access logging tells you what happened when something goes wrong—a different axis. MCP widens the attack surface it rides on (Maloyan & Namiot, 2026); the wider that surface, the more you’ll need to reconstruct who reached what, when. Logs you can’t reach mid-incident aren’t a control.
Injection defense — can hostile content hijack the connection?
Confirmed the connection can’t be steered by the content it reads—a hidden instruction buried in a transcript, file, or field can’t make the AI act on its own.
Why: A connector runs on whatever flows through it. An instruction hidden inside your own data—the phishing attachment now living in your repository—can act through the connection without you asking, and MCP measurably widens that attack surface (Maloyan & Namiot, 2026). Access you didn’t scope is access an attacker inherits.
Print it, work it
| Check | Verify | Grounded in | Pass / Fail |
|---|---|---|---|
| Scope | One project, read-only, ≤10–15 tools? | Tool-selection accuracy (Rodrigues & Vas) | PassFail |
| Read/write gating | Destructive tools behind a human gate? | MCP attack amplification (Maloyan & Namiot) | PassFail |
| Traceability | Immutable source IDs on every insight? | Provenance and stakeholder trust | PassFail |
| Tool clarity | Description matches actual behavior? | Description-code inconsistency research | PassFail |
| Consent & PII | Lawful basis confirmed, PII handled? | GDPR purpose limitation + vendor data-flow disclosure | PassFail |
| Access logging | Tool calls logged with user, timestamp, params—and reachable mid-incident? | Incident-response practice (surface widened by Maloyan & Namiot) | PassFail |
| Injection defense | Hidden instructions in your data can’t trigger actions? | MCP attack surface (Maloyan & Namiot) | PassFail |
Ask before you sign
What exactly leaves our environment when we query, and where does it physically go?
How does authentication work—per-user, or a shared key?
Read-only, or can the model write, delete, or message on our behalf—and can we scope it ourselves?
Do you pass immutable, timestamped source identifiers for every insight?
Is there a security audit trail—who accessed what, when?
Will you disclose the full tool list, and does each tool’s description match its code?
What are the retention and training policies—yours AND the model provider’s?
What certifications and compliance commitments can you show us?
Have you red-teamed your MCP layer—and can you share the report?
Bonus, if participant data is involved: What mechanism, if any, enforces participant-consent scope—or is that on us?
From checklist to proof
A vendor’s docs are a claim, not proof. Real MCP servers ship tools that don’t do what their descriptions say (Shi et al., 2026). So the checklist has a partner: a verifier that connects to the server and tests it against the seven checks—reading the real tool list, sorting read from write, flagging hidden or undocumented tools.
What it caught in testing
Against a sample server, it caught a “save note” tool that quietly overwrites—its description never says so—and an “export” tool the manifest never listed: a hidden data-egress path. Synthetic data only; no real participant records touch a server under test.
A probe proves a failure, never safety. The contractual questions—retention, DPAs, jurisdiction—still get answered on paper.
Wiring a model into your repository? Book a governance review—I’ll run the verifier on your stack first.
Take it with you
Everything on this page, packaged as a PDF you can print, check off in a review, or forward to whoever's about to “just wire it up.”
Access is not rigor.
The connector is the easy part.
Work with me
I help UX research teams put AI into their workflows with intention and integrity. About to wire a model into your repository? Let’s put a second set of eyes on the governance before you connect.
Quick reference
Rodrigues, C., & Vas, O. (2026). MCP Server Architecture Patterns for LLM-Integrated Applications. arXiv:2606.30317. https://arxiv.org/abs/2606.30317
Maloyan, N., & Namiot, D. (2026). Breaking the Protocol. arXiv:2601.17549. https://arxiv.org/abs/2601.17549
Shi, Zhang, et al. (2026). Description-Code Inconsistency in Real-world MCP Servers. arXiv:2606.04769. https://arxiv.org/abs/2606.04769
HeyMarvin Help Center. (2026). Access Marvin data in MCP-compatible tools. help.heymarvin.com
General Data Protection Regulation (EU) 2016/679, Art. 6 (lawful basis) and Art. 5(1)(b) (purpose limitation). https://gdpr-info.eu/art-5-gdpr/
More from the Library
A six-lens self-check for AI-assisted research — plus an adversarial prompt that turns any model into an outside HEARTS reviewer.
Open the kit → Aug 26, 2026A readiness quiz and path checklists for deciding whether to build or buy your research repository.
Open the kit → Aug 11, 2026The multi-agent self-review loop that makes AI tear its own work apart before it reaches you — plus the full /council skill.
Open the kit →