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.
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#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 designsThere 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?