MCP Toolkit: Practical Questions You Should Ask Before Enabling an MCP Connection

As a stakeholder considering the implementation of an MCP connector, it may be difficult to glean from product documentation or marketing materials alone how the tool is functioning, and what must be done to manage its implementation.

MCP connectors provide a standardized way to connect AI models to external systems, allowing for easier proliferation of agentic AI. However, these connections also introduce new risks, including data access and privacy liability; unauthorized or erroneous actions; security vulnerabilities; accountability and governance; and third-party mismanagement.

Consider the below list of questions as your starting point on the path to understanding, and coming up with a plan for deploying a responsible MCP architecture. These questions may be posed to your provider or use case deployer of the tool using MCP connections.

Some of these questions look like standard vendor diligence, and they are, but each conventional question has a sharper edge when the actor is not a person. While these questions are not an exhaustive set to assess potential issues that can arise in an MCP connector deployment, they provide a jumping-off point to identify and proactively manage potential issues in the context of deploying an MCP connection.

WHAT IS THE TOOL DOING?
The questions in this category assist with understanding what the goal of the tool is. Focusing on performance and outcomes keeps the tool from failing its essential purpose.

1. 1. What do you want the agent to do with this connection?
      The answer to this question determines every downstream control. For example, read-only access to a CRM creates a different risk profile than write access that lets the agent send communications, update records or initiate transactions. A good answer identifies each action the agent may take and distinguishes proposed actions from executed ones. As a result, you can then scope the agent to the business need, not to the tool’s default.
   2. Will the model be allowed to take actions without human approval, and if so, what actions?
      Human-in-the-loop is the line between an agent that recommends and an agent that acts. A good answer maps each action type to a control: mandatory approval, optional approval, post hoc review or fully autonomous. Consider imposing human review even where the law does not require it, particularly for actions that are difficult to reverse or that touch external counterparties. The law is a floor, not a ceiling.
   3. How do you know when the agent got it “right”?
      Without a definition of success, there is no way to detect failure. A good answer specifies the qualitative and quantitative metrics by which an action will be judged. If the standard service levels only measure whether the agent ran without throwing an error, the tool may fail its essential purpose but still be considered “performing.”
   4. What are the ways the agent can fail?
      Proactively considering what can go wrong avoids reactively having to clean up a mess. This line of questioning should consider both technical failures (timeouts, malformed calls, retries that compound across systems) and substantive failures (security breaches, erroneous actions, deleted records and hallucinations). A good answer names the worst-case scenario for each failure category and identifies the detection mechanism for each. Logging, audit trails and explainability are the controls that make this question answerable after the fact (more on that in Q11 below).
   5. Who is tracking the outcomes?
      Outcomes are only measurable if tracked, and if tracked by a trustworthy source. A good answer identifies a person or function, calls out a system of record or tracking tool, describes the review cadence and specifies the escalation path when outcomes are bad. If the answer is that the vendor is doing the tracking, the contract should say so and should give the customer access to the results.

Scope is only as meaningful as the data and systems behind it. The next set of questions defines the inventory accessible to the agent.

WHAT IS THE AGENT TOUCHING?
A starting point of risk mitigation is scoping out what the risk looks like—and in the case of AI agents with MCP connections, that means understanding the data involved and where and how it flows. Answers to these questions build an inventory of data types and data access points.

1. 6. What systems and data will the connector touch, and how sensitive is that data?
      The data inventory drives every downstream legal analysis: privacy obligations, confidentiality commitments, privilege preservation, IP protection and regulatory classification. A good answer lists the systems in scope, the data types within each, and the sensitivity classification under the organization’s existing data taxonomy. Consider both what the tool can touch, but also what (if anything) it can create.
   7. Is access scoped to the minimum necessary, or are we exposing entire systems by default?
      Default-broad access is the most common configuration pattern in MCP deployments and the most impactful source of post-incident regret. A good answer documents least privilege as implemented: which records, which fields, which operations and which exceptions. If the answer is that the agent has the same access as a human user role, ask whether the tool and the human really are intended to perform the same way.
   8. Where is the data going, and are there cross-border or data localization implications?
      Model providers, connector hosts and downstream applications may sit in different jurisdictions, and the agent’s data path may cross borders the organization has not previously crossed. A good answer traces the data flow end-to-end and identifies not only the legal basis for each transfer, but also the security controls that protect the transfer.
   9. How is the connector authenticated, and what happens if those credentials are compromised?
      Service accounts and API keys used by agents tend to be long-lived, broadly scoped and less actively monitored than human credentials. A good answer covers the credential type, rotation cadence, scope limitations and incident response procedure tailored to non-human access. The organization’s existing credentials management strategy may need adjustment to account for access at machine speed and volume.

Data and systems are governed by people and contracts. The last set of questions assigns those roles.

WHO IS IN CHARGE?
An MCP deployment puts more parties between the user and the action than a typical procurement: the model provider, the connector host, the application vendor and the internal operator. Stepping outside of the technological architecture and into the governance of the tool, these questions will help better understand who is responsible for oversight and management within the aforementioned group of parties.

1. 10. Who built each element of the stack—the model, the connector and the application—and how was each vetted before deployment?
       An agent is often the product of multiple parties, and each one is a potential point of failure. A good answer identifies the provider of each layer, the contractual relationship with each, and the diligence performed before the connection went live. Where a layer is open source or community-maintained, the vetting process should account for the absence of a contractual counterparty and adjust the residual risk allocation accordingly.
   11. Who is reviewing the logs, usage data and decisions? How often?
       The devil, per usual, is in the details–or rather, the details are key to understanding whether your agent is doing what it is supposed to. Tracking what was done can only happen if the process was logged and those logs are retrievable. A good answer names the reviewer, the cadence, the trigger conditions for off-cycle review, and the documentation retained after each review. Many regulatory governance frameworks expect ongoing monitoring proportionate to the risk profile; agentic systems are not exempt simply because the agent is doing the work a person used to do.
   12. Do our existing contracts and licenses contemplate this type of AI-driven access and use?
       Most software licenses were drafted before agentic access was a meaningful use case, and some contain automation restrictions, per-user pricing assumptions or downstream use limitations that an MCP deployment may breach. A good answer identifies the relevant agreements, flags applicable language and resolves any ambiguous interpretations with the counterparty before deployment rather than after a usage audit. A good answer also provides enough data to assess the commercial implications of the new access point. Where an agreement is silent, the organization may want express permission for AI-driven access added at the next renewal.
   13. Who is accountable across the environment if the model causes harm?
       Risk and control should align. A good answer clarifies the preferred allocation of responsibility among the model provider, the connector provider and the business in a way that matches who actually controls each failure point. Indemnities, liability caps and insurance should reflect that allocation. Where the allocation is silent or carries forward boilerplate from a pre-AI template, the business should understand and own risks it cannot meaningfully manage.

Let the responses to these questions be your guide. A vague response points to a knowledge gap. A partial response points to a configuration assumption no one has stress-tested. An evasive response points to a risk allocation misalignment. Each is easier to fix at the contract table or in the pre-go live architecting of the tool, rather than after the agent goes live.

This is the fifth and final installment in our series on Model Context Protocol (MCP) connectors. The first installment provided a technical primer on MCP architecture. The second installment catalogued the key legal and operational risks. The third installment outlined a risk mitigation framework, and in our fourth installment, we offered a “tool” to include in your toolkit when assessing and using MCP connectors in agentic AI.

---

Pillsbury’s MCP Connector Series

Model Context Protocol (MCP) and Connectors: A Primer

MCP Connectors: Legal and Operational Risks

MCP Connectors: Mitigating the Risks of AI Agents in a Connected Architecture

MCP Toolkit: Contract Terms in the Context of MCP Deployment