Stop runaway Python agents before they burn money.
AgentGuard47 is a zero-dependency runtime control SDK for Python agents. Add hard budget caps, loop detection, retry limits, timeouts, local traces, and incident reports without changing agent frameworks or sending data anywhere by default.
Use it when an agent can call tools, retry work, review code, or run long enough to create surprise spend.
pip install agentguard47Most agent tooling tells you what happened after the run. AgentGuard stops the bad run while it is happening.
Problem | What AgentGuard does |
Agent loops on the same tool | Raises |
Flaky tool retries forever | Raises |
Run spends too much | Raises |
Run hangs | Raises |
Team needs proof | Writes local JSONL traces and incident reports |
Dashboard comes later |
|
Design constraints:
zero runtime dependencies
MIT licensed
local-first by default
no API key required for local proof
no network calls unless you configure HttpSink
guards raise exceptions inside the running process
Related MCP server: Langfuse MCP Server
A Cursor agent ran a destructive sequence against PocketOS production and wiped the live database. Backups went with it.
Reported root cause from the team's postmortem:
one API key had write + delete on both prod and backups
backups lived in the same Railway environment as prod
no confirmation step before destructive actions
the agent was given enough rope to chain the calls in one turn
Source: r/devops thread
The "AI did it" framing buries the actual lesson: the blast radius was infra, not the model. AgentGuard does not replace least-privilege creds or isolated backups. It does kill the run before a loop, retry storm, or runaway turn finishes the job.
A BudgetGuard plus LoopGuard wired around the agent loop caps how much
it can do in one session:
from agentguard import BudgetGuard, LoopGuard, RateLimitGuard, Tracer
budget = BudgetGuard(max_calls=20, max_cost_usd=1.00)
loop = LoopGuard(max_repeats=2)
rate = RateLimitGuard(max_calls_per_minute=10)
tracer = Tracer(service="cursor-agent", guards=[loop, rate])
with tracer.trace("agent.run"):
budget.consume(calls=1)
# tool call here — guards raise on overrunA 9-second sequence of destructive calls trips LoopGuard or
RateLimitGuard long before it finishes. The exception kills the run
in-process. Pair this with scoped credentials and out-of-environment
backups for the rest of the blast radius.
agentguard doctor
agentguard demo
agentguard quickstart --framework rawdoctor verifies the install and local trace writing.
demo proves budget, loop, and retry stops offline.
quickstart prints the smallest starter for your stack.
Installed-package proof:
agentguard demoSource-checkout proof with local incident output and hosted-compatible NDJSON:
git clone https://github.com/bmdhodl/agent47.git
cd agent47
PYTHONPATH=sdk python examples/sticky_agent_proof.py --out-dir proof/sticky-agent-proof
agentguard incident proof/sticky-agent-proof/sticky_agent_proof_traces.jsonlExpected first value moment:
BudgetGuard stops simulated spend.
LoopGuard stops repeated tool calls.
RetryGuard stops a retry storm.
No API keys. No dashboard. No network calls.Notebook version:
Use this when you want a coding agent or teammate to add AgentGuard safely:
pip install agentguard47
agentguard doctor
agentguard quickstart --framework raw --write
python agentguard_raw_quickstart.py
agentguard report .agentguard/traces.jsonlOptional shared local defaults, saved as .agentguard.json in the repo root:
{
"profile": "coding-agent",
"service": "my-agent",
"trace_file": ".agentguard/traces.jsonl",
"budget_usd": 5.0
}Keep the first PR local-only. Add hosted ingest later only when retained incidents, alerts, or team visibility matter.
from agentguard import BudgetGuard, JsonlFileSink, LoopGuard, Tracer
budget = BudgetGuard(max_cost_usd=5.00, max_calls=50, warn_at_pct=0.8)
loop = LoopGuard(max_repeats=3)
tracer = Tracer(
sink=JsonlFileSink(".agentguard/traces.jsonl"),
service="support-agent",
guards=[loop],
)
with tracer.trace("agent.run") as span:
budget.consume(calls=1, cost_usd=0.02)
loop.check("search", {"query": "refund policy"})
span.event("tool.call", data={"tool": "search", "query": "refund policy"})
# Call your agent or tool here.Inspect the local proof:
agentguard report .agentguard/traces.jsonl
agentguard incident .agentguard/traces.jsonlIf you already call OpenAI or Anthropic directly, patch once and keep using the provider normally:
from agentguard import BudgetGuard, Tracer, patch_openai
budget = BudgetGuard(max_cost_usd=5.00, warn_at_pct=0.8)
tracer = Tracer(service="support-agent")
patch_openai(tracer, budget_guard=budget)
# OpenAI chat completions are now traced and budget-enforced.When accumulated cost crosses the hard limit, BudgetExceeded is raised and
the agent stops.
Guard | Stops | Example |
| dollar, token, or call overruns |
|
| exact repeated tool calls |
|
| similar calls and A-B-A-B loops |
|
| retry storms on the same tool |
|
| long-running jobs |
|
| calls per minute |
|
| hard turns that need a stronger model |
|
Guards are static runtime checks. They do not ask another model whether a run is safe. They raise exceptions.
All examples are local-first. No API key is required unless the example says so.
Example | What it proves |
budget, loop, and retry stops | |
one CrewAI-style retry storm proof with local incident and hosted NDJSON outputs | |
review/refinement loop stopped by budget and retry guards | |
one oversized token-heavy turn can blow a run budget | |
when to escalate from a cheap model to a stronger one | |
proposal, edit, approval, and binding decision events |
Sample incident:
docs/examples/coding-agent-review-loop-incident.md
Proof gallery:
docs/examples/proof-gallery.md
Starter files:
examples/starters/
AgentGuard can wrap raw Python code or integrate with common agent stacks.
agentguard quickstart --framework raw
agentguard quickstart --framework openai
agentguard quickstart --framework anthropic
agentguard quickstart --framework langchain
agentguard quickstart --framework langgraph
agentguard quickstart --framework crewaiOptional integration extras are opt-in. The core SDK stays stdlib-only.
pip install "agentguard47[langchain]"
pip install "agentguard47[langgraph]"
pip install "agentguard47[crewai]"
pip install "agentguard47[otel]"AgentGuard is not a generic tracing platform. It is the local runtime stop layer.
Capability | AgentGuard |
In-process hard budget caps | Yes |
Kill a bad run by raising an exception | Yes |
Loop and retry-storm detection | Yes |
Local JSONL traces | Yes |
Local incident reports | Yes |
Hosted ingest | Optional |
Required dashboard | No |
Runtime dependencies | None |
Competitive notes:
Capture proposal, human edit, approval, override, and binding events through the same event pipeline:
from agentguard import JsonlFileSink, Tracer, decision_flow
tracer = Tracer(sink=JsonlFileSink(".agentguard/traces.jsonl"))
with tracer.trace("agent.run") as run:
with decision_flow(
run,
workflow_id="deploy-review",
object_type="pull_request",
object_id="123",
actor_type="human",
actor_id="pat",
) as decision:
decision.proposed({"action": "merge"})
decision.approved(comment="Looks safe")
decision.bound(binding_state="merged", outcome="success")Supported event types:
decision.proposed
decision.edited
decision.overridden
decision.approved
decision.bound
Guide: docs/guides/decision-tracing.md
AgentGuard also ships a read-only MCP server for coding-agent workflows:
npx -y @agentguard47/mcp-serverUse the SDK to enforce local safety where the agent runs. Use MCP when a client like Codex, Claude Code, or Cursor needs read access to traces, decisions, costs, usage, and budget health.
The SDK is the free local proof path. The hosted dashboard is for retained history, alerts, team visibility, spend trends, hosted decision history, and dashboard-managed remote kill signals.
Use local SDK when | Use hosted dashboard when |
You are proving AgentGuard in one repo | Multiple people need the same incident history |
You need hard stops for loops, retries, timeouts, or budget burn | Runs need retained alerts and follow-up outside the terminal |
You want JSONL traces and reports without an API key | You need spend trends across traces, services, or teammates |
You are testing an agent before production | Operators need dashboard-managed remote kill signals |
Start local. Add hosted ingest when the work becomes shared, expensive, or risky enough that local files are no longer enough.
from agentguard import HttpSink, Tracer
tracer = Tracer(
sink=HttpSink(
url="https://app.agentguard47.com/api/ingest",
api_key="ag_...",
)
)HttpSink mirrors trace and decision events to the dashboard. It does not
execute remote kill signals by itself.
Dashboard contract:
docs/guides/dashboard-contract.md
Generate a local incident report:
agentguard incident .agentguard/traces.jsonl --format markdown
agentguard incident .agentguard/traces.jsonl --format htmlFail CI when a trace violates safety expectations:
from agentguard import EvalSuite
result = (
EvalSuite(".agentguard/traces.jsonl")
.assert_no_loops()
.assert_budget_under(tokens=50_000)
.assert_no_errors()
.run()
)
assert result.passedPackage: agentguard47
Python: 3.9+
License: MIT
Core runtime dependencies: zero
Trace format: JSONL
Local commands: doctor, demo, quickstart, report, incident, eval
MCP package: @agentguard47/mcp-server
Topic | Link |
Getting started | |
Coding-agent setup | |
Safety pack | |
Dashboard contract | |
Decision traces | |
Managed sessions | |
Activation metrics design | |
Proof gallery | |
PyPI Trusted Publishing |
agent code
|
v
Tracer
|
+-- guards raise exceptions locally
|
+-- sinks write traces locally or mirror to hosted ingestRepository layout:
sdk/ Python SDK package
mcp-server/ read-only MCP server
docs/ guides and competitive notes
examples/ runnable local examples
ops/ repo operating docs
memory/ SDK-only state and decisionsNo secrets are required for local mode.
Do not put API keys in .agentguard.json.
Hosted ingest API keys should be stored in environment variables.
Local guards remain authoritative even when hosted ingest is configured.
Report security issues through GitHub Security Advisories or by email:
pat@bmdpat.com.
Contributions are welcome when they keep the SDK small, local-first, and zero-dependency.
Before opening a PR:
python -m pytest sdk/tests/ -v
python -m ruff check sdk/agentguard/
python scripts/sdk_release_guard.pyUseful links:
MIT. See LICENSE.
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
