list_dlq
List entries currently in this project's dead-letter queue, newest first. One inbound request fans out per-target, so a single failed request may produce several DLQ entries with different targetIds. Returns {total, limit, offset, rows[]} where each row has id (Redis stream id), requestId, target...
This record as markdown: /tools/dev-echorelay-management/list-dlq.md
What list_dlq does on EchoRelay
AI agents call list_dlq to retrieve information from EchoRelay without modifying anything. It is typically the context-gathering step in research, monitoring, and reporting workflows, before the agent takes action elsewhere.
| Parameter | Type | Required | Description |
|---|---|---|---|
limit | integer | — | Page size. Default 50. |
offset | integer | — | Page offset. Default 0. |
Parameters from the server's own tool schema.
Why list_dlq is rated Low
This tool retrieves and queries DLQ (dead-letter queue) entries for inspection and monitoring purposes. It has no side effects, does not modify or delete data, and does not execute operations. The description explicitly indicates it only lists/returns existing entries.
From the tool's definition Tool description states 'List entries currently in this project's dead-letter queue' and 'Returns {total, limit, offset, rows[]}'. The verb 'list' and return-only behavior indicate data retrieval with no modifications.
Attacks that exploit this kind of access
The rule that runs list_dlq safely
PolicyLayer is an MCP gateway: it sits between your AI agents and EchoRelay, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For list_dlq, this is the rule to start with:
list_dlq is read-only, so it stays allowed. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect EchoRelay, apply this rule, and every list_dlq call is checked against it from then on.
Questions about list_dlq
List entries currently in this project's dead-letter queue, newest first. One inbound request fans out per-target, so a single failed request may produce several DLQ entries with different targetIds. Returns {total, limit, offset, rows[]} where each row has id (Redis stream id), requestId, targetId, failureReason, failedAttempts, failedAt, payload (the original Consumer queue entry JSON). DLQ entries — including the original request body and headers — are kept for up to 30 days from the failure time or until cleared, then purged automatically; they are never written to a database. It is categorised as a Read tool in the EchoRelay MCP Server, which means it retrieves data without modifying state.
list_dlq accepts 2 parameters: limit, offset. The full parameter table on this page comes from the server's own tool schema.
Register the EchoRelay MCP server in PolicyLayer and add a rule for list_dlq: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches EchoRelay. Nothing to install.
list_dlq is a Read tool with low risk. Read-only tools are generally safe to allow by default.
Yes. Add a rate_limit block to the list_dlq rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for list_dlq. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
list_dlq is provided by the EchoRelay MCP server (https://mcp.echorelay.dev). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on EchoRelay, and thousands of servers like it.
This server
Across the catalogue