One of the most useful patterns for enterprise AI is also one of the least flashy: make the model a governed interface over a system the business already trusts. In this case, that meant giving Claude a narrow, auditable way to work with documents in Microsoft 365, then extend that workflow into DocuSign draft envelope creation.
The goal was not to build a general-purpose document chatbot. The goal was to let a team manage a specific document workflow from inside a Claude Project without expanding access beyond what the workflow required.
The useful MCP pattern
MCP is strongest when the tool surface is small, named in business language, and backed by real authorization boundaries. The connector should expose what the user is allowed to do, not everything the underlying API can do.
The Shape of the System
The connector ran as a Python MCP server hosted on Azure Container Apps. Claude connected to the MCP endpoint; the server handled Microsoft Graph calls against a tightly scoped SharePoint document library. The tool surface covered read-heavy document operations plus one outbound action: create a draft DocuSign envelope for human review.
Claude Project
Business users ask for document lookups, counterparty context, expiration status, or a draft envelope.
Python MCP Server
Tool handlers translate business actions into Graph and DocuSign API calls with explicit inputs.
Azure Runtime
Container Apps, Key Vault, Managed Identity, and ingress controls keep the service deployable and governable.
The key design choice was to avoid a broad "search SharePoint" tool. Instead, the connector exposed specific operations: search documents, look up counterparties, retrieve document details, list upcoming expirations, and create a DocuSign draft envelope. That naming matters because every tool is a permission boundary and a prompt-design surface.
Graph Access Was the Real Security Boundary
Microsoft Graph can do a lot. That is exactly why the connector should not receive tenant-wide document access just because it needs one workflow. The implementation used app-only Graph access scoped to a single SharePoint site, with the access model designed around least privilege rather than convenience.
The connector only needed a defined SharePoint location, so the Graph permission model was narrowed to that site rather than a whole tenant.
Runtime secrets lived in Azure Key Vault and were accessed through managed identity. Nothing sensitive belonged in the container image or repository.
The public endpoint used HTTPS ingress controls and an unguessable MCP path so the service was reachable by the intended connector flow without becoming a casual public API.
DocuSign Stayed Human-in-the-Loop
The DocuSign integration deliberately created draft envelopes rather than sending them automatically. That distinction is important. An agent can prepare the envelope, select the right source material, and populate the workflow, but final review and send authority should stay with a person when legal documents are involved.
This is the pattern we prefer for high-value business actions: let the agent remove mechanical work, but make the irreversible step explicit. The connector creates the draft; the human verifies and sends.
Read tools: search the library, find a counterparty, retrieve document details, list upcoming expirations.
Action tool: create a DocuSign draft envelope for review.
Not exposed: broad tenant browsing, arbitrary Graph calls, automatic envelope sending.
Deployment Matters as Much as the Tool Handler
The MCP code was only part of the work. A connector that touches Microsoft 365 and e-signature workflows needs a deployment path that an operator can understand and repeat. The deployment script built the container image, provisioned Azure resources, wired Key Vault access, configured environment variables, and applied the ingress settings.
That is the difference between a prototype and something a client can own. The handoff is not just "here is the server." It is "here is how the service is built, deployed, configured, and safely changed."
The Takeaway
The best enterprise MCP connectors are not giant API wrappers. They are small operational interfaces over systems that already matter. They translate a real workflow into a few controlled tools, then wrap those tools in cloud infrastructure, identity, logging, and deployment discipline.
If your agent needs Microsoft 365 access, the question is not "can Graph do this?" It is "what is the narrowest tool surface that lets the business work faster without widening the blast radius?"
Need a governed MCP connector or Microsoft 365 AI workflow? We design, build, harden, and hand off production agent integrations.
./book-discovery