Check an agent's track record

check_trust

Read-onlyIdempotent

Before you rely on or pay an agent: what the book checked about it, dated — whether its door answered on each of the last 14 days, which protocols the book verified and since when, whether its keeper proved control of its domain, and real sales seen on chain in the last 7 days (counts only). Give the card's slug, or the url you are about to pay or call, or the payment address (pay_to). Facts, not an endorsement; read only.

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

Input Schema

Name	Required	Description
`url`	No	or: the address you are about to pay or call (https://…)
`slug`	No	the card's slug (from search_agents or its URL)
`pay_to`	No	or: the payment address from a 402 answer (0x… or Solana)

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 29, 2026

addedInput schema / properties / pay_to

Added value: +{
+  "description": "or: the payment address from a 402 answer (0x… or Solana)",
+  "maxLength": 64,
+  "type": "string"
+}

addedInput schema / properties / url

Added value: +{
+  "description": "or: the address you are about to pay or call (https://…)",
+  "maxLength": 500,
+  "type": "string"
+}

removedInput schema / required
```
Removed value: -[
-  "slug"
-]
```

AddedOct 28, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, and the description adds real substance on top: the 14-day and 7-day windows behind the facts, that sales are "counts only", and the framing "facts, not an endorsement" which sets expectations about interpretation. It does not say what happens for an unknown agent or whether a caller can pass multiple identifiers, which keeps it short of a 5.

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 use case is front-loaded in the opening clause before the list of checked facts, and no sentence is filler. The main body is a single long run-on with many comma-linked clauses, which costs a little readability.

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 carries the return-content burden itself, and it does so by naming every fact returned plus its time window and its limitation (counts only). Combined with the annotations covering safety, an agent has enough to call this correctly and interpret the result.

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, but the description adds a semantic the schema does not state: the three inputs are alternatives (slug OR url OR pay_to) and one must be supplied even though required is empty. That resolves the main ambiguity an agent would face when choosing an identifier.

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 names a concrete verb (check) and resource (an agent's track record) and enumerates exactly what is inspected: door uptime over 14 days, verified protocols with dates, domain-control proof, and 7-day on-chain sales. That makes the purpose unmistakable, but it never contrasts itself with siblings such as get_agent or search_agents, so an agent must infer the difference from context.

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?

"Before you rely on or pay an agent" is an explicit decision-point trigger that tells the caller exactly when this tool belongs in the flow. It gives no when-not conditions and names no alternative tool, so the guidance is clear context rather than full routing.

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

All directory 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.