MCP: What Changes When You’re the One Orchestrating?

AI used to answer me. Now it works inside my environment.

For a long time, my collaboration with AI followed roughly the same sequence: open a tab, write a prompt, read the answer, close the tab. Useful, but fundamentally disconnected from my real working environment. The AI knew nothing about my Figma files, nothing about my calendar, nothing about the decisions made the week before. I had to rebuild the context for it in every new conversation, as if it suffered from permanent amnesia.

Since I started using MCP, cautiously at first, then in a way that is increasingly woven into my day, something fundamental has shifted. I am no longer the one bringing context to the AI. The AI goes and fetches it where it lives, directly inside my tools.

This shift can look purely technical on the surface, but it is not. It touches directly how I make product decisions, how I run design audits, how I prepare client deliveries. And that is exactly what I want to talk about here: not the protocol itself, which Nolwen already explained very well in this article, but what actually changes when a PM or a freelance designer holds the reins.

The real change: from « AI that answers » to « AI that acts in my flow »

There is a distinction I find often underestimated in discussions around MCP: the difference between an assistant that answers questions and an agent that actually operates inside your working environment. Before MCP, AI was a consultative resource. I handed it a problem, it gave me an answer. That is already powerful, but the missing context created constant friction: explaining the project, pasting the specs, summarizing the history. You could easily lose half the exchange setting the scene before even starting to work.

With MCP, the scene is already there. The agent can read it directly in my tools, and that deeply changes my role in the exchange. I am no longer the one bringing the information, I am the one who formulates the intent and validates the output. That is what orchestrating means. Not coding or configuring all day long, but deciding what to ask, when, and with what level of confidence you validate the result.

A concrete example: MCP with Figma

The case that convinced me most is component auditing. On a recent project, I was working on a design system that had accumulated inconsistencies over several months, the kind of situation where every sprint left its little mark and nobody really had a global view of the file anymore. Before connecting Figma MCP to Claude Desktop, an audit like this took a full half-day: open each frame, note the gaps manually, then produce a summary table.

With the MCP connection in place, I could ask the agent directly to go through the file and identify the components whose internal padding was not aligned with our 8px system. It navigates the file, surfaces the inconsistencies, and produces a structured list. That leaves me only the review to do, instead of all the information gathering.

But what interests me most in this setup is not the raw time saved. It is the quality of the design conversation that becomes possible afterwards. Because the agent has access to the real file, we can reason about systemic consistency, compare component states, anticipate implementation problems, all with the file as a shared reference rather than an approximate description pasted by hand into a prompt. For a PM or a designer who constantly juggles product vision and execution, that is a considerable lever.

Google Calendar and Gmail: AI that understands my work rhythm

The other connection I use regularly is Calendar and Gmail through MCP. Less spectacular than Figma at first glance, but probably the one that changed how I structure my weeks the most, precisely because it acts on very frequent micro-frictions rather than one-off tasks.

Typical example: I have a project follow-up meeting in two hours and I want to prepare a quick status. Before, I opened my notes, my latest email threads, the specs doc, and assembled the whole thing mentally. Now I ask the agent to check the latest exchanges tied to the project, look at what was on the agenda of the previous meeting, and summarize the points still open. It walks into the meeting with me, in a way.

What this really reveals is that the value of MCP for a freelance does not come from the technical sophistication of the connection. It comes from progressively removing those micro-frictions that pile up: the five minutes lost finding an email, the ten minutes recapping the context of a project you have not touched in three days. Individually these are trifles, but added up over a week of juggling multiple projects, they represent a real cognitive load that, once relieved, frees up space for what actually matters.

What orchestration really demands

I want to be honest about a point that is often left unsaid: orchestrating MCP agents is something you learn. Not in the technical sense, since the configuration stays relatively accessible, but in the sense of the judgment it asks you to develop over time.

You have to build the intuition for when to delegate to an agent and when to stay in manual mode. Not every task lends itself to orchestration, and on sensitive topics, strategic trade-offs or high-stakes client conversations, I systematically keep control. The agent can prepare and summarize, but it does not decide in my place.

You also have to learn to formulate clear intentions without over-specifying everything. The best prompts I have written in this context are not the most detailed ones. They are the ones that give a precise goal and let the agent choose its paths through the connected tools. Finally, you have to accept a calibration phase. The first weeks, I had disappointing outputs, interpretations that were too broad, moments when the agent consulted the wrong resources. That is normal and it sharpens with use, exactly like any working tool.

Why this role is natural for a PM or a designer

What strikes me more and more is how well positioned the PM or designer profile is to get the most out of MCP, probably better than many purely technical profiles. We are trained to think in flows, in journeys, in logical chains. We know how to break a complex problem into actionable steps. We are used to working with multiple tools and moving information between them. And above all, we are used to articulating precise intentions, which is exactly what agent orchestration requires.

The PM who writes good tickets knows how to state a precise intent with a defined scope. The designer who writes good specs knows how to describe an expected state without prescribing every implementation detail. These skills, directly transferable to building agentic workflows, were already there long before MCP existed. In that sense, MCP does not create a new job. It reveals a skill that already existed in another form.

To finish

I am not claiming that MCP is indispensable for everyone right now. The ecosystem is still being built, some servers are more robust than others, and you have to stay careful about the permissions you grant, especially in a professional context with sensitive data.

But if you are a PM or a freelance designer already working with Claude or an equivalent every day, the question is no longer really whether you should look at MCP. It is which workflow in your week you would genuinely gain from by connecting your tools. For me, it was Figma. For you it might be something else, but there is very probably a first use case somewhere that deserves the question.