Lumière PayCheck

x402 catalog statistics

catalog_stats

Read-onlyIdempotent

Get an overview of the whole monitored x402 catalog: how many endpoints are monitored, how many fall into each verdict (proceed, caution, avoid, free, insufficient_data), and when scores were last computed. Use it for context or reporting, for example to tell a user how much of the x402 ecosystem passes checks. Endpoints from a seller listing thousands of near-identical endpoints are counted once as bulk_listing until each has its own grade. It says nothing about any single endpoint: use check_endpoint for one endpoint, top_endpoints for a ranked list, or check_payment before paying. Read-only, free, no parameters.

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": "catalog_stats"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`forTeams`	No	Short note about team plans (per-agent keys, spend limits, audit trail)
`scoredAt`	Yes	When scores were last computed
`byVerdict`	Yes	Endpoint count per verdict
`endpoints`	Yes	Endpoints monitored

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 17, 2026
- addedInput schema / $schema
```
Added value: +"http://json-schema.org/draft-07/schema#"
```
First observedSep 30, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, closed-world and non-destructive, so the description is not needed for the safety profile. It nonetheless adds real interpretation context that annotations cannot: scores may be stale (timestamps exposed), the call is free, and bulk_listing endpoints are deduplicated into a single count until individually graded — critical for reading the numbers correctly. It stops short of explaining how insufficient_data or verdict thresholds are determined.

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?

Front-loaded with the purpose and the verdict enumeration before any caveats; the bulk_listing dedup note and the sibling routing both earn their space. Slightly padded by the illustrative clause 'for example to tell a user how much of the x402 ecosystem passes checks', which restates the reporting use case already stated.

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?

An output schema exists and the description needn't restate return shapes. For a zero-parameter read tool, the definition covers purpose, counting semantics, staleness, cost, and all relevant sibling boundaries — an agent can call it and interpret the result correctly.

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?

Zero parameters, so the baseline is 4. The description's 'no parameters' merely confirms what the empty schema already shows and adds no additional semantics, but nothing is missing.

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 and scope ('Get an overview of the whole monitored x402 catalog') and enumerates exactly what is returned: endpoint count, per-verdict breakdown (proceed, caution, avoid, free, insufficient_data), and score timestamps. It is immediately distinguishable from siblings because it explicitly disclaims per-endpoint coverage.

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?

Gives positive guidance ('use it for context or reporting') and an explicit exclusion ('it says nothing about any single endpoint'), then routes to the correct alternatives by intent: check_endpoint for one endpoint, top_endpoints for a ranked list, check_payment before paying. Nothing is left to inference.

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

All Lumière PayCheck 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.