MCP protocol layer is for all practical purposes an irrelevant implementation detail.
We need some new layer to handle things that used to be abstracted away by UIs
- filter to 6 of 50 fields for the paginated pipeline views
- show all the important fields on a detail view
- organize for understanding of fields that might have been poorly named in the public APIs
Some of this can be handled by a CLI wrapper around an API, but it really just shifts the complexity into a different system.
One thing that I haven't heard a lot of people talk about is that MCPs are often able to be far more flexible than a traditional REST api. You can ship breaking changes/renames and agents will adapt. Why should we couple the agent tooling locked 1-1 with our calcified systems?
We need some new layer to handle things that used to be abstracted away by UIs
- filter to 6 of 50 fields for the paginated pipeline views
- show all the important fields on a detail view
- organize for understanding of fields that might have been poorly named in the public APIs
Some of this can be handled by a CLI wrapper around an API, but it really just shifts the complexity into a different system.
One thing that I haven't heard a lot of people talk about is that MCPs are often able to be far more flexible than a traditional REST api. You can ship breaking changes/renames and agents will adapt. Why should we couple the agent tooling locked 1-1 with our calcified systems?