Choose the transport deliberately
A local stdio server and a remote HTTP service have different deployment needs. Use a supported remote transport, TLS and an authenticated route. Check the client and server versions rather than assuming every implementation supports the same capabilities.
Treat every tool as an API
Validate arguments, enforce user-specific authorisation and limit resources. Do not expose arbitrary shell execution as a convenience tool. Restrict outbound destinations where a tool fetches URLs and keep secrets out of descriptions and responses.
Keep identity collection proportionate
A no-KYC host can minimise provider signup data, but the MCP service may still need its own users, session security and abuse controls. Explain what it logs and avoid retaining tool inputs without a defined purpose.
Deploy for operational clarity
Run under a dedicated user, use health checks, bound request times and keep the reverse proxy’s buffering and timeouts compatible with the protocol. Test authentication, revocation, disconnects and retries before granting write privileges.
Align authentication with the supported protocol
For an HTTP-based MCP deployment, review the protocol’s current authorisation requirements and the client’s supported version. OAuth-based resource access involves token audience, discovery and scope, not simply a password on the homepage. Use HTTPS, validate tokens for the intended resource and keep bearer credentials out of query strings. A stdio server uses a different local credential boundary.
- Test an unauthenticated request
- Test an authenticated request outside its scope
- Revoke a credential and verify it stops working
Official documentation: MCP authorisation specification
Publish a limited first toolset
Start with read-only tools that return a bounded amount of data. Add file writes, server lifecycle operations or external messages only after their permissions and duplicate behaviour are understood. Treat returned web pages and documents as untrusted input; they must not silently expand the tool server’s authority.
Pin the protocol behaviour before writing proxy rules
Record both the server SDK release and the MCP revision that the client will use. In the 2026-07-28 Streamable HTTP revision, requests use a POST endpoint; older examples relying on protocol sessions or a standalone GET stream are a different revision. Do not remove an apparent compatibility requirement until you know which client you support. A reverse proxy must preserve the required headers, HTTP status and response streaming behaviour for that version.
- Start with a read-only tool on a loopback listener, then place the intended HTTPS/authentication boundary in front of it.
- Test a normal result, a streaming result, a timeout and a disconnected client through the public proxy.
- Validate allowed Origin values as required by the transport; an Origin check is not a substitute for authenticating the caller.
- If events arrive only at the end, inspect proxy buffering and timeout behaviour before changing tool code.
Official documentation: MCP 2026-07-28: Streamable HTTP
Test authorization failures as deliberately as success
For OAuth-protected HTTP access, the MCP server is a protected resource. Test metadata discovery, the expected issuer and token audience, and the scopes needed for a particular operation. Keep the authorization token out of URL query strings and never forward it unchanged to an unrelated downstream service. A client-facing authentication failure must preserve the appropriate HTTP challenge so the client can recover through its supported flow.
- No token or an expired token: the protected endpoint rejects access rather than returning private tool data.
- Valid token with insufficient permission: the requested resource remains inaccessible.
- Token for another audience: reject it even if its signature is otherwise valid.
- Unexpected external URL or file path: validate against the tool’s authority before fetching or writing.
- Logs and error traces: retain an operation identifier and outcome while removing tokens and private tool inputs.
Official documentation: MCP 2026-07-28: HTTP authorization · MCP: security best practices