Building an AI-Powered Contract Price Adjustment Agent with Docusign MCP and Microsoft Foundry

Acknowledgment: Special thanks to the Docusign Partner Solution Architects team for the original source code and examples that informed this implementation; I adapted and extended that foundation to build the end-to-end agent described below.

The Enterprise Challenge

Every large organization faces the same operational headache: managing thousands of contracts—supplier agreements, service contracts, procurement deals—each containing price escalation clauses tied to economic indicators like the Consumer Price Index (CPI). The traditional approach involves teams manually tracking contract expirations, pulling inflation data from the Bureau of Labor Statistics (BLS), calculating adjustments in spreadsheets, and routing approvals through email chains.

This process is slow, error-prone, and doesn't scale.

We built something different: an intelligent agent that could automate this entire workflow end-to-end. The result is a system that:

• Discovers contracts expiring within a configurable window using Docusign's AI powered agreement repository - Navigator
• Retrieves real-time economic data from the BLS API
• Calculates inflation-adjusted prices based on CPI movements
• Initiates approval workflows through Docusign’s workflow builder -  Maestro
• Provides operational visibility via a real-time monitoring dashboard

The technical innovation that made this possible? The Model Context Protocol (MCP)—an emerging standard that fundamentally changes how AI systems interact with enterprise services.

Architecture at a Glance

The system is a workflow of three agents coordinated by a master orchestrator agent powered by GPT-5.1 through Microsoft Foundry, created via the  Foundry Agent Service. Each stage is handled by a specialized agent:

1. Agreement Finder —This agent queries Docusign's AI powered agreement repository, Navigator, via the Docusign MCP server to quickly find agreements expiring within 30 days
2. Value Calculator — Checks the BLS database for latest CPI value and computes new values for the agreements
3. Trigger Workflows — Queried by the same MCP server, this agent kicks off Docusign's workflow builder, Maestro, to route the updated agreements with adjusted prices for signatures.

The entire backend runs on Azure App Service which acts as a client, hosting the dashboard, executing tool functions locally, and submitting results back to Foundry. The user clicks "Start," the webhook returns immediately, and the agent processes asynchronously in the background—broadcasting status updates to the dashboard as it goes.

The Workflow in Practice

Phase 1: Contract Discovery

The agent queries Docusign Navigator to identify contracts requiring attention. Using the MCP getAllAgreements tool, it retrieves the full agreement repository and filters for those approaching their expiration date within the configured window.

Phase 2: Economic Data Retrieval

The BLS API provides authoritative CPI data for inflation calculations. The agent retrieves the Consumer Price Index series and calculates the period-over-period inflation rate between the contract's effective date and current date.

Phase 3: Workflow Orchestration

Docusign Maestro handles the approval routing. The agent triggers a workflow instance with the calculated adjustment data, including original value, adjusted value, and supporting documentation. Maestro then manages routing, notifications, and document generation.

Phase 4: Operational Visibility

The dashboard provides real-time status updates. As each phase completes, the system broadcasts updates to connected clients, enabling operational monitoring without polling or manual status checks.

The Strategic Advantage of MCP

Consider the alternative: traditional REST API integration. That approach requires:

• Studying multiple API surfaces (eSignature, Navigator, Maestro—each with distinct conventions)
• Implementing separate authentication flows for different service tiers
• Writing custom serialization logic for each endpoint's idiosyncratic response format
• Maintaining brittle integrations that fracture when APIs evolve

MCP collapses this complexity into a single, coherent protocol. The same client code that queries agreements can trigger workflows, manage templates, or invoke any future capability Docusign exposes—without modification.

The Docusign MCP server gives agents access to Docusign’s Intelligent Agreement Management capabilities as Docusign's AI engine, Iris, efficiently pre-processes agreement metadata, which means:

• Faster retrieval: Structured insights enable quick search and higher accuracy
• Secure and compliant: Interactions are governed by Docusign's permission-aware guardrails
• Efficient token usage: LLMs query pre-processed metadata rather than raw agreement text

Microsoft Foundry: The Reasoning Engine

The system's intelligence comes from four agents created via the Foundry Agent Service in Microsoft Foundry. Each agent is defined with its own instructions and tool schemas using Microsoft Foundry SDKs. The App Service creates agents at startup, then for each request:

1. Creates a thread per agent
2. Sends the context message
3. Starts a run
4. When the agent returns its action, executes the tool locally and submits results
5. Polls until the run completes

Azure App Service: The Runtime

The backend runs on a Linux App Service with Python 3.11. This configuration supports both standard HTTP requests and WebSocket connections through a single process. Key configuration:

• WebSockets enabled for real-time dashboard updates via Socket.IO
• HTTPS enforced with Azure-managed TLS certificates
• Environment variables configured through App Service Settings (Docusign credentials, BLS API key, MCP configuration)

Deployment is a single az webapp up command—Azure's Oryx build system detects the Python project, installs dependencies from requirements.txt, and starts the application automatically.

Built with Github Copilot Agent Mode

This entire system—from the first line of Flask boilerplate to a running Azure App Service—was built and deployed using GitHub Copilot in VS Code powered by Claude Opus 4.6. The agent mode transformed what would have been days of scaffolding into a rapid iteration loop: describe what you want, watch it write the code, review, adjust, repeat.

Just with one request to Github Copilot, it was able to take the base source code, built by Docusign Partner Solution Architects, to run locally, and deploy it all to Azure, from the App Service to the Foundry agents. By chatting with Copilot, I was able to:

• Wiring up integrations — point Copilot to use Docusign MCP and the BLS API docs. It produced the MCP client with OAuth token management and the BLS CPI calculation logic—including edge cases like partial data and missing series IDs.
• Azure deployment — go from local Flask app to a deployed App Service in a single conversation. Copilot generated the startup script with the correct Gunicorn/eventlet configuration, helped configure App Service settings, and iterated through deployment errors in real time—reading az webapp output and adjusting.
• Debugging in production — when the deployed app hit issues (Managed Identity permissions, content filter blocks, WebSocket configuration), the iteration cycle was: pull logs → paste into chat → get a fix → deploy → verify. Problems that would normally require context-switching between docs, Stack Overflow, and Azure Portal were resolved inline. All of this could be done hands-free, as the agent was able to debug and redeploy by itself until the app worked.

The key insight: using Github Copilot with the Claude Opus 4.6 model in agent mode doesn't just autocomplete lines—it holds the full architectural context across a long session. It remembered that the Foundry client uses async, that the MCP client needs token refresh before each call, that the App Service needs --sku S1 for WebSocket support. That continuity eliminated an entire class of "I forgot to update the other file" bugs and made the build-deploy-debug loop feel like pair programming with someone who never loses context.

Why MCP Represents the Future

Universal Tool Semantics: MCP establishes a common language for AI-to-service communication. Rather than training models on proprietary API conventions, they can discover and invoke tools through a standardized interface. This is the foundation for truly general-purpose AI agents.

Compositional Architecture: Because MCP tools are self-describing, agents can orchestrate across multiple services without hardcoded integration logic. This agent composes Docusign for documents, BLS for economic data, and Microsoft Foundry for reasoning—each component remaining independently evolvable.

Forward Compatibility: As service providers add capabilities, they appear as new MCP tools—discoverable and invocable without client-side changes. This inverts the traditional integration maintenance burden.

The AI-Native Enterprise: MCP represents the infrastructure layer for organizations where AI agents are first-class participants. When every enterprise service speaks this protocol, the boundary between human-driven and AI-driven work becomes fluid.

Conclusion

This project demonstrated that sophisticated enterprise automation is achievable when the right abstractions are in place. The Model Context Protocol provides exactly that—a clean interface between AI reasoning and enterprise capability.

The architecture combines:

• Docusign MCP for unified access to agreement insights, workflow orchestration, and end to end agreement management
• Microsoft Foundry for secure, scalable AI inference with enterprise governance

This architecture demonstrates how Microsoft’s agent ecosystem supports customers across the full spectrum of development choices. The same MCP-enabled agents built pro‑code in Microsoft Foundry can be made via Copilot Studio and surfaced inside everyday M365 productivity tools, enabling organizations to operationalize agentic workflows wherever work already happens. By pairing MCP with both low‑code (Copilot Studio) and pro‑code (Foundry) approaches, customers can start where they are, scale as needed, and meet diverse developer and business requirements—without re‑architecting their agent framework.

As MCP adoption grows across the enterprise software landscape, the patterns established here will become foundational. The agents we build today are prototypes for the AI-native organizations of tomorrow.

The future of enterprise software isn't just AI-assisted—it's AI-orchestrated. MCP is the protocol that makes that future possible.

Built with Docusign MCP, Microsoft Foundry, and a commitment to the agentic enterprise.

Try it yourself: - 🚀 Clone the repository to explore

Learn more about the technologies: 

• Docusign MCP Server documentation
• Microsoft Foundry Agent Service Overview
• Learn more about MCP

Join the conversation: - Share your MCP implementation experiences in the comments below