Skip to main content
Glama
Sign In

Privatrak

by com.privatrak
OverviewDiscussionsAdmin

Click problems

list_click_problems
Read-onlyIdempotent

Click problems (dead clicks, rage clicks and more), worst first, paged. Four signals, each with the dashboard's name for the user: dead (No effect: nothing visibly happened), rage (Repeated clicks: a rapid burst), error (Errors: an uncaught error followed), slow (Slow responses). Each counts once per element per page view: page views, not clicks or visitors. Default status: open and reopened (Happened again): a dead or error click after it was resolved, even outside the period (since counts); rage and slow clicks never reopen. Pass a row's identity as is to resolve, ignore_ or reopen_click_problem; element_selectors: the exact selectors that had problems, to find them in code. changes compare total_with_signals. Max 92 days. Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_click_problems"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoLast day, YYYY-MM-DD in the project's timezone, inclusive. Default: yesterday, the last complete day.
fromNoFirst day, YYYY-MM-DD in the project's timezone, inclusive. Default: 27 days before 'to'. At most 92 days in one call.
pageNoPage number, from 1.
limitNoRows per page, 1-100. Default 50.
statusNoStatuses to list, any of: open (never resolved or ignored), reopened (Happened again: resolved, then a dead or error click came in), resolved (resolved and quiet since), ignored. Default: open and reopened, the ones that want attention.
projectNoProject ID, from list_projects. Required when this connection covers more than one project; may be left out when it covers one (and with an API key, which belongs to one project).
signalsNoOnly rows with a signal of one of these types in the period: dead (shown as No effect), rage (Repeated clicks), error (Errors), slow (Slow responses). A reopened (Happened again) row also qualifies for dead or error through the click that recurred. Default: no filter.
sort_byNoproblems (all four signals added up), dead, rage, error, slow, last_seen, status (reopened, open, resolved, ignored), element (its text, A to Z) or page. Default: problems, with reopened (Happened again) rows first.
group_byNoelement (default): one row per element (page, generalized selector, text, tag). selector: one row per exact CSS selector (element_selector), e.g. one per list item, to pin down which instance; these rows carry no identity (see notes).
page_urlNoOnly elements on this page, as a full URL (e.g. https://shop.example.com/pricing). Normalised like ingestion and matched on both origin and path. Not together with page_path.
sort_dirNoasc or desc. Default: desc, except asc for element and page.
page_pathNoOnly elements on this page path, exact, as stored (e.g. /products/:id), on every origin. Not together with page_url.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Though annotations already establish readOnly/idempotent, the description adds substantial non-structured context: counting semantics (once per element per page view, "page views, not clicks or visitors"), the reopen rule including the fact that rage and slow never reopen, and the timezone/calendar-day behavior. These are behavioral traits an agent could not infer from the schema.

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

Conciseness4/5

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

Purpose and ordering come first, then details in a logical progression with no filler. It is a dense, single-block paragraph with parenthetical asides that make it slightly harder to scan than a bulleted form, but every clause carries operational 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?

For a 12-parameter tool with no output schema and no enums in the schema, the description covers dates, timezone, paging, sorting, grouping, filtering and follow-up actions. An agent has everything needed to construct a correct call and interpret the result shape at a high level.

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

Parameters5/5

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

Schema coverage is 100%, but the description goes beyond it: it glosses each signal with the dashboard label (dead = No effect, rage = Repeated clicks), explains that reopened rows qualify through their recurring click, notes that group_by=selector rows carry no identity, and flags the page_url/page_path mutual exclusion and sort_dir defaults.

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?

Opens with a specific verb+resource combination ("Click problems (dead clicks, rage clicks and more)") plus ordering and pagination, so the agent immediately knows this is a paged, sorted list of click-quality issues. The scope is narrow enough that it is clearly distinct from the funnel/flow/feature siblings in the toolset.

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?

Explicitly states defaults (status open+reopened, last 28 complete days), the 92-day cap, and the rule for omitting from/to. It also names the follow-up tools ("Pass a row's identity as is to resolve_, ignore_ or reopen_click_problem") and explains group_by as a choice between element-level and selector-level views.

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

All Privatrak toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources