Better way to standardize?

[umangty]

Is your feature request related to a problem? Please describe.
Is there a better way to standardise the actions on top of resources?
Since most of the use-cases popping up are just wrappers on top of already written servers and product APIs like Jira, G etc, can the authors of servers mark in their open api spec that a mcp server needs to be created - example /api/ticket?id=1223 needs to be exposed to MCP. It feels like we are writing separate client libraries for already written libraries because we can't expose all of the resources to LLMs.
That being said, I understand that MCP goes beyond REST APIs and can work with literally anything. But the amount to duplication it leads to is bad - almost like building proxies. Actions on resources are already standardised by well defined protocols.

Describe the solution you'd like
More closer integration for REST and REST-like APIs. If tools work with standard OAS, adding some custom field like mcpCompatible: true/false and having a cli-generator for MCP servers would be great. Same for RPCs, WSS, SSE or AsyncAPI.

Describe alternatives you've considered
Building clickup mcp, custom s3+PG mcp according to documentation.

Additional context
NA

[umangty]

Kudos to the creator here - https://github.com/ivo-toby/mcp-openapi-server

[alioshr]

@umangty I am going beyond that in my personal little memory bank mcp server. I am implementing a memory bank with clean architecture and will treat mcp as an adapter, while maintaining http protocols on the presentation layer. As I am already seeing competition (Open AI, etc) starting to "invent" their own stuff to connect agents I expect to see other protocols or even the wish to call a server as a normal REST api.

MCP is just a protocol, like http. So we should be able to opt in, or out of it as desired.

protocol: MCP / HTTP / Whatever new stuff that can appear
server adaptar: Still thinking and not a requirement, but should be able to adapt between providers as well in the future (express, etc). Not sure on how to categorize this though. But it should also be an env variable.

This kind of adaption could be implemented in an isolated way from the architecture itself, but in my personal opinion it only really shines in clean architecture =)

[olaservo]

Hi @umangty , if you'd like to continue a discussion around this, please open a Discussion instead: https://github.com/orgs/modelcontextprotocol/discussions Thanks.