MCP support is a start: designing APIs that agents can use responsibly
A tool connection does not define permission, reversibility, billing, or auditability. A practical checklist for exposing business operations to AI agents.
この記事を日本語で読む →
A callable tool is not a safe business operation
MCP gives a client a standard way to discover and call tools. It does not decide which employee may approve a refund, whether an action is reversible, how a customer is billed, or what evidence an auditor will need later. Those remain product and API design decisions.
Wrapping every CRUD endpoint as a tool can make an agent powerful without making its intent legible. The more consequential the operation, the more important it is to make the boundaries explicit.
Design the operation, not just the endpoint
| Design question | A useful API property |
|---|---|
| What is the agent allowed to do? | Operation-level permission evaluated on the server |
| What will change? | A preview or dry-run result with affected objects |
| Can it safely retry? | Idempotency and a stable operation identifier |
| Can a person stop it? | An approval step before consequential writes |
| What happened afterward? | An audit record with actor, action, time, and outcome |
| What is charged? | Clear usage units and limits enforced by the service |
The tool description should explain parameters and side effects, but a description is not an authorization boundary. A server must still validate the caller and the operation. A model can misunderstand a description; it should not be able to bypass business rules because of that misunderstanding.
Make failure and review first-class
For a write operation, return an actionable error rather than a vague failure. Where practical, let a person see the proposed change before it is committed. Keep the underlying service's invariants in one place so web UI, API clients, and MCP tools obey the same rules.
A useful agent audit trail also distinguishes an attempted call from a completed change. “The agent asked to publish” and “the service published” are different facts.
Contextberg's narrower example
Contextberg uses an MCP bridge to expose selected local work context to compatible agents. The desktop app remains the owner of the recorded history and its capture controls. This is a read-oriented example of a broader principle: define the data boundary and operation semantics before treating the connection as complete.
If your SaaS lets agents act on behalf of customers, the same principle becomes more demanding. Model the business operation, enforce permissions in the service, and keep a record that a human can inspect.