Protect secrets and limit access

The current server uses static public data. It needs no credential, filesystem access, or outgoing network request. Keep the first deployment that small.

When you add a backend, draw the access chain:

MCP caller → MCP server → notes backend

Each arrow needs its own identity and permission. The caller token is for the MCP server. The backend credential is for the notes service. Never reuse one token across both boundaries.

Store backend credentials in the platform secret manager. Give them read-only access while the server exposes only reads. Restrict database tables, object prefixes, API operations, and reachable network destinations.

Least privilege also covers time and volume:

• cap query length and result count
• add backend and request timeouts
• limit concurrent calls and request rate
• cap response bytes before returning content
• abort work when the client cancels

A read-only tool can still disclose private data or exhaust a paid backend. “No writes” is only one safety property.

Run the server once with no secrets configured. The public practice-data version should still work. Then document every new permission needed for a real backend and the failure produced when it is absent.

Review dependency and deployment configuration changes as security changes. A new library, binding, or environment variable can expand the server’s authority without adding a tool.