People typing "figma mcp server" or "jira mcp server" into search are usually after the same thing: a connection between a tool they use every day and the AI assistant they already work in. For one of these four searches the thing being searched for doesn't exist in that form, and for two others the obvious guide leads past the official setup. So here they are in order, with what's actually available.
What such a connection is good for#
An MCP server is a bridge. On one side sits a program holding data, on the other an AI assistant, and between them runs a defined protocol the assistant can use to ask questions and trigger actions. Without that bridge you copy content across by hand. With it you say "take a look at this" and mean your actual file, your actual ticket, your actual merge request.
The difference matters more day to day than it sounds. An assistant that only sees your Figma design as a screenshot guesses spacing and colours. One that reaches the file through a connection reads the real values. That's the point where a nice toy turns into something that saves work.
Figma: two routes, and the local one isn't the recommended one#
Figma ships a server inside the desktop app. You enable it once in Dev Mode, after which it starts along with the file and listens locally on http://127.0.0.1:3845/mcp. That local connection needs no API key.
One caveat worth stating, because it usually gets skipped: local here describes the endpoint only. Whatever the assistant reads from your file, it then processes like any other context, and with a cloud assistant that means it goes to that provider. "Runs locally" is a statement about the connection path, not a data protection guarantee.
Alongside it there's a remote server, and Figma now recommends that as the default route. For Claude Code the shortest path is the official plugin:
claude plugin install figma@claude-plugins-official
What comes across is components, variables and styling information. Code Connect mappings come too, if that integration is set up in your project, otherwise not.
Then there are prerequisites that decide whether the connection is usable for you at all. The remote server is available on every plan and for every seat. The server inside the desktop app requires a paid plan and a Dev or Full seat. Code Connect additionally requires an Organization or Enterprise plan, again with a Dev or Full seat. How much you can retrieve on top of that depends on plan and seat. So if you're on the free plan, the remote route is the one that gets you there, not the local one.
Jira: there is no dedicated server for it#
This is where most guides get vague. Atlassian offers no separate official Jira server. There is one server for the whole house, and Jira sits inside it, alongside Confluence, Jira Service Management, Bitbucket Cloud and Compass. (Third-party servers exist, but they aren't the official connection.)
So anyone searching for "jira mcp server" is in fact setting up the Atlassian server. The same goes for "confluence mcp server" and "atlassian mcp server", three searches for one thing.
Sign-in deserves a closer look, because "OAuth or API token, take your pick" isn't accurate. The choice depends on the product: Jira Service Management and Bitbucket Cloud only work via API token, Compass only via OAuth 2.1. And API token sign-in has to be permitted by your organisation's administrator in the first place. Depending on which route you take, only part of the functionality will be available to you. Skip that check and you'll set the connection up and wonder why half of it is missing.
Where it does fit, the payoff is exactly that combination: an assistant can read a ticket against the Confluence page behind it, instead of seeing the two separately.
GitLab: official, but tied to prerequisites#
GitLab has its own server, built into the application. It arrived in version 18.3 as an experiment, has been in beta since 18.6, and the direct HTTP transport came with 18.6 as well. Beta here means what it says: expect details to keep moving.
You connect over HTTP at your instance's address:
https://<your-gitlab-instance>/api/v4/mcp
Sign-in is where it matters, and this is the mistake many guides pass along: the officially documented route runs through OAuth 2.0 with dynamic client registration, not through a personal access token you create yourself. Anyone searching for "create a token with the api scope" is following a guide for GitLab's other interfaces, not this one.
On top come prerequisites that often go unmentioned: GitLab Duo has to be available, beta and experimental features have to be enabled, and MCP access has to be switched on. If you'd rather go through an intermediate layer, mcp-remote works as a proxy, which requires Node.js version 20 or newer. The direct HTTP route is the recommended one and does without that dependency.
Playwright: the assistant drives the browser#
Playwright is the odd one out here, because it isn't a data store but a browser control tool. Microsoft publishes the official server for it; unlike Atlassian's, it isn't a hosted service but runs on your own machine. Connected up, an assistant can open pages, click, fill in forms and report back what it found.
The interesting part is less about automating tests and more about being able to send an assistant to go and look. "Open the page and tell me whether the form submits" used to be an instruction that needed a person. The server returns structured snapshots of the page rather than plain screenshots. That's the basis on which the assistant can click deliberately at all; it doesn't replace a real WCAG accessibility audit, even if the data format is reminiscent of one.
Which of these is worth it for a business#
Honest placement: these four connections are developer tools. If nobody in your company works with Figma, Jira or GitLab, they do nothing for you.
What's interesting is the principle underneath. An MCP server isn't limited to developer software. The same bridge can be built to an inventory system, a booking system, a customer database. The difference is that the large vendors now ship their bridge ready-made, and a smaller piece of industry software generally doesn't.
That's exactly where our work starts: we build the connection to the systems that have none, so an assistant works with your real data instead of whatever someone pasted in. What that looks like is on the AI connector page, and if you want to know what sits behind the protocol itself, the piece on MCP explained covers it.
The short version#
Figma has two routes, local and remote, and now recommends the remote one; what you can retrieve depends on your plan. Jira, Confluence and Bitbucket share a single Atlassian server, no official Jira-only server exists, and your sign-in method partly decides which functions you get. GitLab has had a server since 18.6 in beta, connected through OAuth and requiring an active GitLab Duo. Playwright comes from Microsoft, runs locally and drives the browser rather than serving data.
For all four the real effort isn't the setup anyway. It's what comes after: working out what you actually use the connection for day to day.
