Agentforce Vibes Meets Azure DevOps MCP: From ADO Work Items to Custom Objects Without Leaving VS Code

You have six new user stories sitting in Azure DevOps. Custom objects. Custom fields. Validation rules. Page layout updates. The old workflow? Open ADO in one browser tab. Salesforce Setup in another. VS Code in a third. Copy-paste acceptance criteria into code comments like a human clipboard. Bounce between three tools for an hour before writing a single line of metadata.

The new workflow? You type one natural language prompt. Agentforce Vibes reads your org schema, GitHub Copilot pulls the ADO work item, and the Salesforce DX MCP Server deploys the metadata to your scratch org. All inside VS Code. Zero browser tabs. Zero context switches. This is what enterprise vibe coding actually looks like.

TL;DR: By wiring up the Azure DevOps MCP Server alongside Agentforce Vibes and the Salesforce DX MCP Server in a single VS Code workspace, you create a triple-context AI development loop. GitHub Copilot reads your requirements from ADO. Agentforce Vibes generates org-aware Apex, custom objects, and fields using Plan and Act modes. The DX MCP Server deploys everything. Work items go from backlog to deployed metadata in minutes.

The Real Problem: Your AI Assistant Has No Idea What You’re Building

Here is where most Salesforce AI coding setups fall short. You fire up GitHub Copilot or Agentforce Vibes, and it can write decent Apex. It can scaffold a Lightning Web Component. But it has zero context about why you are building it.

The acceptance criteria live in Azure DevOps. The data model lives in your Salesforce org. The code lives in your SFDX project. Three systems, three contexts, and your AI assistant can only see one of them at a time.

Model Context Protocol changes that equation. MCP is an open standard that gives AI assistants structured access to external tools and data. Instead of one MCP server, you run multiple servers simultaneously. Each one gives the AI a different lens into your world.

The Triple-MCP Setup: ADO + Agentforce Vibes + Salesforce DX

The magic happens when you combine three MCP-powered layers in a single VS Code workspace.

Layer 1: Azure DevOps MCP Server reads your work items, acceptance criteria, and sprint context. It uses domains like core, work, and work-items to expose just the tools your AI needs.

Layer 2: Agentforce Vibes is Salesforce’s enterprise vibe coding extension, now powered by Claude Sonnet 4.5. It understands your org’s metadata, schema, and existing code patterns before generating anything. Its Plan mode analyzes requirements and produces an implementation plan. Its Act mode writes and modifies files.

Layer 3: Salesforce DX MCP Server provides 40+ tools for metadata operations, SOQL queries, deployments, Apex test execution, and org management. This is the execution layer that connects Agentforce Vibes to your actual Salesforce environment.

Here is the .vscode/mcp.json configuration that ties it all together:

{
  "inputs": [
    {
      "id": "ado_org",
      "type": "promptString",
      "description": "Azure DevOps organization name"
    }
  ],
  "servers": {
    "ado": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y", "@azure-devops/mcp",
        "${input:ado_org}",
        "-d", "core", "work", "work-items"
      ]
    },
    "salesforce": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y", "@salesforce/mcp",
        "--orgs", "my-scratch-org",
        "--toolsets", "orgs,metadata,data,users",
        "--tools", "run_apex_test",
        "--allow-non-ga-tools"
      ]
    }
  }
}

A few critical details here. The -d core work work-items flags on the ADO server use domains to load only work-item-related tools. Azure DevOps exposes a huge surface area, and loading everything can confuse the model and hit the roughly 20-tool limit that MCP clients work best within. On the Salesforce side, the metadata toolset is what lets Agentforce Vibes and Copilot deploy and retrieve metadata components directly.

You will also want a .github/copilot-instructions.md in your project root:

This project uses Azure DevOps for work tracking and Salesforce DX 
for development. Always check the Azure DevOps MCP server for work item
context before generating code. Follow Salesforce metadata API 
conventions for custom objects and fields. Use API version 62.0.
Enforce bulkification in all Apex code.

Once both servers are running, open Agentforce Vibes from the sidebar icon and enable the Salesforce DX MCP server. Switch Copilot Chat to Agent Mode. You now have two AI surfaces with shared MCP context.

The Walkthrough: ADO User Story to Deployed Custom Object

Let us trace a real scenario end to end. Your team has a user story in Azure DevOps:

Get RAMAKRISHNAN SAKTHIVEL’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Work Item #4521: “As a sales manager, I need a Customer Feedback custom object with fields for Rating (picklist: 1–5), Feedback Date (date), and Comments (long text area), linked to the Account object, so I can track post-sale satisfaction.”

Step 1: Pull the Requirement with Copilot Agent Mode

In GitHub Copilot Chat (Agent Mode), type:

Read work item 4521 from ADO and summarize the custom object
and field requirements, including field types and relationships.

Copilot calls the wit_get_work_item tool from the ADO MCP Server, retrieves the full description, acceptance criteria, and child tasks. It returns a structured breakdown without you ever opening a browser.

Step 2: Plan with Agentforce Vibes

Switch to the Agentforce Vibes panel. Set the mode toggle to Plan. Enter:

Based on this requirement, plan the implementation for a 
Customer_Feedback__c custom object with Rating__c (picklist 1-5),
Feedback_Date__c (date), and Comments__c (long text area). 
Include a master-detail relationship to Account. Consider 
validation rules and a basic page layout.

Agentforce Vibes in Plan mode does something no generic AI assistant can do. It introspects your actual org’s metadata first. It checks whether a Customer_Feedback__c object already exists, reviews the Account object's current relationships, and generates an implementation plan that accounts for your org's real state. No hallucinated field names. No conflicts with existing schema.

Step 3: Execute with Act Mode

Toggle Agentforce Vibes to Act mode. Enter:

Execute the plan. Create the Customer_Feedback__c object 
definition, all custom fields, the master-detail relationship
to Account, and a page layout. Place files in the correct
force-app/main/default directory structure.

Agentforce Vibes generates the object XML, individual field metadata files, and a page layout. Because it operates through the Salesforce DX MCP Server, the generated files follow SFDX directory conventions exactly.

Step 4: Deploy via MCP

Stay in the Agentforce Vibes chat or switch to Copilot:

Deploy the Customer_Feedback__c metadata to my scratch org
and confirm it was created successfully. Then describe the 
new object and verify all fields are present.

The DX MCP Server pushes the metadata and runs a describe call. You see the field names, types, and API names confirmed right in the chat response.

Step 5: Close the Loop in ADO

Back in Copilot Agent Mode:

Update work item 4521 in ADO to "In Progress" and add a comment:
"Customer_Feedback__c object deployed to scratch org with 
Rating__c, Feedback_Date__c, Comments__c fields and 
master-detail to Account."

The ADO MCP Server handles the status change and comment. Your PM sees the update on the board. The entire flow took five prompts and roughly eight minutes.

Pro Tips for the Triple-MCP Workflow

• Start every task in Plan mode. Agentforce Vibes in Plan mode consumes fewer requests than Act mode and catches architectural issues before code generation. Salesforce recommends using Plan before Act to stretch your request allocation.
• Be surgical with ADO domains. Only load core, work, and work-items. Loading repos, pipelines, and wikis alongside 40+ Salesforce DX tools creates tool overload and degrades response quality.
• Use copilot-instructions.md as your guardrails. Define naming conventions, API versions, field-level security defaults, and bulkification rules. Both Copilot and Agentforce Vibes will respect these instructions.
• Chain prompts across AI surfaces. Read requirements in Copilot Agent Mode, plan in Agentforce Vibes Plan mode, execute in Act mode, deploy via DX MCP, and update ADO via Copilot. Each tool excels at its specific stage.
• Always target a scratch org or sandbox. Never point the Salesforce DX MCP Server at production. Agentforce Vibes does not deploy anything unless you explicitly ask, but when you do, make sure the target is disposable.
• Leverage Agentforce Vibes skills and rules. Create custom rules with /newrule to enforce your team's coding standards. Agentforce Vibes can auto-load relevant skills based on the task context, giving you consistent output across your team.

Why This Changes the Game for Salesforce Teams

The fundamental shift here is not about any single AI tool getting smarter. It is about context unification. When your AI assistant can simultaneously see the what (ADO work items), the where (your Salesforce org schema), and the how (SFDX metadata conventions), it stops generating generic boilerplate and starts generating implementation-ready artifacts.

Agentforce Vibes brings something no general-purpose coding agent can match: deep Salesforce context awareness backed by the Einstein Trust Layer. It reads your org before writing a single line. Combined with the ADO MCP Server feeding in requirements, you have an end-to-end development loop that eliminates the three-tab shuffle most Salesforce teams live in every sprint.

Salesforce reported 100 million lines of code accepted through Agentforce Vibes since launch, and a 22x surge in monthly usage. That is not hype. That is developers finding genuine velocity.

Your Move

If you are on a Salesforce team using Azure DevOps, try this setup in your next sprint. Spin up a Developer Edition org (it is free, and now includes Agentforce Vibes with Claude Sonnet 4.5 and Hosted MCP Servers at no cost). Wire up the ADO MCP Server. Pick one user story and take it from ADO work item to deployed scratch org without opening a browser.

Time yourself. Compare it to your last sprint. Then tell your team.

What is the first custom object you would build with this workflow? Drop it in the comments.