AnalyticsProof

List scan history

list_scans

Read-onlyIdempotent

List scan history (permission: read)

Keyset pagination: pass the previous response's nextCursor as ?cursor= to fetch the next page (ordered createdAt DESC, id DESC). nextCursor is null on the final page. Filters combine with AND. Each item has id, scanType, status, targetId, journeyId, score, createdAt and completedAt.

Use it to find scans by saved test, journey, type or status. For one scan: get_scan (status and the CI gate), get_scan_evidence (the stored data), explain_scan (a plain-language summary).

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_scans"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Page size, 1–100.
`cursor`	No	The previous page's `nextCursor` (opaque). A malformed cursor is 400 on path cursor (issue code invalid_cursor).
`status`	No	Only scans in this status.
`scanType`	No	Only scans of this type.
`targetId`	No	Only scans of this saved test.
`journeyId`	No	Only replays of this journey.
`projectId`	No	Required with an organization key; must be the key's project with a project key. Missing (organization key) or not a UUID: 400 invalid_request on path projectId; a project outside the key's reach: 404.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 5, 2026
- addedInput schema / properties / journeyId / description
```
Added value: +"Only replays of this journey."
```
- addedInput schema / properties / scanType / description
```
Added value: +"Only scans of this type."
```
- addedInput schema / properties / status / description
```
Added value: +"Only scans in this status."
```
- addedInput schema / properties / targetId / description
```
Added value: +"Only scans of this saved test."
```
First observedNov 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: it discloses the required permission, the keyset pagination contract (pass nextCursor as ?cursor=, null on the final page), the sort order (createdAt DESC, id DESC), the AND-combination of filters, and the shape of each returned item. These are behavioral facts the annotations cannot express.

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?

Three short, front-loaded blocks (purpose, pagination, routing) with no filler. Slight overlap with the schema's own cursor and limit descriptions, but the reiteration is brief and supports standalone reading.

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?

With no output schema, the description takes on the burden of describing return shape and does so (id, scanType, status, targetId, journeyId, score, createdAt, completedAt). Pagination, filtering, permissions and sibling routing are all covered for a 7-parameter list tool.

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?

Schema coverage is 100%, so the baseline is 3; the description earns above that by disclosing the ordering guarantee, the opaque-cursor round-trip, the AND semantics across filters, and the fields of each item. It adds little on the enum values themselves, which the schema already carries.

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?

States a specific verb and resource (list scan history) plus its scope, and immediately differentiates itself from get_scan, get_scan_evidence and explain_scan by naming what each of those returns instead. An agent can pick the right tool without opening any schema.

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 says when to use this tool ('find scans by saved test, journey, type or status') and when to use each alternative, naming all three sibling tools with their distinct purposes. Exclusions are implied by the routing to the single-scan tools.

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

All AnalyticsProof tools Inspect

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

Need Help?