Core principle
A model may request a tool call, but trusted backend code must decide whether it can run.
MCP gives clients a standard way to discover and call tools. It does not automatically make those tools safe. Security depends on the server-side implementation that checks identity, publication state, source ownership, arguments, limits, redaction, and execution policy before touching the upstream system.
The safest mental model is simple: prompts and tool descriptions guide the model; Gateway validation enforces the rules.
Production release checklist
Before exposing tools to AI clients, confirm that execution is governed outside the model.
| Area | Question to answer before release |
|---|---|
| Tool catalog | Are only the tools required for the workflow published? |
| Descriptions | Does each description say when to use the tool, what inputs matter, and what result comes back? |
| Credentials | Are upstream API keys and database connection strings kept server-side? |
| Authorization | Can the Gateway prove the caller owns or is allowed to use this source? |
| Validation | Are path, query, body, QueryPlan, SQL, and database permissions checked before execution? |
| Limits | Are rate limits, row limits, timeouts, and plan limits in place? |
| Logging | Are tool calls observable without storing secrets or sensitive payloads? |
| Rollback | Can the team hide a tool, unpublish a scope, rotate a token, or pause a surface quickly? |
API-backed tool checklist
OpenAPI tools should map to known upstream operations, not arbitrary client-supplied requests.
- Map each published MCP tool to a stored OpenAPI operation.
- Hide internal, admin, destructive, token-management, bulk-update, and low-signal endpoints by default.
- Validate path, query, header, and body arguments against the stored schema.
- Strip or override client-supplied headers that should not reach the upstream API.
- Keep upstream auth in the Gateway and issue client-facing Gateway tokens instead.
- Log the tool name, integration, caller, latency, success or error state, and redacted argument summary.
- Treat write operations as reviewed workflows, not automatic exports from OpenAPI.
Database-backed tool checklist
Database tools need a stricter model because the source is broad by default.
- Publish a database scope around a workflow, schema, or business domain rather than the whole database by default.
- Keep schema tools metadata-only; they should never return sample rows or unrestricted row payloads.
- Set column permissions for visible, hidden, sensitive, selectable, filterable, sortable, groupable, aggregatable, and mask mode.
- Use QueryPlan mode first unless a reviewed workflow specifically needs SqlScript mode.
- Never publish QueryPlan and SqlScript executor tools at the same time for one scope.
- Reject cross-database, cross-schema, cross-scope, and cross-owner access.
- Validate generated SQL again before execution and redact sensitive parameters in audit logs.
Credential boundary
A production MCP client should not become the place where upstream secrets live.
| Secret or token | Should the MCP client have it? | Why |
|---|---|---|
| Gateway token | Yes, if the client needs to call the Gateway. | It authenticates the client to the Gateway surface. |
| Upstream API key | No. | The Gateway should hold and apply upstream credentials server-side. |
| Database connection string | No. | Database credentials should be encrypted at rest and never returned after save. |
| Admin/control-plane token | No. | Client tool execution should not require broad management privileges. |
| User-entered sensitive values | Only when required for the task. | Inputs should be validated, minimized, and redacted in logs. |
Observability and audit
If a tool can affect a real system, the team needs to see how it is being used.
| Signal | Why it matters |
|---|---|
| tools/list visibility | Confirms what the client can discover. |
| Tool call success and failure | Shows whether the surface is usable and where validation blocks requests. |
| Latency | Highlights slow upstream APIs, database queries, and client timeouts. |
| Rate and quota pressure | Prevents one client or agent loop from exhausting shared capacity. |
| Validation errors | Reveals unclear prompts, missing permissions, broad questions, or weak descriptions. |
| Redaction status | Confirms secrets and sensitive values are not persisted. |
Minimum test plan
Test the happy path and the rejected path before opening the surface to more clients.
- Run tools/list and confirm only expected tools are visible.
- Ask Gateway Chat realistic questions and confirm the intended tool is selected.
- Send invalid arguments and confirm the Gateway rejects them before upstream execution.
- For API tools, try an unpublished operation and confirm it cannot run.
- For database tools, try hidden columns, unpublished tables, cross-scope joins, and excessive limits.
- Rotate or revoke a token and confirm the client loses access.
- Inspect logs for redaction, latency, caller identity, result state, and validation errors.
Common risks
Most MCP risk comes from broad tools, unclear descriptions, misplaced credentials, and weak validation.
| Risk | Mitigation |
|---|---|
| Broad API tool | Hide endpoints that are not needed for the workflow. |
| Unclear tool description | Write agent-ready descriptions with purpose, inputs, constraints, and expected result. |
| Prompt-held credential | Move credentials into the Gateway and use client-facing Gateway tokens. |
| Raw database access | Use metadata-only schema tools and validated executor tools. |
| Overlapping tools | Rename, hide, or rewrite tools so the model has a clear choice. |
| Unlogged execution | Treat tool calls like production integration traffic and log with redaction. |
| Policy in prompt text | Use prompts for guidance only; enforce policy in backend validation. |
Red flags before launch
Pause the rollout if any of these are true.
- The client config contains an upstream API key or database connection string.
- An OpenAPI import has been published wholesale without curation.
- A database schema tool returns row samples.
- A database executor accepts free-form SQL without conservative validation.
- Tool descriptions are copied directly from vague endpoint comments.
- Logs contain tokens, connection strings, raw credentials, or sensitive payload values.
- No one can quickly disable the tool or rotate the token if behavior looks wrong.
Operating model
Treat MCP traffic like production integration traffic.
AI-driven tool calls need observability, rate controls, audit trails, and change control. Teams should be able to pause integrations, hide tools, update descriptions, rotate tokens, and adjust database scope permissions without changing every client manually.
Security review should happen before the catalog grows. A small, well-described, observable MCP surface is more useful than a broad catalog that nobody can explain or audit.
Sources and further reading
Common questions
Should MCP security live in prompts?
No. Prompts can guide behavior, but validation and enforcement should live in the Gateway or another trusted backend layer.
What is the safest first publish surface?
Start with a narrow OpenAPI operation set or a read-only database scope with only the columns needed for one workflow.
Why do descriptions matter for security?
Clear descriptions reduce accidental tool misuse by helping AI clients choose the intended tool and understand constraints.
Should write tools be published by default?
No. Write tools should be reviewed as workflows. Confirm required inputs, upstream permissions, logging, confirmation behavior, and rollback options before publishing them.
What should MCP logs include?
Logs should include tool name, source, caller, success or error state, duration, validation errors, row count or result size when relevant, and redacted argument or policy summaries.
What should never appear in MCP logs?
Connection strings, upstream API keys, bearer tokens, raw credentials, and sensitive payload values should not appear in persistent logs.
Is tools/list a security risk?
It can be if the catalog is too broad. The tools/list response should expose only tools the authenticated client is allowed to discover and use.