Document MCP server and tool trust boundaries

### Summary

Consider adding documentation that helps users understand the trust boundaries around MCP servers, their tools, and the host applications or LLM harnesses that invoke them.

### Motivation

Recent security analysis involving Azure MCP Server’s Azure Storage tools highlighted the value of clarifying what protections users should expect from an MCP deployment. Input validation can help ensure correctness and provide defense-in-depth, but it may not address scenarios where the host environment, network, MCP client/LLM harness, or model has already been compromised.

The documentation could help distinguish between:

- The MCP server, which implements the protocol and is commonly run in a local host context;
- The tools exposed by the server;
- The MCP host/client or LLM harness that advertises and invokes those tools.

### Suggested topics

The documentation might consider explaining that:

- MCP servers and tools are commonly operated within the trust boundary of their host environment.
- Tool validation is generally intended to support correct operation and may not constitute a comprehensive security boundary.
- Tool results may include information available to the host identity or environment.
- Additional validation or restrictions for destructive tools can be useful defense-in-depth, but may not replace broader authorization and isolation controls.
- Applications that choose to expose an MCP server beyond its local context—such as through a reverse proxy—may need to provide appropriate authentication, authorization, network restrictions, and least-privilege configuration.
- The MCP server itself should not necessarily be treated as a multi-tenant authorization or isolation layer.

The [AKS-MCP security considerations](https://github.com/Azure/aks-mcp#supported-deployment-model-and-security-considerations) may provide a useful example of how to describe supported deployment models, trust assumptions, and responsibilities when an application is deployed remotely.