3 ms·

I'm struggling to think of a good entry under those sections, what did you have in mind? For accessibility, that's a client consideration typically, the agent

I'm struggling to think of a good entry under those sections, what did you have in mind? For accessibility, that's a client consideration typically, the agent using the MCP server would be responsible for making its output accessible. I don't think the intention is to let webapps define how their output is displayed to end users, but to define outputs for agents instead. For security, other than what the MCP protocol itself provides, what should be defined? I think it's a draft, there is still discussion about it, they might not have reached a point where there consensus for those categories. But I'm curious to hear your thoughts.

dfabulich 8mo ago
> For security, other than what the MCP protocol itself provides, what should be defined? The MCP protocol itself provides no security at all. The MCP specification includes no specified method of authorization, and no specified security rules. It lists a handful of "principles," and then the specification simply gives up on discussing the problem further. https://modelcontextprotocol.io/specification/2025-11-25#security-and-trust-%26-safety https://modelcontextprotocol.io/specification/2025-11-25#sec... 3.2 Implementation Guidelines While MCP itself cannot enforce these security principles at the protocol level, implementors **SHOULD**: 1. Build robust consent and authorization flows into their applications 2. Provide clear documentation of security implications 3. Implement appropriate access controls and data protections 4. Follow security best practices in their integrations 5. Consider privacy implications in their feature designs
- notepad0x90 8mo ago
  it's just an http or stdio server, would there be considerations beyond that of any other http server or cli app? shouldn't the security be dependent on deployment details? Like you wouldn't require OAUTH if it is deployed on localhost only, or if there is a reverse proxy handling that bit. There is a reason it cannot enforce those principles, an MCP is a web service. it could use SQL as a backend for some reason, or use static pages. it might be best to use mTLS, or it might make sense to make it open to the public with no authentication or authorization whatsoever, and your only concern might be availability (429 thresholds). the spec can't and shouldn't account for wildly varying implementation possibilities right?
  - davidcrowe 8mo ago
    The difference is that MCP introduces a third party: the agent isn't the user and isn't the service, but it's acting on behalf of one to call the other. Standard HTTP auth assumes two parties. That's the gap the spec needs to address.

dfabulich 8mo ago

> For security, other than what the MCP protocol itself provides, what should be defined? The MCP protocol itself provides no security at all. The MCP specification includes no specified method of authorization, and no specified security rules. It lists a handful of "principles," and then the specification simply gives up on discussing the problem further. https://modelcontextprotocol.io/specification/2025-11-25#security-and-trust-%26-safety https://modelcontextprotocol.io/specification/2025-11-25#sec... 3.2 Implementation Guidelines While MCP itself cannot enforce these security principles at the protocol level, implementors **SHOULD**: 1. Build robust consent and authorization flows into their applications 2. Provide clear documentation of security implications 3. Implement appropriate access controls and data protections 4. Follow security best practices in their integrations 5. Consider privacy implications in their feature designs

notepad0x90 8mo ago
it's just an http or stdio server, would there be considerations beyond that of any other http server or cli app? shouldn't the security be dependent on deployment details? Like you wouldn't require OAUTH if it is deployed on localhost only, or if there is a reverse proxy handling that bit. There is a reason it cannot enforce those principles, an MCP is a web service. it could use SQL as a backend for some reason, or use static pages. it might be best to use mTLS, or it might make sense to make it open to the public with no authentication or authorization whatsoever, and your only concern might be availability (429 thresholds). the spec can't and shouldn't account for wildly varying implementation possibilities right?
- davidcrowe 8mo ago
  The difference is that MCP introduces a third party: the agent isn't the user and isn't the service, but it's acting on behalf of one to call the other. Standard HTTP auth assumes two parties. That's the gap the spec needs to address.