Post

... i mean if we're gonna do all that why not just do json apis? like i respect what codemode is going for but throwing away the 'you get to choose the tool response for the agent' part seems suboptimal

like ok theres a lot of bad mcps. bigger context windows mean people dont have to care about response size as much. but it still matters! if you can get a tool response down to under 10k tokens that's still helpful and makes the tools broadly useful

controlled, understandable composability is the one that I found in my experiments with a code mode. the agent can do stuff with the results and intermediate states in a way that is far more readable and manageable in terms of effect scope than the average chain of shell commands.

"make and use better mcps" is a solution to one part of that problem, but it doesn't solve "the officially blessed mcp for X sucks" nor does it solve taking the output from one, doing something with it, then feeding it to another thing, conditionally, without needing a model call, in a readable way.

i agree w/yr earlier point about composing structured output. the spec really needs a first-class way to expose structured stuff (the current output schema isn’t super helpful because it still yeets it all back into context)

mmhm. and mcp often pushes towards lots of little tools that each do one operation, which means they need composition.

from my talk later this month about the mcp at honeycomb; the first big thing we did was decompose api calls into capabilities that mapped to existing logical features for ppl and exposed those to mcp

yeah you all do fairly well on this. the problem i usually run into is either the operations are too small, or the author's workflow opinions mean you simply can't do the thing in question if they don't also expose the stupid granular ops.

or the constraints on some input are not made obvious to the agent even in error output, much less in advance, it must discover them by making another call, which is not necessarily obvious unless mentioned, and in at least one case the mcp actually seemingly had no way to find that info

In any open ecosystem where good design takes effort (and will therefore not be consistent) features that compensate for BAD design are incredibly important.

1 repost4 likes

yep. especially when you might not actually be able to choose your mcp for a service or rewrite it if it sucks. and you can't anticipate every workflow, even if you do design things well, so it's good for people/robots to be able to make their own without reinventing the whole thing.