I have been playing around with MCP, and one of its current shortcomings is that it didn’t support OAuth. This means that credentials need to be hardcoded somewhere. Right now, it appears that a lot of MCP servers are run locally, but there is no reason they couldn’t be run as a service in the future.
There is a draft specification for OAuth in MCP, and hopefully this is supported soon.
socrateslee 22 hours ago [-]
For the OAuth part, the access_token is all an MCP server needs. So users could do an OAuth Authorization like in the settings or by the chatbot, and let MCP servers handle the storage of the access_token.
For remote MCP servers, storing access_token is a very common practice. For MCP servers hosted locally, how to deal with a bunch of secret keys is a problem.
You could use Nango for the OAuth flow and then pass the user’s token to the MCP server: https://nango.dev/auth
Free for OAuth with 400+ APIs & can be self-hosted
(I am one of the founders)
knowaveragejoe 23 hours ago [-]
There are remotely run MCP server options out there, such as mcp.run and glama.ai
johnjungles 1 days ago [-]
This is pretty cool!
I too am working on effortless mcp servers for other developers using cursor and windsurf - there’s so much out there on mcp but turns out a lot of mcp servers don’t “just work”. A lot of other people have been porting APIs but actually you need to put a lot more thought into it because people don’t memorize uuids that are required to make api calls. Memory is a good approach, but afraid of the recall aspect and how that could potentially cause tool calls with bad inputs.
I built https://skeet.build where anyone can try out mcp for cursor and windsurf - we approached it with just brute force thoughtful design and a lot of trial and error.
We did this because of a painpoint I experienced as an engineer having to deal with Jira and Linear - updating slack and all that friction. I noticed I copy and paste a lot to cursor and so spent time building this app.
Mostly for workflows that I like:
* start a PR with a summary of what I just did
* slack or comment to linear/Jira with a summary of what I pushed
* pull this issue from sentry and fix it
* Find a bug a create a linear issue to fix it
* pull this linear issue and do a first pass
* pull in this Notion doc with a PRD then create an API reference for it based on this code
* Postgres or MySQL schemas for rapid model development
Everyone seems to go for the hype but ease of use, practical pragmatic developer workflows, and high quality polished mcp servers are what we’re focused on
Lmk what you think!
pdf2calguy 1 days ago [-]
sweet product
max_on_hn 22 hours ago [-]
[dead]
fudged71 22 hours ago [-]
Very cool.
How does it work when multiple installed MCP servers have overlapping functionality? Are MCPs going to have competing prompts saying for example they’re the best to choose for OCR etc?
jasonjmcghee 20 hours ago [-]
Yes absolutely. And if you install an mcp server with a poorly written prompt, your sota llm might try to use it for everything. Prompt injection attacks will also be a thing. Depending on how this all plays out, we're in for interesting times.
The number of threads of people asking how to permanently accept all tool use so they don't have to accept them manually...
lifty 19 hours ago [-]
Still waiting for someone to implement and MCP to LSP bridge.
There is a draft specification for OAuth in MCP, and hopefully this is supported soon.
For remote MCP servers, storing access_token is a very common practice. For MCP servers hosted locally, how to deal with a bunch of secret keys is a problem.
For hosted MCPs: https://supermachine.ai
Free for OAuth with 400+ APIs & can be self-hosted
(I am one of the founders)
I too am working on effortless mcp servers for other developers using cursor and windsurf - there’s so much out there on mcp but turns out a lot of mcp servers don’t “just work”. A lot of other people have been porting APIs but actually you need to put a lot more thought into it because people don’t memorize uuids that are required to make api calls. Memory is a good approach, but afraid of the recall aspect and how that could potentially cause tool calls with bad inputs.
I built https://skeet.build where anyone can try out mcp for cursor and windsurf - we approached it with just brute force thoughtful design and a lot of trial and error.
We did this because of a painpoint I experienced as an engineer having to deal with Jira and Linear - updating slack and all that friction. I noticed I copy and paste a lot to cursor and so spent time building this app.
Mostly for workflows that I like:
* start a PR with a summary of what I just did * slack or comment to linear/Jira with a summary of what I pushed * pull this issue from sentry and fix it * Find a bug a create a linear issue to fix it * pull this linear issue and do a first pass * pull in this Notion doc with a PRD then create an API reference for it based on this code * Postgres or MySQL schemas for rapid model development
Everyone seems to go for the hype but ease of use, practical pragmatic developer workflows, and high quality polished mcp servers are what we’re focused on
Lmk what you think!
How does it work when multiple installed MCP servers have overlapping functionality? Are MCPs going to have competing prompts saying for example they’re the best to choose for OCR etc?
The number of threads of people asking how to permanently accept all tool use so they don't have to accept them manually...