In a recent Claude Code session I tried using the Google Docs, Drive, and Sheets MCP and was honestly surprised at how limited it felt. It was hard to get anything meaningful done because it just did not expose enough capability to be useful in practice. In hindsight, that frustration was probably a good thing. I ended up skipping MCP entirely and using the LaTeX API plus its plugin ecosystem, and the result was far beyond anything I could have realistically produced through Docs anyway.
I have seen a similar pattern with Canva’s MCP. I pay for Pro, but the one feature that would actually make MCP useful, Auto Fill, is gated behind an enterprise plan. So the surface is there, but the real power is locked away.
I get that this is still the wild west for MCP, and I agree with the OP’s general take. But right now there is a big gap between "integration exists" and "integration is actually useful." Personally, I am more excited about where something like WebMCP could go, where the default assumption is full capability rather than a restricted subset.
The result is less that I want to go to Figma directly and more that I just want to skip it entirely. So, assuming the power of these aggregator agents keeps growing, the onus is on these tools to create useful integrations or get subsumed by a model capability or another tool with a better integration. It sounds like your experience is similar - you bypassed the tools with bad integrations instead of going to them directly.
You have to be very very careful with this stuff. These SaaS companies have tons of paying customers giving them thousands of dollars a month. If customers mess up with an officially supported MCP and delete their assets or break implementations or DDOS their own site it’d be nightmare for sales / support.
It makes sense they very slowly transitioned from read-only to limited write. You have to carefully beta test. Both figuring out the guardrails and finding usecases where it actually works well. The only way to do that (properly) is a slow drip release cycle.
I had same experience with Databricks. The built-in MCP offering is very limited (querying, etc.) but there are community-built projects that offer the full scope (creating ETL jobs, etc.). I would prefer not to have to go through the hassle of getting some random project on GitHub added as an artifact and deal with the updates.
All SaaS-built MCP servers should cover the entirety their existing API functionality. I know it sounds like a lot but I really don't think it is an unreasonable expectation.
I attended a design conference last week where Figma has been basically delegated as a design library tool, and that was it. They'd use it as a source of truth for components such as buttons, colors, typography, etc, but the actual design work that was being done was done through Claude Code. Multiple designers who had this stack said that they preferred it as their designs were now closer to what the end user would experience (i.e. code). One person actually eschewed Figma completely and used Storybook as the source of UI truth. I think that Figmas moat is a lot smaller than people think and that within a year or 2 there's going to be some very solid competitors out there.
SaaS products are headed to where the UI isn't the undifferentiated factor. People have been so busy building a UI that works for everyone so it works for no one. The real value is the data and the workflow they provide. Make the data accessible to agents (MCP, OpenClaw skills, etc0.
Completely agree. Every SaaS tool will come with an MCP or an API to leverage composability. We can unlock useful functionalities from Claude Code and other aggregators (terminology from the post) to be able to compose different MCP's from different SaaS. One can imagine composing the results from a google search and using it in for a Figma design attempt, as a simple example.
This is an obvious direction that the industry is heading to. But what are the implications of this? I think the differentiating factor of having a good UI will reduce - productivity apps and SaaS will no longer have their aesthetic UI as a moat. I'm not sure whether this will tank their stocks or increase the valuation but what I'm sure of is that the productivity and usage will increase.
Actually... their MCP reflects more than just supporting AI. It demonstrates the future of closed, walled garden MCPs.
While Figma advertises that their official MCP "can now write directly to your Figma files", in reality it is restricted to create and read (as in CRUD), but not update nor delete. Currently, there is only one option to edit/update using the Figma MCP and it requires going through a third-party service with its own subscription and tiny token allocations.
Meanwhile, several developers have figured out how to use Figma's plug-in system to work-around these limitations, for a more robust CRUD MCP solution.
Could the limited MCP support be due to security concerns?
I've seen a number of stories about LLMs going rogue and messing things up (dropping databases, making unwanted changes, etc). Also, apparently there are security concerns with the MCP protocol itself.
MCP is a stopgap measure. What we need is for files and applications to exist within the same environment. That ultimately means a new OS. So yes, for the first time in decades, there will be new OSes competing.
48 comments
I have seen a similar pattern with Canva’s MCP. I pay for Pro, but the one feature that would actually make MCP useful, Auto Fill, is gated behind an enterprise plan. So the surface is there, but the real power is locked away.
I get that this is still the wild west for MCP, and I agree with the OP’s general take. But right now there is a big gap between "integration exists" and "integration is actually useful." Personally, I am more excited about where something like WebMCP could go, where the default assumption is full capability rather than a restricted subset.
The result is less that I want to go to Figma directly and more that I just want to skip it entirely. So, assuming the power of these aggregator agents keeps growing, the onus is on these tools to create useful integrations or get subsumed by a model capability or another tool with a better integration. It sounds like your experience is similar - you bypassed the tools with bad integrations instead of going to them directly.
It makes sense they very slowly transitioned from read-only to limited write. You have to carefully beta test. Both figuring out the guardrails and finding usecases where it actually works well. The only way to do that (properly) is a slow drip release cycle.
All SaaS-built MCP servers should cover the entirety their existing API functionality. I know it sounds like a lot but I really don't think it is an unreasonable expectation.
People who do that will do well.
This is an obvious direction that the industry is heading to. But what are the implications of this? I think the differentiating factor of having a good UI will reduce - productivity apps and SaaS will no longer have their aesthetic UI as a moat. I'm not sure whether this will tank their stocks or increase the valuation but what I'm sure of is that the productivity and usage will increase.
Figma offered the capabilities but not the data or context.
Everyone's building "the everything app". The end game is likely an entire OS shell that is AI-first.
While Figma advertises that their official MCP "can now write directly to your Figma files", in reality it is restricted to create and read (as in CRUD), but not update nor delete. Currently, there is only one option to edit/update using the Figma MCP and it requires going through a third-party service with its own subscription and tiny token allocations.
Meanwhile, several developers have figured out how to use Figma's plug-in system to work-around these limitations, for a more robust CRUD MCP solution.
I've seen a number of stories about LLMs going rogue and messing things up (dropping databases, making unwanted changes, etc). Also, apparently there are security concerns with the MCP protocol itself.