Skip to main content
Glama

probe402

by com.probe402

probe402_endpoint_grade

The Machine Commerce Observatory: independent readings of x402 and MPP endpoints — alive right now, quoting what, and how fast? Probed at arm's length on a fixed clock, every reading traceable to a retained capture. Blocked and rate-limited are told apart from unreachable at capture time, so a defended endpoint is never reported as dead. Not affiliated with any endpoint graded. Call before paying an unfamiliar endpoint, or to check whether one you use has repriced or rotated its payTo. This tool is the FREE grade: current observation plus 7 days of counts. The same record our published reports are written from.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endpoint_idYesprobe402 endpoint id, from the free /coverage list

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the independent probe methodology, fixed-clock timing, retained captures, the distinction between blocked/rate-limited and unreachable, and the non-affiliation stance. This is unusually transparent and goes far beyond a generic read-only claim.

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?

The description is front-loaded with the core purpose and then builds trust with methodology, use cases, and scope. It is slightly promotional and longer than strictly necessary, but every sentence contributes meaningful information.

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

Completeness4/5

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

For a single-parameter tool with no output schema, the description conveys the essential scope, behavior, and usage context. It does not enumerate the exact grade fields returned, but an agent can still select and invoke the tool correctly based on the given information.

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

Parameters3/5

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

The schema already covers the single endpoint_id parameter with a useful description ('from the free /coverage list'), so the high schema coverage sets the baseline at 3. The description adds no additional parameter-level meaning, syntax, or example.

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

Purpose4/5

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

The description clearly identifies the tool as an independent grade for x402/MPP endpoints, reporting current liveness, quote, speed, and a 7-day count. It is specific about the resource and output, but it does not explicitly contrast with the sibling probe402_endpoint_history, so differentiation is implied rather than stated.

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

Usage Guidelines4/5

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

The description gives concrete trigger conditions: call before paying an unfamiliar endpoint, or to check whether an endpoint has repriced or rotated its payTo. It does not explicitly say when not to use it or when to prefer the sibling history tool, so it falls short of full guidance.

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

All probe402 toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation2/5

The two tools are named differently (grade vs history), but their descriptions are almost identical, with only one sentence distinguishing the grade tool. An agent would struggle to determine which tool provides the needed historical or current data without guessing.

Naming Consistency5/5

Both tools follow the same probe402_endpoint_<noun> pattern, making the naming clear, consistent, and predictable. The only difference is the final noun, which directly conveys the tool's purpose.

Tool Count3/5

With only two tools, the server feels thin but is still plausible for a focused observatory service. The count is on the borderline of being too small, though it may cover the core need of current grading and historical review.

Completeness4/5

The domain is narrowly scoped to endpoint grading, and the two tools cover current observations and history. Minor gaps exist, such as lack of an explicit comparison or alerting tool, but the core workflow appears covered.

Resources