Observability for AI agents
Read what your agents actually did. Sessions, tool calls, errors, trigger runs, escalations and compute spend, all queryable from the same MCP connection.
Copy the setup prompt.
Your agent does the rest.
Fetch and execute the appropriate instructions to set me up for superagnt_ from https://mcp.superagnt.com/agent-setup/prompt.md» once it is connected, run this so your agent can switch the source on itself.
agnt_tools_enable({ families: ['observability'] })Everything your agent can do with it
agnt_observability_read_session returns a compact per-event index first, then lets you pull only the events that matter instead of the whole transcript.
agnt_observability_search_sessions filters by free text, status, tool name, or problematic only, which surfaces the sessions that hit an error.
Recent schedule and webhook invocations for an agent, with dispatch status, the session each produced, and the error when one failed.
Blocking human-in-the-loop requests, both gated tool approvals and escalated questions, so you can see what an agent is stuck waiting on.
Compute and credit usage for a session or an agent, totalled and broken down by category.
agnt_observability_get_diagnostics rolls deploy state, dependency checks, recent sessions, trigger failures, escalations, usage and open config requests into one call.
Verify an agent has the integrations, connectors, MCP connections and workspace resources its config implies, before blaming the prompt.
Every tool in this family reads. None of them change an agent, a session or a config.
tool names10as your agent sees them
agnt_observability_list_agentsagnt_observability_list_sessionsagnt_observability_search_sessionsagnt_observability_read_sessionagnt_observability_list_trigger_runsagnt_observability_get_session_usageagnt_observability_list_escalationsagnt_observability_get_diagnosticsagnt_observability_check_dependenciesagnt_observability_read_config_requestThree jobs it can start on today
Debug a failing agent
Search for problematic sessions, read the event index for the worst one, and pull the failing tool call with its arguments and its error rather than guessing from the reply.
Find out why a schedule did nothing
List trigger runs for the agent. A dispatch that never produced a session is a different problem from a session that ran and gave up, and the run list tells you which happened.
Watch what a run costs
Pull session usage after changing a prompt or a tool set, and see whether the fix actually made the agent cheaper or only quieter.
What it costs to run
Platform tools carry no per-tool price. What you pay is the AI and credit usage the work causes, on the same workspace balance every other tool draws from.
Each run is itemized, so you can see which agent spent what and on which call.
how credits work →Before you wire it up
01Can an agent enable this itself?
Yes. Observability is read-only and grants no authority the caller does not already have, so agnt_tools_enable with observability is allowed, unlike the families that change workspace configuration.
02Does reading a session dump the whole transcript?
No. The default call returns a compact per-event index with position, time, type, tool, size and an error flag. You then fetch only the events you need.
03What is the fastest way to triage?
Call agnt_observability_get_diagnostics for the agent. It rolls deploy state, dependency checks, recent sessions, trigger failures, escalations and usage into one report.
04Can it change anything?
No. Every tool in the family is read-only, which is exactly why it is safe to hand to a debugging agent.
Point your client at https://mcp.superagnt.com/mcp and your agent has this, plus everything else on one balance.