Skip to main content
Glama
clamp-sh

Clamp Analytics MCP Server

Official

errors.list

Read-only

Retrieve recent error events with full context including message, type, stack, and user environment. Filter by time period, browser, or fingerprint to diagnose specific bugs.

Instructions

Recent error events with full context. One row per occurrence, returned newest-first. Each row carries the error itself (message, type, stack, fingerprint, handled flag) plus the standard event context (url, browser/OS/device, country, anonymous_id, session_id) — same shape ingest enriches every other event with, so an agent can correlate "errors here, traffic there" without joining a second tool.

Errors are written to the events table with name = "$error" by the SDKs' captureError() / window.onerror auto-capture. The server adds a stable error.fingerprint at ingest (sha256 of normalized message + first stack frame), so the same bug groups across occurrences regardless of which session or SDK reported it.

Examples:

  • "what errors fired today" → period="today" (no other filters)

  • "show me all TypeError occurrences this week" → message="", or use errors.groups first to find the fingerprint

  • "errors on Safari only" → browser="Safari"

  • "errors on the same fingerprint" → fingerprint=""

  • "only the auto-captured ones, not manual reports" → handled="false"

Limitations: returns up to limit rows (default 50, max 200). Stacks are stored verbatim from the SDK with no source-map resolution — production stacks will be minified for users on a build pipeline. For aggregate counts and dedup, use errors.groups; for breadcrumbs leading to one error, use errors.context.

Pairs with: errors.groups (find a noisy fingerprint, then list its occurrences here); errors.context (drill from one error row into the events from the same session that led to it); users.journey (full multi-session view of a user who hit an error).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idNoTarget project ID (e.g. "proj_abc123"). Required when the credential has access to multiple projects. If omitted and only one project is accessible, that project is used automatically. Call `projects.list` to discover available project IDs.
periodNoTime period. Use "today", "yesterday", "7d", "30d", "90d", or a custom range as "YYYY-MM-DD:YYYY-MM-DD" (e.g. "2026-01-01:2026-03-31"). Defaults to "30d".
limitNoMax rows to return (1-50). Defaults to 10.
messageNoFilter by exact error message (matches the `error.message` property). Use a known message verbatim; substring matching is not supported.
fingerprintNoFilter by server-computed fingerprint (16-char hex). Get fingerprints from errors.groups; same fingerprint groups all occurrences of the same bug.
handledNoFilter to handled (manual captureError calls) or unhandled (window.onerror / unhandledrejection auto-capture). Omit to return both.
browserNoFilter by browser name (e.g. "Chrome", "Safari", "Firefox"). Case-sensitive; use the exact value the SDK reports.
osNoFilter by OS name (e.g. "macOS", "Windows", "iOS", "Android").
device_typeNoFilter by device type. Use this to isolate mobile-only bugs.
countryNoTwo-letter ISO country code (e.g. "US", "DE"). Useful when an error correlates with a CDN edge or a localization issue.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
periodYes
countYes
errorsYes
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses behavioral traits beyond readOnlyHint: returns newest-first, default limit, max limit, no source-map resolution, how errors are captured and grouped (fingerprint). The description adds value that annotations alone do not capture.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: first sentence core purpose, second paragraph ingest details, third paragraph examples, fourth limitations and paired tools. Every sentence adds value despite length. Front-loaded with essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (10 parameters, rich output, many siblings), the description covers return structure, filtering, limitations, and pairing with alternatives. Output schema exists, so return values are not required to be repeated. The description is complete and actionable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% description coverage, so baseline is 3. The description adds value by providing usage patterns (e.g., period='today', browser='Safari') and clarifying the fingerprint parameter (16-char hex from errors.groups). This extra context raises the score above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists recent error events with full context, one row per occurrence, newest-first. It distinguishes itself from sibling tools (errors.groups for aggregates, errors.context for breadcrumbs) and specifies the exact shape of each row (error details plus standard event context).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidelines: examples of queries (by period, message, browser, fingerprint, handled flag), limitations (max rows, no source-map resolution), and clear when-to-use alternatives (e.g., errors.groups for aggregate counts, errors.context for breadcrumbs). Pairs with sibling tools are explicitly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/clamp-sh/mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server