Most bug trackers are built for humans — a web form, a CAPTCHA, a Jira board with a human triaging every ticket. That works fine when the only people filing bugs are people. But what happens when your own AI agents start discovering issues?
Agent Media Tools exposes a public Bug Queue API where both humans and AI agents can submit genuine bug reports with a simple HTTP POST. The queue provides structured status and a compact format suitable for an authorized review worker. Filing a report does not promise an automatic fix: reproduction, code changes, review, and deployment still follow the project's safety controls.
In this post, you'll learn how the bug queue works, how to submit bugs via curl and Python, how to read the queue, and where an agent-assisted review process fits.
The Bug Queue is a simple SQLite-backed ledger. Anyone — logged-in user, anonymous visitor, or autonomous agent — can submit a bug report by sending a POST request to /api/bugs with a title and description. The endpoint enforces a per-IP rate limit of 8 submissions per hour to keep the queue manageable, but there is no credit cost and no API key required for submitting.
Each bug gets a severity label (critical, high, medium, low) and a unique slug. The queue tracks status transitions:
| Status | Meaning |
|---|---|
open | Awaiting triage or fix |
in_progress | An authorized maintainer or worker is investigating |
fixed | Resolved — resolution notes may include links or commit info |
wontfix | Expected behavior or out of scope |
duplicate | Already tracked by another bug report |
Anyone can read the public queue. Status changes require authorized credentials, preventing anonymous visitors from rewriting issue state.
Agent Media Tools exposes over 70 API tools via REST and MCP. When one of those tools misbehaves — returns a wrong error, accepts an invalid parameter, or crashes on edge input — your agent is often the first one to notice. The standard workflow today is:
With the Bug Queue API, step 2 becomes:
POST /api/bugs with the repro steps → keeps running.This removes the manual transcription step between an agent observing a failure and maintainers receiving a reproducible report. It does not remove human accountability for changes or production releases.
The submission endpoint is completely open — no authentication, no API key, no sign-up required. Just send a POST with a title and description:
curl -s -X POST https://agentmediatools.com/api/bugs \
-H "Content-Type: application/json" \
-d '{
"title": "Image resize returns 400 on valid width",
"description": "Calling /api/resize with width=800 and height=600 on a public JPEG returns a 400 error instead of a resized image. Expected the standard resized response.\n\nRepro:\ncurl https://agentmediatools.com/api/resize?url=...&width=800&height=600",
"severity": "high",
"page_url": "/api/resize"
}' | python3 -m json.tool
Response:
{
"success": true,
"bug": {
"id": 42,
"slug": "bug_a1b2c3d4e5f6",
"title": "Image resize returns 400 on valid width",
"description": "Calling /api/resize with width=800...",
"severity": "high",
"status": "open",
"source": "human",
"page_url": "/api/resize",
"agent_label": null,
"created_at": "2026-07-27 10:15:00",
"updated_at": "2026-07-27 10:15:00",
"fixed_at": null,
"resolution_notes": null
},
"message": "Bug filed. The Fixer Worker (Hermes) picks up open bugs on its cron.",
"poll_url": "/api/bugs/bug_a1b2c3d4e5f6"
}
The response includes a poll_url so you (or your agent) can check back later for a resolution.
| Field | Type | Description |
|---|---|---|
title | string (required) | Short bug title, min 5 chars, max 200 |
description | string (required) | Full repro steps, min 10 chars, max 8,000 |
severity | string | One of critical, high, medium, low (default: medium) |
page_url | string | URL of the page or API endpoint involved |
email | string | Contact email for follow-up (optional) |
agent_label | string | Your agent's name, if submitting as an agent |
For agents running Python, the same submission is a one-liner with requests:
import requests
resp = requests.post("https://agentmediatools.com/api/bugs", json={
"title": "QR code generation fails on long URLs",
"description": "Calling /api/qr with a URL over 2048 characters returns a 500 error. QR codes support longer payloads in the spec. Expected a valid QR code or a clear error message about the limit.",
"severity": "medium",
"page_url": "/api/qr",
"source": "agent",
"agent_label": "my-monitoring-bot"
})
data = resp.json()
print(f"Filed #{data['bug']['slug']} — {data['bug']['status']}")
# Poll later:
poll = requests.get(f"https://agentmediatools.com/api/bugs/{data['bug']['slug']}")
print(poll.json()["bug"]["status"])
When an agent submits with a Bearer token in the Authorization header, the API automatically attaches the agent's identity to the bug record:
requests.post("https://agentmediatools.com/api/bugs",
headers={"Authorization": "Bearer mt_live_..."},
json={
"title": "...",
"description": "...",
})
The queue is fully public. Anyone can list open bugs or check a specific bug's status.
curl -s https://agentmediatools.com/api/bugs | python3 -m json.tool
Response includes counts and the bug array:
{
"success": true,
"counts": { "open": 3, "in_progress": 1, "fixed": 12 },
"bugs": [ ... ]
}
# All fixed bugs curl -s "https://agentmediatools.com/api/bugs?status=fixed" # All bugs (any status) curl -s "https://agentmediatools.com/api/bugs?status=all"
curl -s https://agentmediatools.com/api/bugs/bug_a1b2c3d4e5f6 | python3 -m json.tool
The Fixer Worker uses a compact QA format by appending ?format=fixer. This strips status metadata and returns a prioritized findings array:
curl -s "https://agentmediatools.com/api/bugs?format=fixer" | python3 -m json.tool
{
"success": true,
"generated_at": "2026-07-27T12:00:00.000Z",
"source": "bug-queue",
"count": 3,
"findings": [
{
"id": "bug_a1b2c3d4e5f6",
"severity": "critical",
"title": "...",
"description": "...",
"priority_rank": 1
}
]
}
The queue supports an authorized review worker, but it deliberately separates reporting from permission to change code or production. A safe review flow can:
GET /api/bugs?status=openNormal agents can read and submit reports, but status mutation is restricted to authorized actors. The public integration does not expose the server's internal worker credentials.
If your agent connects via the MCP server, two tools expose the bug queue directly:
| MCP Tool | What it does |
|---|---|
submit_bug | Submit a bug report. Accepts title, description, severity, page_url, agent_label. Requires title+description. |
list_bugs | List bugs by status (open, in_progress, fixed, wontfix, duplicate, all). Defaults to open. |
This means any MCP-connected agent — Claude Desktop, a custom Hermes agent, an OpenHands session — can file bugs as easily as it calls any other tool.
A background agent can read GET /api/bugs-stats, flag an unusual increase, and route critical reports to a human review channel. Treat severity supplied by a reporter as a hint, not a trusted production decision.
A CI pipeline that tests API endpoints after a deploy can submit a report for a confirmed test failure. Including the exact request and sanitized output makes independent reproduction faster; it does not replace reproduction.
if [ $? -ne 0 ]; then
curl -s -X POST https://agentmediatools.com/api/bugs \
-H "Content-Type: application/json" \
-d "{
\"title\": \"Test failure: $TEST_NAME\",
\"description\": \"$REPRO_STEPS\",
\"severity\": \"medium\",
\"page_url\": \"$ENDPOINT\",
\"source\": \"agent\"
}"
fi
When an agent encounters unexpected behavior — say, a watermark API that accepts an out-of-range value — it can log a medium-severity report with the exact request that triggered the observation. A maintainer can then reproduce and validate the behavior before deciding whether code should change.
For dashboards and monitoring, GET /api/bugs-stats returns just the counts:
curl -s https://agentmediatools.com/api/bugs-stats | python3 -m json.tool
{
"success": true,
"open": 3,
"in_progress": 1,
"fixed": 12,
"total": 16
}
This is the lightest possible endpoint — no pagination, no descriptions, just four numbers.
The Bug Queue API is intentionally generous because bug reports are high-signal, low-volume data:
| Limit | Value |
|---|---|
| Rate limit (submit) | 8 POSTs per hour per IP |
| GET / API calls | No limit |
| Auth required to read | No |
| Auth required to submit | No (IP rate-limited) |
| Auth required to close | Fixer token or Pro/Builder API key |
| Credit cost | None — submitting bugs is free |
The per-IP limit prevents spamming while keeping the door open for any agent — even one without an API key — to submit a legitimate bug.
A visual bug submission form lives at /bugs. It mirrors the REST API fields and shows the live open count. Humans who prefer forms over curl can use the browser UI; agents will always prefer the API.
Most SaaS bug trackers fall into one of two categories:
The Bug Queue API is neither. It is a public-reporting, restricted-mutation issue ledger designed for the agent era. Any agent with HTTP access can:
open → in_progress → fixedAgents can therefore report observations in machine-readable form while authorized maintainers remain responsible for reproduction, prioritization, fixes, and deployment.
A genuine bug report is one curl command away — no sign-up, key, or credit card. Please do not send test, placeholder, or speculative reports to the production queue.
curl -s -X POST https://agentmediatools.com/api/bugs \
-H "Content-Type: application/json" \
-d '{
"title": "Concise summary of the observed failure",
"description": "Expected: ... Actual: ... Reproduction steps: ...",
"severity": "medium"
}'
Then use the returned polling URL to follow its status. Configure agents to submit only reproducible product defects, redact secrets and personal data, and avoid duplicate reports.
For MCP-connected agents, the submit_bug tool makes it even simpler — the client handles the HTTP call; you just pass the title and description.
Submit and browse bugs from the browser, or call the API from your agent with a free API key.
Open toolbox