An agent with both a Redis server and a Postgres server has two tools named something like 'query'. The model picks by description, and if the descriptions are both 'access the database', it will pick wrong — scanning a table for a value that was supposed to be a cache hit, or reading a cache entry as if it were the record of truth.
That is not a model failure. It is a tool-description failure. This page is about writing the descriptions and the boundaries for the two servers.
The short answer
Describe Redis as fast, volatile, key-based, and correct only as a cache. Describe Postgres as the durable, relational source of truth. If the agent needs to decide, the question it should be able to answer is 'would a stale value here be acceptable'.
What each one is for
| Need | Redis | Postgres |
|---|---|---|
| Get by a known key | Yes | Possible but slower |
| Filter and join | No | Yes |
| Counter or rate limit | Yes | Awkward |
| Durable record | No | Yes |
| Stale answer acceptable | Yes | No |
The last row is the decision rule an agent can actually apply. A cache value may be old; a database value is the record.
The description that works
A Redis tool description should say what the values are and how old they might be: 'cached profile snapshots, may be up to five minutes stale, miss means absent'. A Postgres description should say what the tables represent and that it is the source of truth: 'accounts and orders, current, authoritative'.
Those two sentences let the model choose correctly without a prompt. It is the cheapest reliability improvement in an MCP setup.
The failure modes
The first is a cache miss read as absence. Redis returns nothing, the agent concludes the object does not exist. The fix is in the tool: a miss should be an explicit 'not cached', not an empty result.
The second is a database scan triggered by a cache-shaped question. The fix is a row limit and a read-only user, which turns a cost incident into a fast failure.
The third is the agent writing to the cache and treating that as a durable change. Redis writes should be separate tools with names that say what they do.
A worked example
A support agent answers 'what plan is this account on'. With good descriptions it reads Postgres, because the description says the plan is authoritative. With bad descriptions it may read Redis, return a stale plan, and answer confidently — the kind of error that is invisible in a demo and expensive in a refund conversation.
The general rule
Two data tools with the same shape need descriptions that state their guarantees, not their technology. An agent does not know what Redis is; it knows what the tool says it returns.
Frequently asked questions
Should I expose both at all? Yes, when they serve different questions. Hiding one pushes the same decision into a prompt.
Can one server proxy both? It can, and then the description becomes even more important, because the tools look identical.
What about writes? Separate tools, separate permissions, and a human in the loop for anything durable. See Redis vs Postgres and MCP servers.
Last checked: 12 November 2026.
Related: Redis vs Postgres, guardrails, and MCP servers.
