7 ms·

Welcome to FastMCP

80 points by Anon84 7mo ago

whattheheckheck 7mo ago
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.
_verandaguy 7mo ago
> FastMCP is the standard framework for building MCP applications Standardized by whom? In an era where technology exists that can lend the appearance of legitimacy to just about anyone, that kind of statement needs to be qualified.
- simonw 7mo ago
  Yeah, calling itself "the standard framework" doesn't feel right to me, https://github.com/modelcontextprotocol https://github.com/modelcontextprotocol is the home of the actual standard and has a bunch of libraries for this, of which FastMCP is not one. UPDATE: I was wrong about this, see comment reply. The python-sdk in https://github.com/modelcontextprotocol https://github.com/modelcontextprotocol is a fork of FastMCP.
  - m11a 7mo ago
    If I recall correctly, the ‘official’ Python one is a fork of FastMCP v1 (which then removed the attribution, arguably in violation of the original software’s license)
    - simonw 7mo ago
      I stand corrected! https://github.com/modelcontextprotocol/python-sdk/blob/7ba4fb881d85406f44a5af8169fb7200fa7c8e49/docs/migration.md#fastmcp-renamed-to-mcpserver https://github.com/modelcontextprotocol/python-sdk/blob/7ba4...
      - Merik 7mo ago
        There is a whole history with this, and i think its not appropriate or fair to malign the mcp python-sdk. My read of what happened is that the author spiked an an initial the implementation of 'fastmcp' on Nov 30 2025, 5 days later, the author relicensed it to MIT, and donated it to the python sdk (10 days after anthropic announced MCP): https://github.com/PrefectHQ/fastmcp/pull/54 https://github.com/PrefectHQ/fastmcp/pull/54 It was incorporated on Dec 21 2024, and hardened through the efforts of one of the python-sdk maintainers. The author seemingly abandoned the github project shortly after donating it to the python-sdk and marked it as unmaintained, and it remained so for several months (there are roughly zero commits between jan-april): https://github.com/PrefectHQ/fastmcp/issues/96 https://github.com/PrefectHQ/fastmcp/issues/96 He also apparently has made almost no other contributions to the mcp python-sdk: https://github.com/modelcontextprotocol/python-sdk/commits?author=jlowin https://github.com/modelcontextprotocol/python-sdk/commits?a... Many contributors to the python sdk continued to iterate on the mcp server implementation using the name fastmcp ( since it had been donated to the project ) resulting in growing interest: https://trends.google.com/explore?q=fastmcp%20&date=2024-12-05%202025-04-30&geo=Worldwide https://trends.google.com/explore?q=fastmcp%20&date=2024-12-... Then around April 2025, the author likely noticing the growing interest and stickyness of the name, decided to write a new version and start using the name fastmcp again. https://github.com/PrefectHQ/fastmcp/graphs/contributors?from=18%2F11%2F2024&to=10%2F04%2F2025 https://github.com/PrefectHQ/fastmcp/graphs/contributors?fro... The author clearly made an attempt to promote his effort: https://www.reddit.com/r/mcp/comments/1np6dwg/fastmcp_20_is_changing_how_we_build_ai/ https://www.reddit.com/r/mcp/comments/1np6dwg/fastmcp_20_is_... This resulted in a lot of confusion by users, which persists to this day. I only looked into this last year, because i was one of those users who was suddenly confused regarding the provenance of what i was actually using vs what i thought i was using; and as i looked into it i was suddenly seeing lots of questionable reddit comments pop up in subreddits i was reading, all evangelizing fastmcp 2.0 and using language that was contributing to the confusion. The author's interest in monetizing the fastmcp github repo is understandable, and he and others have clearly put alot of effort into iterating in his SaaS onramp, but the confusion arises simply because the author wanted to capitalize on the success of mcp and on the popularity of the fastmcp name, the initial growth and popularity of which was primarily driven by the effort and support of contributors to the mcp python sdk .
- Alifatisk 7mo ago
  The official website modelcontextprotocol refers to FastMCP in their examples https://modelcontextprotocol.io/docs/develop/build-server https://modelcontextprotocol.io/docs/develop/build-server
zlurker 7mo ago
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?
- paulddraper 7mo ago
  Authentication for one.
- simonw 7mo ago
  I know of two benefits to MCP over Skills: - If your agent doesn't have a full Bash-style code execution environment it can't run skills. MCP is a solid option for wiring in tools there. - MCP can help solve authentication, keeping credentials for things in a place where the agent can't steal those credentials if it gets compromised. MCPs can also better handle access control and audit logging in a single place.
  - staticassertion 7mo ago
    Can you explain the auth part? I feel like auth for an agent is largely a matter of either verifying its context or issuing it a JWT that's scoped to its rights, which I assume is quite similar to how any tools would work. But I'm very unfamiliar with MCP.
    - monkpit 7mo ago
      I think they’re saying you could start up the mcp and pass it creds/auth for some downstream service, and then the LLM uses the tool and has auth but doesn’t know the creds.
      - simonw 7mo ago
        Right. If you're running a CLI tool that is authenticated there's effectively no way to prevent the coding agent from accessing those credentials itself - they're visible to the process, which means they're visible to the agent. With MCP you can at least set things up such that the agent can't access the raw credentials directly.
cboyardee 7mo ago
[dead]
notoreous 7mo ago
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
- speedgoose 7mo ago
  MCP is superior to CLI by design, and it’s not even close. I don’t understand the sudden hype towards CLI for agents.
  - zingar 7mo ago
    Would you mind elaborating on the superiority you perceive?
    - speedgoose 7mo ago
      It has a json schema, that’s the main point. It also enforces good documentation by design. No need to get a man page or run the help command, it’s in the context. It can work remotely with authentication.
      - ramon156 7mo ago
        Most CLI tools have JSON support. Your arguments fall flat pretty short. I think MCP is fine in an env where you have no access to tools, but you cannot ripgrep your way through an MCP (unless you make an MCP that calls ripgrep on e.g. a repo, which in that case what are you doing).
        vova_hn2 7mo ago
        Tool calls can have JSON schema enforced on lower level (token sampling). Although, I'm not sure if major providers do it, but I don't see any reason why they wouldn't.
        speedgoose 7mo ago
Alifatisk 7mo ago
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”.
arthurjean 7mo ago
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.
- cadamsdotcom 7mo ago
  Why wouldn’t you just give the agent a shell (and by implication a sandbox)? Seems like unnecessarily constraining it.
  - arthurjean 7mo ago
    Most of the time you should. But it depends on what you're wrapping. Exa is a good example of where MCP makes sense, it's not just one API call, it's 4 different tools (web search, code search, crawling, advanced search) plus embedded skills for chaining them. One MCP connection and the agent discovers all of that at runtime. Doing that with a CLI means building a multi-command script and hoping the agent figures out the orchestration. On the other hand, something like context7 is just `npx ctx7 resolve <lib>` then `npx ctx7 docs <id>` — two stateless shell calls, done. No server to maintain, no protocol overhead. CLI is the right tool there.
    - TimTheTinker 7mo ago
      Why not put all of that into a skill file? The context overhead from an MCP connection is significantly higher.
      - arthurjean 7mo ago
        You're right actually. Exa's MCP server is stateless, just a REST wrapper. A skill + CLI would do the same job with way less context cost. Someone already built that (https://github.com/tobalsan/exa https://github.com/tobalsan/exa).
- TimTheTinker 7mo ago
rcarmo 7mo ago
I built https://github.com/rcarmo/umcp 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).
jlowin 7mo ago
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.
iblaine 7mo ago
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.
agentictrustkit 7mo ago
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?

80 points by Anon84 7mo ago

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.

_verandaguy 7mo ago

> FastMCP is the standard framework for building MCP applications Standardized by whom? In an era where technology exists that can lend the appearance of legitimacy to just about anyone, that kind of statement needs to be qualified.

simonw 7mo ago
Yeah, calling itself "the standard framework" doesn't feel right to me, https://github.com/modelcontextprotocol https://github.com/modelcontextprotocol is the home of the actual standard and has a bunch of libraries for this, of which FastMCP is not one. UPDATE: I was wrong about this, see comment reply. The python-sdk in https://github.com/modelcontextprotocol https://github.com/modelcontextprotocol is a fork of FastMCP.
- m11a 7mo ago
  If I recall correctly, the ‘official’ Python one is a fork of FastMCP v1 (which then removed the attribution, arguably in violation of the original software’s license)
  - simonw 7mo ago
    I stand corrected! https://github.com/modelcontextprotocol/python-sdk/blob/7ba4fb881d85406f44a5af8169fb7200fa7c8e49/docs/migration.md#fastmcp-renamed-to-mcpserver https://github.com/modelcontextprotocol/python-sdk/blob/7ba4...
    - Merik 7mo ago
      There is a whole history with this, and i think its not appropriate or fair to malign the mcp python-sdk. My read of what happened is that the author spiked an an initial the implementation of 'fastmcp' on Nov 30 2025, 5 days later, the author relicensed it to MIT, and donated it to the python sdk (10 days after anthropic announced MCP): https://github.com/PrefectHQ/fastmcp/pull/54 https://github.com/PrefectHQ/fastmcp/pull/54 It was incorporated on Dec 21 2024, and hardened through the efforts of one of the python-sdk maintainers. The author seemingly abandoned the github project shortly after donating it to the python-sdk and marked it as unmaintained, and it remained so for several months (there are roughly zero commits between jan-april): https://github.com/PrefectHQ/fastmcp/issues/96 https://github.com/PrefectHQ/fastmcp/issues/96 He also apparently has made almost no other contributions to the mcp python-sdk: https://github.com/modelcontextprotocol/python-sdk/commits?author=jlowin https://github.com/modelcontextprotocol/python-sdk/commits?a... Many contributors to the python sdk continued to iterate on the mcp server implementation using the name fastmcp ( since it had been donated to the project ) resulting in growing interest: https://trends.google.com/explore?q=fastmcp%20&date=2024-12-05%202025-04-30&geo=Worldwide https://trends.google.com/explore?q=fastmcp%20&date=2024-12-... Then around April 2025, the author likely noticing the growing interest and stickyness of the name, decided to write a new version and start using the name fastmcp again. https://github.com/PrefectHQ/fastmcp/graphs/contributors?from=18%2F11%2F2024&to=10%2F04%2F2025 https://github.com/PrefectHQ/fastmcp/graphs/contributors?fro... The author clearly made an attempt to promote his effort: https://www.reddit.com/r/mcp/comments/1np6dwg/fastmcp_20_is_changing_how_we_build_ai/ https://www.reddit.com/r/mcp/comments/1np6dwg/fastmcp_20_is_... This resulted in a lot of confusion by users, which persists to this day. I only looked into this last year, because i was one of those users who was suddenly confused regarding the provenance of what i was actually using vs what i thought i was using; and as i looked into it i was suddenly seeing lots of questionable reddit comments pop up in subreddits i was reading, all evangelizing fastmcp 2.0 and using language that was contributing to the confusion. The author's interest in monetizing the fastmcp github repo is understandable, and he and others have clearly put alot of effort into iterating in his SaaS onramp, but the confusion arises simply because the author wanted to capitalize on the success of mcp and on the popularity of the fastmcp name, the initial growth and popularity of which was primarily driven by the effort and support of contributors to the mcp python sdk .
Alifatisk 7mo ago
The official website modelcontextprotocol refers to FastMCP in their examples https://modelcontextprotocol.io/docs/develop/build-server https://modelcontextprotocol.io/docs/develop/build-server

zlurker 7mo ago

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?

paulddraper 7mo ago
Authentication for one.
simonw 7mo ago
I know of two benefits to MCP over Skills: - If your agent doesn't have a full Bash-style code execution environment it can't run skills. MCP is a solid option for wiring in tools there. - MCP can help solve authentication, keeping credentials for things in a place where the agent can't steal those credentials if it gets compromised. MCPs can also better handle access control and audit logging in a single place.
- staticassertion 7mo ago
  Can you explain the auth part? I feel like auth for an agent is largely a matter of either verifying its context or issuing it a JWT that's scoped to its rights, which I assume is quite similar to how any tools would work. But I'm very unfamiliar with MCP.
  - monkpit 7mo ago
    I think they’re saying you could start up the mcp and pass it creds/auth for some downstream service, and then the LLM uses the tool and has auth but doesn’t know the creds.
    - simonw 7mo ago
      Right. If you're running a CLI tool that is authenticated there's effectively no way to prevent the coding agent from accessing those credentials itself - they're visible to the process, which means they're visible to the agent. With MCP you can at least set things up such that the agent can't access the raw credentials directly.

cboyardee 7mo ago

[dead]

notoreous 7mo ago

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

speedgoose 7mo ago
MCP is superior to CLI by design, and it’s not even close. I don’t understand the sudden hype towards CLI for agents.
- zingar 7mo ago
  Would you mind elaborating on the superiority you perceive?
  - speedgoose 7mo ago
    It has a json schema, that’s the main point. It also enforces good documentation by design. No need to get a man page or run the help command, it’s in the context. It can work remotely with authentication.
    - ramon156 7mo ago
      Most CLI tools have JSON support. Your arguments fall flat pretty short. I think MCP is fine in an env where you have no access to tools, but you cannot ripgrep your way through an MCP (unless you make an MCP that calls ripgrep on e.g. a repo, which in that case what are you doing).
      - vova_hn2 7mo ago
        Tool calls can have JSON schema enforced on lower level (token sampling). Although, I'm not sure if major providers do it, but I don't see any reason why they wouldn't.
      - speedgoose 7mo ago

Alifatisk 7mo ago

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”.

arthurjean 7mo ago

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.

cadamsdotcom 7mo ago
Why wouldn’t you just give the agent a shell (and by implication a sandbox)? Seems like unnecessarily constraining it.
- arthurjean 7mo ago
  Most of the time you should. But it depends on what you're wrapping. Exa is a good example of where MCP makes sense, it's not just one API call, it's 4 different tools (web search, code search, crawling, advanced search) plus embedded skills for chaining them. One MCP connection and the agent discovers all of that at runtime. Doing that with a CLI means building a multi-command script and hoping the agent figures out the orchestration. On the other hand, something like context7 is just `npx ctx7 resolve <lib>` then `npx ctx7 docs <id>` — two stateless shell calls, done. No server to maintain, no protocol overhead. CLI is the right tool there.
  - TimTheTinker 7mo ago
    Why not put all of that into a skill file? The context overhead from an MCP connection is significantly higher.
    - arthurjean 7mo ago
      You're right actually. Exa's MCP server is stateless, just a REST wrapper. A skill + CLI would do the same job with way less context cost. Someone already built that (https://github.com/tobalsan/exa https://github.com/tobalsan/exa).
TimTheTinker 7mo ago

rcarmo 7mo ago

I built https://github.com/rcarmo/umcp 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).

jlowin 7mo ago

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.

iblaine 7mo ago

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.

agentictrustkit 7mo ago

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?