Whatever you do do not simply put 1 to 1 rest apis to mcp tools. Really think about common workflows users want and make good abstractions for good chunks of work.
I still dont fully understand the point of MCP servers. What do they provide that a skill doesnt? Maybe I've just used too many poorly written ones.
Is there some sort of tool that can be expressed as an MCP and but not as an API or CLI command? Obviously we shouldnt map existing apis to MCP tools, but why would I used an MCP over just writing a new "agentic ready" api route?
> Is there some sort of tool that can be expressed as an MCP and but not as an API or CLI command?
... most standard desktop software? How do you interact with Blender, Unity3D, Ableton Live, Photoshop, DaVinci Resolve, ... when they don't provide any API or programmatic CLI and don't want to open random network ports but will be absolutely fine with opening a tightly controlled local channel through a fd / pipe like MCP uses ?
Well it sure took "FastMCP" long enough. And the announcement lands at a time when its looking increasingly like CLI is the preferred method vs MCP. I'm sure in a few months time, even that will be out of date
Have FastMCP become the standard sdk? The docs is great, honestly way better than the official website modelcontextprotocol which most if its pages is ”under construction”.
MCP earns its keep in specific cases: when the agent has no shell access, when you need to keep credentials out of the prompt context, or when you want runtime tool discovery across teams. But I've built a few MCP servers and half of them would've been simpler as a CLI script the agent calls directly.
I built https://github.com/rcarmo/umcp to be tiny _and_ fast, but this has some nice twists on the theme. Will investigate for sure (even if it seems like a much larger dependency).
FastMCP author here, surprised and excited to see this hit the front page! Certainly not an announcement, we’ve been around since the beginning, but we will be launching full generative apps support shortly so stay tuned.
FastMCP is great and this post is overdue. What did FastMCP solve? Lots of code reduction, reduced complexity and the ability to streamline auth. Offloading the auth was a huge benefit. With FastMCP I could replace all my custom JWT validation and get an auth workflow with fewer steps.
This is a perfect example of why supply chain is becomaing an agent problem or an agent governance problem. It's no longer just devops. We, humans, will notice things are off a bit maybe during an install or upgrade. Agents can't. They'll just intall whatever and then keep going, often with credentials loaded and tools enabled.
So what I've found to be useful or even critical is treating dependency changes as "authority changes." What I mean is upgrades and new transititive deps shouldn't be in the same permissions bucket as "normal" execution. You want to isolate the install/update into a separate job or identity with no access to production secrets. Secondly require an explicit allowlist or signed artifact for packages in the execution enviornemnt. Third, log who/hwat authorized this new code to run as a first-class audit event.
If agents are going to operate as we are tyring them to (unattended) then the question isn't only was the package malicious but it's also why was any unattended actor allowed to do what it did. Isn't this within our best interest?
15 comments
[ 9.5 ms ] story [ 146 ms ] threadIn an era where technology exists that can lend the appearance of legitimacy to just about anyone, that kind of statement needs to be qualified.
Is there some sort of tool that can be expressed as an MCP and but not as an API or CLI command? Obviously we shouldnt map existing apis to MCP tools, but why would I used an MCP over just writing a new "agentic ready" api route?
Why? Isn't obvious to me..
... most standard desktop software? How do you interact with Blender, Unity3D, Ableton Live, Photoshop, DaVinci Resolve, ... when they don't provide any API or programmatic CLI and don't want to open random network ports but will be absolutely fine with opening a tightly controlled local channel through a fd / pipe like MCP uses ?
So what I've found to be useful or even critical is treating dependency changes as "authority changes." What I mean is upgrades and new transititive deps shouldn't be in the same permissions bucket as "normal" execution. You want to isolate the install/update into a separate job or identity with no access to production secrets. Secondly require an explicit allowlist or signed artifact for packages in the execution enviornemnt. Third, log who/hwat authorized this new code to run as a first-class audit event.
If agents are going to operate as we are tyring them to (unattended) then the question isn't only was the package malicious but it's also why was any unattended actor allowed to do what it did. Isn't this within our best interest?