Look up AgentCat sessions and issues next to your server logs

Last verified on Nov 8, 2026.

If you ship an MCP server, your users are mostly AI agents, and a failure rarely arrives as a bug report. It shows up as a session where a client called a tool, got an error, and gave up. You see the server-side half in your logs. AgentCat holds the other half: which client called, in what order, and how the session ended.

Connecting AgentCat lets the Sazabi agent, part of Sazabi's AI-native observability and security platform, read that session data while it reads your service logs. One thread can then hold both the error and the conversation that triggered it.

What the Sazabi agent can do with AgentCat

The connector uses AgentCat's hosted MCP server at https://mcp.agentcat.com/mcp. You authorize with OAuth, and AgentCat enforces your account permissions, so a project you cannot open in AgentCat is not available to the agent. AgentCat lists ten tools:

• list_projects and get_project_overview to find a project and read its usage and performance summary
• search_sessions and get_session to find sessions and read one in detail
• search_issues and get_issue to browse tracked issues and open one
• get_metric_trend and get_metric_breakdown to see how a metric moves over time and how it splits
• list_skills and load_skill to load AgentCat skills into a workflow

A project in AgentCat is the unit of organization. It usually maps to one MCP server or one environment of it, so asking about production versus staging is a matter of picking the project.

Questions it answers

• Which tools in this MCP server are called most, and which fail most?
• What did the session that errored at 14
  actually do, step by step?
• Which client or user was affected by this tracked issue?
• Did latency or error volume change after the release, and for which tool?
• What does the agent's stated intent look like for the calls that failed?

That last one works because AgentCat adds a context parameter to your tool schemas and asks the calling agent to explain why it is making each call.

A worked example: an MCP tool errors for one client

Your MCP server's search_files tool has a spike of 500s in your own logs. You ask in a thread:

Errors on search_files in mcp-gateway started around 14:15 UTC. In AgentCat,
find the project for mcp-gateway, search sessions with errors in that window,
open one, and tell me which client made the calls and what it was trying to
do. Then break down the tool's error metric by client.

The agent calls list_projects to find the project, then search_sessions for the window. get_session on one result returns the sequence of events with timing and error messages, and the stated intent where the SDK captured it. It then calls get_metric_breakdown for the tool's error metric, split by client, to show whether one client accounts for the errors. Back in Sazabi, it can match the session's request times to the matching error lines in your logs.

The pairing is the point. AgentCat says what the client sent and expected. Your logs say what the server did with it. If the failing calls all share one client, the cause is probably a malformed argument. If they spread across clients, check the server deploy next. If search_issues returns a tracked issue that covers the same tool, ask the agent to open it with get_issue before filing a new one.

How it fits with other integrations

AgentCat covers one layer: how agents use your MCP server. For the model-call layer, see LangSmith and Langfuse, and for the broader set browse the AI frameworks category. The Context Company is another source of agent runs and sessions. Your server's own logs reach Sazabi through OpenTelemetry, and the integrations index lists every method.