MCP governance

MCP audit logs and rate limits

Agents retry, fan out and work without pausing, so traffic through an MCP server behaves differently from your other API clients. Limits keep a bad loop small, and a good audit log explains it afterwards.

Written by Octri · Checked 3 November 2026

What an audit log should record

The specification tells servers to rate limit tool calls and tells clients to log tool usage for audit. It leaves the format to you. For each write, these fields answer most of the questions an incident raises:

  • The tool name and the API request it produced
  • The arguments, with credentials and personal data removed
  • The person or team the call acted for, and the client that sent it
  • Whether a person approved it, declined it, or a policy allowed it
  • The status that came back, and any correlation ID your API logs share

Sign-in and scope events

Tool calls are half the record. The specification also suggests logging scope elevation, meaning what was requested and what was granted. Together with grants and revocations, that shows how an agent came to hold the access it used.

Per-tool rate limits

One limit for the whole server treats a search and a refund the same. Set limits per tool, starting from what a person doing that job would plausibly need, and give expensive or sensitive tools their own lower number.

Return a limit as a tool error with isError set and a clear message. The specification notes that clients should pass tool execution errors to the model, so the agent can read the message and adjust.

Write caps

A rate limit slows a loop. A write cap ends it. Capping the writes in one run bounds how much an agent can change before a person looks, however slowly the calls arrive.

Protocol sessions no longer exist as of revision 2026-07-28, so a server on that revision needs its own definition of a run, such as a grant, a time window or a workflow handle.

Separating agent traffic

Your API’s own limits still apply behind the server. Identify MCP traffic to your API so you can see it in your metrics, and so a busy agent spends its own budget and leaves the rest of that customer’s traffic alone.

How Octri handles this

The audit log records each write an agent attempted: the tool and request, its arguments, who sent it and from which client, whether the person approved it, and the status that came back. You can export it. It is kept for 12 hours on Free, 30 days on Starter, 90 days on Growth and 365 days on Business.

Cap writes per session stops a session after a set number of calls that change data. Cap calls per minute per tool slows any single tool, with per-tool limits for those that need their own number. Both apply on every plan.

Limits are checked before the approval prompt, so an agent over its cap is told so without asking the person anything.

Signed-in people are listed with the client they used and when it last made a call, and any grant can be ended from that list.

Questions

That depends on the data. Your API’s access logs usually cover reads already, so many teams keep the MCP audit log to writes. Reads of regulated data are the common exception. Octri’s audit log records writes.

References

Checked against MCP specification revision 2026-07-28 on 3 November 2026.

Try it on your own spec

Generate an MCP server from your OpenAPI spec on the Free plan, with every tool set to run, ask first or stay off.