Connecting Agents to Databases and APIs
Give agents safe access to real systems: read-only database tools, API wrappers, pagination, rate limits, and keeping credentials out of the model's reach.
An agent that can only read the files on your laptop is a clever assistant. One that can query your production database and call your company's APIs can answer real questions on its own: which customers churned last month, what's blocking the release, why an invoice failed. That's also the point where a confused or manipulated agent stops being an annoyance and becomes a real problem.
This lesson shows you how to connect agents to real systems safely. You'll build a read-only database tool backed by a locked-down database role, wrap a real API (GitHub's) with pagination, rate-limit handling, and errors written for the model, and learn where credentials should live so the model never sees them. The code is plain TypeScript functions you can expose through any tool mechanism, including the MCP servers you'll build later in this module.
Three rules for connecting agents to real systems
Everything in this lesson follows from three rules. Keep them in mind and most design decisions make themselves.
- Enforce limits outside the model. The model will eventually do something you didn't intend, through misunderstanding, overreach, or prompt injection (instructions hidden in content the agent reads). Database permissions, API token scopes, and checks in your tool code still hold when that happens. Instructions in a system prompt don't.
- Credentials stay in your code. The model asks for an action; your code performs it with credentials the model never sees. A key that never enters the context window can't be leaked by the model.
- Results are bounded and readable. Real systems hold millions of rows and return verbose JSON. A tool that dumps raw output burns context and buries the answer. Return a capped, trimmed result and say how to get more, as you learned in Designing Tools Agents Love to Use.