Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New MCP Roadmap

blog.modelcontextprotocol.io

Post reply on HN
Print view View original

181–189 of 189 posts

Re: New MCP Roadmap

#181

Post by chrisweekly »

DarmokTanagra wrote: post #170
chrisweekly wrote: post #31

Earlier quoted context omitted.

> "only use things that have been around for at least three years" Yikes. I can understand the desire to mitigate churn, but following this advice would be career suicide. Trying new things is essential.

Trying is not the same thing as advocating for and implementing products features using unproven tech. Ive been in this industry nearly 40 years and I have seen many many people push new tech and later fail to deliver and suffer the consequences. Experiment where it doesnt matter, everywhere else boring and old is a virtue.

I hear you. "Choose boring tech" is a reasonable default stance. IMHO, designing resilient systems in anticipation of change, and finding ways to incorporate the best of what's new, is the nature of the game and what helps keep it fun after all these years (closer to 30 vs your 40, but I'm no spring chicken).

Re: New MCP Roadmap

#182

Post by chrisweekly »

techpression wrote: post #40
chrisweekly wrote: post #31

Earlier quoted context omitted.

> "only use things that have been around for at least three years" Yikes. I can understand the desire to mitigate churn, but following this advice would be career suicide. Trying new things is essential.

Three years is nothing, what kind of work do you do where you need something released in the last three years? And I’m not OP, but I would assume the senior developers made a distinction between try and use.

What models do you use in your work?

Re: New MCP Roadmap

#183

Post by chrisweekly »

Bjartr wrote: post #39
chrisweekly wrote: post #31

Earlier quoted context omitted.

> "only use things that have been around for at least three years" Yikes. I can understand the desire to mitigate churn, but following this advice would be career suicide. Trying new things is essential.

Keeping up with changes is valuable. At the same time, it's often smart to avoid putting things into production that haven't matured or demonstrated staying power. Or, to badly mangle Postel's law: Be liberal in what you learn, and conservative in what you deploy

Sure. No real disagreement here. (See also my replies to peer comments here.)

Re: New MCP Roadmap

#184

Post by willio58 »

nozzlegear wrote: post #97
rolisz wrote: post #77

Earlier quoted context omitted.

With authentication and on mobile? I agree that on desktop it's not particularly relevant. Or through openclaw. But for most people who use it through mobile, MCP solves some problems.

> With authentication and on mobile? It's been a long time since I've used Claude, but is it not able to just use curl and an API key that it keeps in its "memory" on mobile? Or can it only use curl on the desktop?

I honestly don’t know if Claud can curl on mobile. I also haven’t had it try and store auth keys in memory.

Setting up an MCP connector took like 10 minutes for me, and it provides a nice little ui in Claude/chatgpt to make it easier for non-technical users to set up. I think of MCPs as a layer over APIs that makes things easier to interact with, similar to a frontend of a site.

Theoretically, no site needs a frontend. Yet they all do.

Re: New MCP Roadmap

#187

Post by entity002 »

simianwords wrote: post #87

Is there a way in MCP where I can "approve" certain privileged actions? Like imagine an MCP for buying stuff in Amazon but it can do everything including payment but is behind a gate that the human needs to approve

[flagged]

Re: New MCP Roadmap

#189

Post by v0idw4lker »

sofixa wrote: post #167
zackify wrote: post #43

Earlier quoted context omitted.

I think the spec overcomplicates everything honestly. Its not that hard to add a long running auth token and put it in the MCP config as a header to send along and then avoid all the extra special rules. "Oh no it's a long lived token that's bad" Put it in a secret manager like 1pw cli and now start an agent...

> "Oh no it's a long lived token that's bad" > Put it in a secret manager like 1pw cli and now start an agent... And when the agent does something stupid, your long lived token is compromised. It also makes it hard to segregate access (e.g. all those "Cursor deleted by production DB and all its backups because it had an API key that could do that"). Nope, you should instead use something that give short-lived tokens,…

[flagged]
Post reply on HN