kristymerriam
Administrator
Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
52m ago
ServiceNow Build Agent MCP Servers: Jira, Figma, Postgres, Zoom, and More
ServiceNow Build Agent now supports 10 MCP (Model Context Protocol) integrations, letting you pull live context from Jira, Figma, Miro, Postgres, Zoom, and Docusign directly into your app builds.
Table of Contents
- Complete list of ServiceNow Build Agent MCP integrations
- Setting up your MCP connections
- Walkthroughs
- Why governed matters here
- FAQ
A lot of the work that goes into building a ServiceNow app doesn't happen in ServiceNow. Requirements live in places like Jira or Linear. Designs are in Figma. Your team's process flows are mapped out on a Miro board. Data schemas are in Postgres. And the decisions that shaped the whole thing happened on a Zoom call! Getting all of that context into a build has always been manual and prone to error... you copy specs between windows, re-explain your architecture and hope nothing critical falls through the gaps.
Build Agent supports 10 MCP (Model Context Protocol) server integrations. Connect them and Build Agent reads from your source material directly (the Jira ticket, the Figma frame, the Miro board, the Postgres schema) instead of whatever you managed to reconstruct in the prompt. The result is a first draft grounded in what you already have, not your reconstruction of it.
This post covers the full list of supported integrations, how to set them up, and how to use them. We'll keep it updated as new integrations are added.
Worth being direct about what these connections change: Build Agent's first draft is only as good as the context it has to work from. Give it the real Jira ticket and the Postgres schema, and it generates something pretty close to right. Describe those same things in a prompt, and it fills gaps on its own. Sometimes well, sometimes not so much.
Complete list of ServiceNow Build Agent MCP integrations
10 MCP servers are now live in Build Agent. Figma, Miro, and Prisma Postgres were announced at K26. Everything else is new with this release:
- Figma: Connect a Figma frame and Build Agent reads the component layout directly, generating a UI page from your actual design.
- Miro: Planning boards, workflow diagrams, and process maps become live build input instead of reference documents.
- Linear: Issues, acceptance criteria, and requirements read directly into the build.
- Atlassian Rovo: Jira tickets, Confluence docs, and acceptance criteria feed directly into the build.
- Prisma Postgres: Live schema introspection means the app Build Agent generates is grounded in your real data model, not a placeholder.
- Docusign: Existing signature templates and envelope routing read into workflow builds directly.
- Zoom: Meeting transcripts become build context, so decisions from calls stop getting lost before they reach the code.
- Zoom Chat: Chat threads and shared decisions feed into what you're building.
- Zoom Docs: Shared specs and runbooks are read as direct build input.
- Zoom Whiteboard: Sketches from live sessions become buildable input rather than screenshots.
MCP (Model Context Protocol) is the open standard Build Agent uses to connect to these tools securely. It's not a copy-paste bridge. Build Agent reads live context from the connected tool while it builds.
Each integration is enabled through the MCP settings panel in Build Agent inside ServiceNow Studio or IDE. Some MCPs will also allow writing back to the server. For example, using the Linear MCP, you can ask Build Agent to solve a task, complete it, and comment on what was done to solve it.
Setting up your MCP connections
Before you dive into the walkthroughs, it's worth understanding how setup works — because there's a piece here that trips people up if they don't know it going in.
Setup happens in two stages, and each belongs to a different role. First, an admin connects each MCP server at the instance level through the Workflow Data Fabric Connect Hub and approves the new MCP in AI Control Tower. That's what puts a server on the instance and makes it available. Then, each developer individually authenticates against the servers via personal integrations for the MCP servers they want to use inside Build Agent. These are separate steps — an admin setting up Figma in Connect Hub doesn't mean it's active in your Build Agent session. You still need to connect to it personally, and that connection uses your own credentials, not a shared account.
Which servers appear in your Build Agent settings depends on what's been set up on your instance. Which ones are active in your session depends on which ones you've personally connected to. That distinction matters when something isn't showing up where you expect it.
A few things worth knowing before you start:
- Studio requires Australia Patch 3 or higher. MCP connections work in both ServiceNow Studio and the IDE, but Studio has a minimum patch requirement. Check your version before you start.
- Each Zoom integration needs its own Zoom app. Zoom, Zoom Chat, Zoom Docs, and Zoom Whiteboard are separate MCP servers, and Build Agent doesn't support multiple servers connecting to a single Zoom app. You'll need one dedicated Zoom app per integration.
- Your first connection to each server requires an Allow step. After that, it's a toggle — you don't go through authorization again unless your token needs to be refreshed.
- These integrations depend on the provider's MCP server being available. Build Agent connects to each tool through that tool's own MCP server. If Figma's server is down, the Figma integration won't work — that's an external dependency, not a ServiceNow issue. It's the same behavior you'd expect from any API call to an outside service. If an integration that was working suddenly stops responding, check the provider's status page before opening a support case.
The full step-by-step setup — Connect Hub configuration, Build Agent settings panel, OAuth flows — is in the docs. The videos in the section below walk through both stages end-to-end. We're publishing them integration by integration, starting with Linear — the rest are on the way.
📄 Setup docs: Model Context Protocol connectors in Connect Hub · Enable MCP servers in Build Agent
Setup videos
Each video walks through both setup stages end-to-end: the admin connection in Connect Hub and the approval in AI Control Tower, then the personal authentication inside Build Agent.
Linear MCP
Coming soon: Figma, Miro, Atlassian Rovo, Prisma Postgres, Docusign, Zoom, Zoom Chat, Zoom Docs, and Zoom Whiteboard.
Walkthroughs
From a Linear issue and Figma design to a working app
With the Linear and Figma MCPs connected, Build Agent reads your ticket and design frame directly and generates a UI page, custom table, and Flow Designer flow in one pass.
The requirement and acceptance criteria are in Linear. The UI spec is in Figma. Normally that means reading both, then rebuilding everything by hand: the Linear ticket becomes a paraphrased prompt, the Figma frame becomes an approximation you describe and hope is close enough.
An example prompt:
Use the Linear MCP to pull LIN-482, and use the Figma MCP to read
the linked UI frame. Build the feature with the form's 'priority'
field driving a conditional approval step.
And just like any other app, deployment is reviewed, approved, and governed through App Engine Management Center.
🎥 Linear + Figma walkthrough video coming soon. Setup walkthroughs for the Linear and Figma MCPs: see Setup videos.
From a Miro board to a working workflow
With the Miro MCP connected, Build Agent reads your board, identifies stages and conditional branches, and generates the corresponding Flow Designer flow. The diagram your team aligned on becomes the build.
Your team spent time on that Miro board: stages, decision points, the routing logic, what happens on reject. Everyone reviewed it, aligned on it. And then it sat there as a reference you rebuilt from memory when it came time to build.
An example prompt:
Use the Miro MCP to read the approval flow on this board, and build
it as a workflow in ServiceNow.
This is worth distinguishing from Zoom Whiteboard, which is covered below. Miro is where deliberate planning happens. What's on that board is the output of a design process. It's been reviewed, refined, and agreed on. Build Agent turning it directly into a runnable workflow means that alignment survives all the way into the code, and doesn't just sit in a document that gets referenced once and filed away.
🎥 Miro walkthrough video coming soon. Setup walkthrough for the Miro MCP: see Setup videos.
From a Jira ticket and Postgres schema to a working app
With the Atlassian Rovo and Prisma Postgres MCPs connected, Build Agent reads your Jira ticket and introspects your live Postgres schema, so the app it generates is grounded in your real data model from the first draft. No placeholder tables to rewire later, no schema drift between what got built and what's in your database.
Same pattern as Linear but with enterprise scale. The requirement lives in Jira. The data the app needs is already in a Postgres database.
An example prompt:
Use the Atlassian Rovo MCP to read PROJ-1203, and use the Prisma
Postgres MCP to read our partner and contract tables. Build the
partner-onboarding tracker.
The Confluence access through Atlassian Rovo also means any relevant runbooks or documentation attached to the ticket are part of what Build Agent reads, not just the ticket itself.
🎥 Jira + Postgres walkthrough video coming soon. Setup walkthroughs for the Atlassian Rovo and Prisma Postgres MCPs: see Setup videos.
From a Zoom meeting to a workflow
With Zoom connected, Build Agent reads meeting transcripts, shared docs, and whiteboard sessions, turning decisions made on calls into direct build context. Meeting transcripts surface decisions and open questions. Zoom Docs let you use a shared spec or runbook as direct build input. Zoom Whiteboard covers live sessions, turning in-call sketches into buildable input rather than screenshots.
Because Zoom, Zoom Chat, Zoom Docs, and Zoom Whiteboard are four separate MCP servers, each one needs its own dedicated OAuth app in Zoom — Build Agent can't point multiple servers at a single app. Create one app per integration, grant the scopes listed below, then connect each one in Build Agent. The videos walk through setting up each app end to end.
Zoom meeting transcripts
Scopes required: https://developers.zoom.us/docs/mcp/zoom/
Decisions made on calls have a way of never making it into the build.
An example prompt:
Use the Zoom MCP to pull the transcript from yesterday's design
review. Build the approval workflow we agreed on in that call.
🎥 Zoom meeting walkthrough video coming soon. Setup walkthrough for the Zoom MCP: see Setup videos.
Zoom Chat
Scopes required: https://developers.zoom.us/docs/mcp/zoom-chat-mcp-server/
🎥 Setup walkthrough for the Zoom Chat MCP: see Setup videos.
Zoom Docs
Scopes required: https://developers.zoom.us/docs/mcp/zoom-docs-mcp-server/
🎥 Setup walkthrough for the Zoom Docs MCP: see Setup videos.
Zoom Whiteboard
Scopes required: https://developers.zoom.us/docs/mcp/zoom-whiteboard-mcp-server/
🎥 Setup walkthrough for the Zoom Whiteboard MCP: see Setup videos.
Signature workflows with Docusign
With the Docusign MCP connected, Build Agent reads your existing signature templates and builds envelope routing, completion triggers, and status tracking into the app. The signed record stays attached to the workflow record in ServiceNow, so it's useful anywhere a sign-off needs to be tied to an app action: vendor onboarding, access agreements, policy acknowledgments.
Docusign opens up apps that originate, route, and track signature workflows: contract reviews, policy acknowledgments, anything where a legally binding record of sign-off is part of the process.
An example prompt:
Use the Docusign MCP to look up my contract review templates and
build a workflow that routes the completed document back to the
requestor on signature.
🎥 Docusign walkthrough video coming soon. Setup walkthrough for the Docusign MCP: see Setup videos.
Why governed matters here
AI coding tools made it easy to generate apps fast, and that created a problem IT already has a name for: shadow AI. Tools and automation running outside the systems your organization manages. Apps that pile up faster than they can be reviewed, secured, or even inventoried.
Build Agent takes a different approach.
How ServiceNow Build Agent is different from GitHub Copilot and other AI coding tools
Unlike Copilot or Cursor, Build Agent runs inside the Now Platform and builds against your actual data model, CMDB, and governance policies from the first draft.
Three things make that concrete:
- Platform-native context. When Build Agent reads your Figma frame or your Jira ticket, it's not generating in a vacuum. It builds against the ServiceNow platform: your data model, your permissions structure, your existing workflows, your CMDB. That context isn't available to any external AI coding tool. An AI assistant in your IDE doesn't know your change management process. It doesn't know the relationships between your tables or the policies controlling how data moves through your organization. Build Agent does, because it's running inside the platform that manages all of it. When it generates an app, it's building against your actual Now Platform data model: your infrastructure relationships, your existing workflows, the policies that control access and routing. You don't write API calls to wire those things in; the platform is the context. Apps inherit that from the first draft, not patched in after.
- Governance before deployment. Everything Build Agent generates goes through App Engine Management Center before it touches production. AEMC is a review gate: your security, compliance, and IT governance teams evaluate what's being deployed and under what conditions. The app doesn't ship until that review clears. That's not a policy you enforce reactively after things go wrong; it's built into the deployment path by default.
- Deployment confidence. Once an app is live, it inherits the platform's audit trails, access controls, and compliance posture. You know who built it, what it does, what data it touches, and when anything changed. Not because someone added observability later. It's the runtime every app on the platform runs in.
Teams building on App Engine are already seeing this. Hitachi Vantara reported a 40% reduction in time spent building forms and workflows. Yokogawa improved development speed by 30%. The MCP connections in this release feed into that same runtime: more of your existing context coming in, the same governed platform on the other end.
The point of 10 MCP integrations isn't that there are more tools connected. It's that more of your existing workflow now feeds into one place where everything you build is sanctioned, auditable, and controlled.
FAQ
Does ServiceNow Build Agent support MCP?
Yes. Build Agent works as an MCP client, which means it connects to external tools that expose an MCP server and reads context from them directly while it builds. 10 MCP integrations are currently live: Figma, Miro, Linear, Atlassian Rovo (Jira + Confluence), Prisma Postgres, Docusign, Zoom, Zoom Chat, Zoom Docs, and Zoom Whiteboard.
What tools can I connect to Build Agent?
10 MCP integrations are now live: Figma and Miro for design and ideation; Linear and Atlassian Rovo (Jira + Confluence) for project tracking; Prisma Postgres for data; Docusign for agreements; and Zoom, Zoom Chat, Zoom Docs, and Zoom Whiteboard for collaboration. Enable each through the MCP settings panel in Build Agent inside ServiceNow Studio.
How do I connect Jira to Build Agent?
Jira connects through the Atlassian Rovo MCP. Enable it in the MCP settings panel in ServiceNow Studio, then reference it explicitly in your prompt: "Use the Atlassian Rovo MCP to read PROJ-1203." This also gives Build Agent access to any Confluence documentation linked to the ticket.
Can I use a Figma design to build a ServiceNow app?
Yes. With the Figma MCP connected, you can point Build Agent at a specific Figma frame and it reads the component layout directly, then generates a UI page and data model based on the design. Early testing showed initial UI and data-model implementation time reduced by over 80% compared to building from a manual description.
Why is my MCP integration not working?
The most common reasons: the MCP server isn't enabled in your Build Agent settings, you haven't personally connected to it yet (it's a per-user step, not just an instance setting), or the provider's MCP server is temporarily unavailable. Build Agent connects to each tool through that tool's own external server — if Figma, Miro, or any other provider has an outage or API issue, that integration won't work until it's resolved on their end. Check the provider's status page before filing a support case with ServiceNow.
How is Build Agent different from GitHub Copilot?
Build Agent runs inside the ServiceNow platform, which means it builds against your actual Now Platform data model, CMDB, and governance policies. GitHub Copilot and tools like Cursor generate code in your editor without access to your platform context. Everything Build Agent generates also goes through App Engine Management Center before it deploys, so governance is part of the build path by default, not something you manage separately.
Drop a comment below with what you build and which integration you connect first.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
