The AgentGuard47 server provides read-only access to agent trace data, guard alerts, usage metrics, and cost breakdowns for the AgentGuard runtime monitoring system.
Query trace summaries (query_traces): Search and paginate through trace summaries, filterable by service name and time range, returning metadata like trace ID, event/error counts, duration, and cost.
Get full trace details (get_trace): Retrieve the complete event tree for a specific trace ID, including all spans, tool calls, LLM calls, guard triggers, and errors.
Get trace decisions (get_trace_decisions): Extract normalized decision events (proposals, overrides, approvals, bindings) from a trace — useful for auditing human-in-the-loop workflows.
Get alerts (get_alerts): Fetch recent guard alerts such as loop detections and budget overruns, optionally filtered by time.
Check usage quota (get_usage): View current event quota consumption versus plan limits, including retention period and plan details.
Get cost breakdown (get_costs): Retrieve the current month's cost breakdown by model, total spend, and estimated savings from guard interventions.
Budget health check (check_budget): Run a quick pass/fail assessment combining usage quota and cost data to determine if operations are within safe limits.
Provides runtime guards for CrewAI agents, including loop, retry, and budget limits via optional integration extra.
Integrates runtime guards with LangChain agents to enforce budgets, loops, and retry limits via optional extra.
Adds runtime control to LangGraph agents, including hard budget caps and loop detection via optional integration extra.
Auto-patches OpenAI SDK to trace and enforce budget limits on chat completions, stopping overspend in-process.
Stop runaway agents before they burn money.
Zero-dependency Python kill switch for AI agents. Hard budget caps. Loop detection. Local traces. MIT.
pip install agentguard47pip install agentguard47
agentguard doctor # package ok?
agentguard demo # offline proof (no API keys)from agentguard import BudgetGuard, LoopGuard, Tracer, patch_openai
budget = BudgetGuard(max_cost_usd=5.00, warn_at_pct=0.8)
loop = LoopGuard(max_repeats=3)
tracer = Tracer(service="my-agent", guards=[loop])
patch_openai(tracer, budget_guard=budget)
# every OpenAI call is now traced + budget-enforcedWhen spend crosses the hard limit, BudgetExceeded is raised and the run stops.
Session budget can still have headroom. One goal can still be killed:
with budget.goal("refund", max_cost_usd=0.50, warn_at_pct=0.8) as g:
g.attempt()
budget.consume(cost_usd=0.12)
# BudgetExceeded names the goal when it crossesagentguard report .agentguard/traces.jsonl
agentguard incident .agentguard/traces.jsonlOr scaffold a starter file:
agentguard quickstart --framework raw --write
python agentguard_raw_quickstart.pyRelated MCP server: Langfuse MCP Server
Problem | Guard | Exception |
Spend blowup |
|
|
Same tool forever |
|
|
Fuzzy / A-B-A-B loops |
|
|
Retry storms |
|
|
Hung runs |
|
|
Spam calls |
| — |
Wallet drain (x402/USDC) |
|
|
Not a dashboard. Not a model router. An in-process exception that kills the bad run mid-flight.
Agents that pay per-call via x402 (USDC micropayments) can drain a wallet in a
silent loop. X402SpendGuard wraps the payment step and refuses before paying:
from agentguard import X402SpendGuard
guard = X402SpendGuard(
max_total_usd=5.00, # wallet cap, add period="day" for a daily reset
max_per_endpoint_usd=1.00, # cap per resource URL
max_per_call_usd=0.10, # refuse any single payment above this
)
guard.charge(0.001, "https://api.example.com/search", my_x402_pay_step)AgentGuard meters and refuses; it never signs or settles. Amounts come from your x402 client. No crypto dependencies.
Hard stops — exceptions inside your process, not after-the-fact alerts
Task-level budgets — BudgetGuard.goal(...) for sub-task caps + warn hooks
Local traces — JSONL by default; no network unless you opt in
Zero deps — stdlib only; Python 3.9+
Provider patches — patch_openai / patch_anthropic
Framework hooks — LangChain, LangGraph, CrewAI (optional extras)
No API key required for local proof
No network unless you configure HttpSink
MIT licensed
The SDK is the free local proof path. Start local. Add hosted ingest later only if you want retained history, alerts, team visibility, spend trends, hosted decision history, or dashboard-managed remote kill signals. Local guards remain authoritative. HttpSink mirrors trace and decision events; it does not execute remote kill signals by itself.
OpenAI · Anthropic · LangChain · LangGraph · CrewAI · raw agent loops
pip install "agentguard47[langchain]" # optional extras as neededThe base install declares zero runtime dependencies. pip install agentguard47 pulls nothing, so a default install adds no third-party exposure.
Extras pull real dependency trees. The [crewai] extra pulls chromadb, which carries PYSEC-2026-311: a pre-authentication remote code execution advisory with no fixed release available. Nothing in AgentGuard calls the affected endpoint, and installing the extra does not start a ChromaDB server. You are exposed only if you run a ChromaDB server reachable by untrusted callers. A 2026-08-28 pip-audit run also flags CVE-2026-45830, CVE-2026-45831, and CVE-2026-45833 against the same chromadb release, none with a fixed version. The [langchain], [langgraph], and [otel] extras resolve clean under pip-audit. See #702 for the full finding.
MCP server — npx -y @agentguard47/mcp-server
AgentGuard on the web (hosted history, alerts, and MCP visibility for Claude Code, Cursor, and Codex): https://bmdpat.com/tools/agentguard?utm_source=agentguard47&utm_medium=readme&utm_campaign=touchpoints
The hosted page is an optional next step, not a requirement. The SDK stays free, local, and MIT, and the local guards stay authoritative. Nothing in this package phones home. The only network egress is a sink or exporter you configure yourself, such as HttpSink or an OpenTelemetry exporter.
MIT · Built for people who ship agents and hate surprise bills.
Quick pass/fail budget health check. Combines usage quota and cost data to give a summary of whether you're within safe operating limits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description says 'quick pass/fail' and combines data, but doesn't explain what 'safe operating limits' means, if it's read-only, latency, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that efficiently conveys purpose and scope, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides adequate context for a simple check tool given no input/output schema, but could mention if results are cached or real-time.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema (100% coverage). Description adds meaning that it's a quick check combining two sources, exceeding baseline for zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it performs a pass/fail budget health check by combining usage quota and cost data. Distinct from siblings like get_alerts or get_costs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied use for quick budget health check, but no explicit guidance on when to use vs alternatives (e.g., get_costs, get_alerts), nor conditions to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent guard alerts (loop detection, budget exceeded) and errors. Useful for checking if your agents are hitting safety limits.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max alerts to return (default 50) | |
| since | No | ISO timestamp — only alerts after this time |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states it 'gets' data, implying a read operation, but lacks details on side effects, permissions, rate limits, or response characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no fluff, and front-loads the core purpose. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and few parameters, the description could be more complete, e.g., mentioning that limit is a maximum, or that alerts are sorted by recency. It provides adequate but not rich context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema's parameter descriptions; it only provides context for alert types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving recent guard alerts and errors, with specific examples (loop detection, budget exceeded). It effectively distinguishes from sibling tools like get_costs and check_budget.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is 'useful for checking if your agents are hitting safety limits,' which implies usage context. However, it does not explicitly state when not to use it or offer alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get cost breakdown for the current month: total spend, cost by model, and estimated savings from guard interventions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool retrieves cost data for the current month, but does not mention whether it is a read-only operation, any authentication requirements, or potential impacts. Basic behavioral context is present but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose and concisely lists the output components. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description is fairly complete. It specifies the scope (current month) and three key output categories. It could mention whether historical months are available, but it is adequate for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so baseline is 4. The description adds value by explaining what the output includes (total spend, cost by model, savings), going beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets a cost breakdown for the current month, listing specific components: total spend, cost by model, and estimated savings. This is a specific verb+resource combination and distinguishes itself from sibling tools like check_budget and get_usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving cost details, but does not explicitly state when to use this tool vs alternatives like check_budget or get_alerts. There is no mention of exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full event tree for a specific trace by its trace ID. Shows all spans, tool calls, LLM calls, guard triggers, and errors.
| Name | Required | Description | Default |
|---|---|---|---|
| trace_id | Yes | The trace ID to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the output contents (spans, tool/LLM calls, guard triggers, errors), which is helpful for a read operation. Since no annotations are provided, the description carries the burden, and it covers the expected behavior well, though it could mention potential performance implications or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and includes key details. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with low complexity (1 required param, no nested objects, no output schema), the description is fairly complete. It explains the tool's function and output. Minor gap: could mention if the output is paginated or if there are limits, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'trace_id' is fully described in the schema with 'The trace ID to look up'. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full event tree for a specific trace using its trace ID. It lists the components of the tree (spans, tool calls, LLM calls, guard triggers, errors), which distinguishes it from siblings like 'query_traces' or 'get_trace_decisions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a trace ID and want a detailed view, but it does not explicitly state when to use this tool versus alternatives like 'query_traces' or 'get_trace_decisions'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract normalized decision.* events from one trace. Use this when a workflow includes proposal, override, approval, or binding steps.
| Name | Required | Description | Default |
|---|---|---|---|
| trace_id | Yes | The trace ID to inspect for decision events |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention side effects, authentication needs, rate limits, or what happens if trace_id is invalid. The term 'normalized' hints at transformation but is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words: first states action, second gives usage guidance. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no annotations, no output schema), the description covers purpose and usage but lacks behavioral details and output hints. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully describes the trace_id parameter. The description adds no new semantic information beyond confirming its role. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Extract' and resource 'normalized decision.* events from one trace', specifying it focuses on decision events like proposal, override, approval, or binding steps. This distinguishes it from sibling tools like get_trace (full trace) and query_traces (search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when a workflow includes proposal, override, approval, or binding steps', providing clear context for invocation. While it doesn't explicitly state when not to use or name alternatives, the positive guidance is sufficient for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check your current event quota usage and plan limits. Shows event count vs limit, retention period, and plan details.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description conveys a read-only operation by using verbs like 'Check' and 'Shows'. It details what data is returned (event count vs limit, retention period, plan details), which informs the agent of the tool's output. However, it doesn't mention authentication requirements, rate limits, or whether the operation is free, but these are less critical for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the purpose and then lists what is shown. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description adequately covers functionality and output content. It could optionally mention that it's a read-only operation or the output format, but the provided details are sufficient for an agent to understand its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema description coverage is 100%. The description adds no parameter-specific meaning beyond what the schema provides, which is baseline for this case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks event quota usage and plan limits, listing specific details (event count vs limit, retention period, plan details). It distinguishes from siblings like 'check_budget' and 'get_costs' which focus on financial aspects, while 'get_trace' and related are for trace data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing quota information ('Check your current event quota usage'), but does not explicitly state when to use this tool versus alternatives like 'check_budget' or 'get_alerts'. No when-not or conditional guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only search for retained AgentGuard trace summaries from the AgentGuard Read API. Requires AGENTGUARD_API_KEY with read access; create keys in the AgentGuard dashboard. Returns JSON with a traces array, newest traces first when the API supports ordering; items include trace_id, service, root_name, event_count, error_count, duration_ms, started_at, API key metadata, and total_cost when available. Defaults to a small page, accepts offset pagination, exact service filtering, and ISO 8601 since/until bounds. Use this to find candidate trace_id values; use get_trace for the full event tree of one trace or get_trace_decisions for decision.* events from a known trace.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum trace summaries to return. Defaults to 20; API maximum is 500. | |
| offset | No | Zero-based pagination offset for walking additional trace pages. | |
| service | No | Exact AgentGuard service name to filter by, such as a repo or agent label. | |
| since | No | ISO 8601 timestamp; include only traces that started at or after this time. | |
| until | No | ISO 8601 timestamp; include only traces that started at or before this time. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, etc.), description details response format (JSON with traces array and listed fields), default pagination, ordering (newest first when supported), and filtering capabilities. Provides full behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundant words. Front-loaded with purpose and auth requirement. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 5 optional parameters and no output schema, the description covers purpose, auth, response structure, pagination, filtering, ordering, and links to sibling tools. Sufficient for an AI to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters are fully described in the input schema (100% coverage). The description adds minor context like pagination and filtering, but does not provide significantly new information beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a read-only search for trace summaries, specifies the API source, and lists key fields. It distinguishes itself from siblings like get_trace and get_trace_decisions by explaining its role in finding candidate trace IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use this tool (find candidate trace IDs) and explicitly directs to alternatives (get_trace for full tree, get_trace_decisions for decision events). Also mentions required AGENTGUARD_API_KEY with read access.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.2.13query_traces5 fields changedInput schema / properties / limit / descriptionPrevious value: -"Max traces to return (default 20, max 500)"New value: +"Maximum trace summaries to return. Defaults to 20; API maximum is 500."Input schema / properties / offset / descriptionPrevious value: -"Offset for pagination"New value: +"Zero-based pagination offset for walking additional trace pages."Input schema / properties / service / descriptionPrevious value: -"Filter by service name"New value: +"Exact AgentGuard service name to filter by, such as a repo or agent label."Input schema / properties / since / descriptionPrevious value: -"ISO timestamp — only traces after this time"New value: +"ISO 8601 timestamp; include only traces that started at or after this time."Input schema / properties / until / descriptionPrevious value: -"ISO timestamp — only traces before this time"New value: +"ISO 8601 timestamp; include only traces that started at or before this time."v0.1.0check_budgetget_alertsget_costsget_traceget_trace_decisionsget_usagequery_tracesEach tool targets a distinct aspect of agent guard monitoring: budget health, alerts, costs, trace details, trace decisions, usage quota, and trace search. No two tools have overlapping purposes, ensuring clear selection.
Most tools use the 'get_' prefix (5 of 7), but 'check_budget' and 'query_traces' break the pattern. While still readable, the inconsistency slightly reduces predictability.
7 tools is well-scoped for a monitoring-oriented server. Each tool serves a distinct and necessary function without being overwhelming or sparse.
The set covers key monitoring aspects: budget, alerts, costs, usage, and traces. Missing might be aggregate dashboards or write operations, but for a read-only guard monitoring server, the surface is reasonably complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Deterministic runtime safety for AI agents: scan PII, gate tool actions, verify LLM output.
AgentGuard — 20-tool AI safety MCP: policy preflight, risk scoring, audit logging, rate limits.
Budget & cost control for AI agents — per-agent spend caps + rate limits before each call.
The WAF for agents. Pattern-based + heuristic firewall scans prompts, RAG documents, tool argume...
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bmdhodl/agent47'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
