It's like people hate it so much they forget how easy it is to spin one of these up; it's not like I spent weeks and weeks working on this.
I spun up an MCP server for a personal finance app I've been working on. OAuth with personal tokens and all the tools I added- guess how long it took me? Like 2 hours maybe. Some people find it useful, including me, and some don't. That's okay!
Add in the context that they're also building their own inference provider[1], and there's certainly a non-zero risk that the project trends away from the barebones platform to build on that people signed up for.
criteria: {
none: "Neutral, factual, or friendly, even about a serious bug",
mild: "Explicit annoyance, impatience, or disappointment",
high: "Clearly angry, exasperated, sarcastic, or fed up",
},Doesn't have to be used for prioritization purposes. Obviously a little annoyance is to be expected at times, but you could explicitly ban egregious angry behavior in your project.
So, exactly like OpenAPI?
a subagent per mcp toolset, basically sub agent per saas in the configuration at $WORK
I don't have any hard evals on this but it feels like it works more than it doesn't, especially now that subagent use has gotten better in general, but you do feel drawbacks if you ever need to do something that involves coordinating multiple sub agents, there's some communication overhead that wouldn't be there if it was just one agent with all the tools to do the whole job
Treating MCP as a part of OpenAPI rather than a tool connector is a direction in which we're heading. It is important for the users to have the flexibility of deciding the model, work to be done and the tool call in one prompt. The framework sets up the configuration and gets the output.